Buying a banner on SnappFood meant phone calls, SMS contracts, and manual payment tracking. I designed the purchase flow in the vendor app, working with the product manager, sales, finance, and development teams to make a first version we could deliver in one cycle.
01Sales growth
02Choose a placement
03Find available dates
04Follow the request
The banner purchase flow in the vendor app. Results above cover the first three months.
02 · Why it mattered
Selling a banner took six calls over two months.
6%Offline sales conversion
6calls
2months
1sale
About 200 vendors converted from 3,000 calls. Converting a restaurant took an average of six calls over two months. The operations team could not reach all potential vendors by hiring more agents.
SnappFood is a food delivery service in Iran. Restaurants could buy banner spots on the home page and category lists, including restaurants, cafés, and confectioneries. The business wanted to sell those spots inside the vendor app.
Where the banners appear to customers.
01 · Business owner
Understand the opportunity
I started with the team and project manager: how large was the revenue opportunity, how were banners sold, and what made the offline process difficult?
02 · Three sales agents
Understand what slowed sales down
I needed to understand whether the bottleneck was the number of agents, the sales flow itself, or both.
03 · Stakeholders
Agree on an MVP
The product manager and I worked with the business team to treat the first release as an MVP, then check its effectiveness and resolve the issues it exposed.
The questions I started with↗
How much was this revenue opportunity?
Why couldn’t the team sell the banners through the offline flow?
Converted vendors as a share of submitted requests
Number of purchased banners
03 · Design decisions
How I designed banner selection and payment
Problem 1Three dependent choices, with no obvious starting point.
A restaurant needed to choose an area, a spot, and a date. Each choice changed what was available in the other two. I explored different starting points and orders before the team selected a flow for the MVP.
↔
SpotWhich page?
The banner could appear on the restaurant, café, confectionery, or another list in the customer app.
↔
AreaWhich district?
Different Tehran districts could show different restaurants’ banners in the same placement.
DateWhich day?
Each banner was sold for one day. Availability depended on the chosen spot and area.
We assumed vendors would already know the type of placement they wanted and would prefer the area where their store was located. With those two choices made, the calendar could show the available dates.
These were assumptions
We did not have time to interview vendors or run another research phase. I planned to check the sequence after launch by tracking requests on the same date across different areas, and requests for different spots within the same date or area.
First, choose the placement.Then choose the area and explore the available dates.
Problem 2Vendors were used to paying later. Card payments weren’t available.
In the offline flow, agents confirmed a purchase over the phone and the cost was deducted from the vendor’s revenue. We could not simply move this to a card checkout: the platform did not support it, and paying the full amount upfront was a change from the existing process.
Rejected
Card payment
Technical limitations ruled it out. We also assumed the change from paying later could reduce conversion.
Rejected
Wallet + card
It retained the same technical limitation and still charged the full cost in one step.
Rejected
Biweekly deductions
Finance rejected the manual process because it was not trackable or maintainable.
Assigned credit made the purchase more complicated
I explored combining the wallet balance with credit based on the vendor’s revenue and level on the platform. We rejected it because explaining how credit was assigned, calculated, and topped up made the purchase more complicated.
The wallet and credit explorations↗
Pay the full price in five installments
Banners were expensive enough that a wallet balance might not cover the purchase. We chose to split the full price into installments, deducted from daily revenue over five days. The installment amounts were calculated using the vendor’s average daily revenue.
Full banner price↓
Day 1Daily revenue
Day 2Daily revenue
Day 3Daily revenue
Day 4Daily revenue
Day 5Daily revenue
Installment amounts calculated using the vendor’s average daily revenue.Exploring how to explain the installments↗
Checking the payment decision
I defined two measures: requests that did not get past the basket, and average basket value compared with average wallet credit for each vendor level.
The final payment flow: the full banner price, spread over five days.Making request statuses clear to developers↗
The vendor app and back office needed to stay in sync. Design documents, user flows, and separate Excel sheets were not communicating those status changes clearly enough. I created a sequence diagram to explain the interactions.
The research team reported these results after three months. The numbers were rounded.
Banner sales handling time
−71%
Before
After
Converted vendors / submitted requests
62%
Active advertising vendors
+5%
Calls to convert a vendor
4 fewer
−−−−
Banners purchased per month
390
Monthly average
Most banner purchases came from vendors who were already active in advertising.
My contribution
I mapped the offline and online flows, interviewed sales agents, explored package selection and payment options, and defined measures to check the assumptions. With the product manager and business team, I kept the first release focused on an MVP. I also changed how I documented request statuses when the existing material was not helping developers.
What this project taught me↗
Keep the MVP small enough to deliver
We had one cycle and limited research capacity. New details kept emerging from the sales team. I had to stay flexible without letting every possible improvement expand the first release.
Use the right document for the problem
I kept detailed design documents at SnappFood, but more detail was not always the answer. The status handoffs needed a different form of documentation. The sequence diagram made me think more carefully about who each document was for.
05 · Beyond the MVP
What comes next
The first release left three areas for further work.
01 · Exploration
Banner builder
Automate banner creation in real time so each purchase would no longer depend on the graphic design team.
Graphic design team→Automated creation
A subsequent direction for automating banner design.
02 · Further work
Chain restaurants
Extend the single-branch flow to vendors with several branches. This introduced a more complex set of choices and became a separate piece of work.
03 · Further work
Reporting
We could not include a statistics dashboard in the MVP. In subsequent work, we began designing a reporting system for vendors to understand their banner performance.
