One Way
Into Support

I redesigned rider support at Snapp so there is one place to start. Riders say what went wrong, the flow collects the trip or transaction it needs, and then solves the problem on the spot or hands it to the right channel: a call, a chat with an agent, or a ticket.

In a launch to 10% of riders, calls about lost items fell 70%, calls in other categories fell 5–7%, and call-center costs fell about 3%.

Riders had three ways to reach support, each with its own rules:

• Tickets. A submitted ticket disappeared into a separate tickets section. About 50% were answered automatically, the rest by agents. Automatic answers were text only and couldn’t take any action.
• Phone. Always available, with about a 5-minute wait on average.
• Chat. Only for riders on a trip, whose problems needed a fast fix. An agent joined in under 2 minutes.

For riders

• Too many ways in, and no clear sign of which one to use.
• They wanted every issue solved as fast as possible.
• Some tickets were already solved automatically, but the design hid it. Riders didn’t notice the answer had arrived, or that the problem might be fixed.

For the business

• Support costs were high.
• Everyone waited in one queue. A rider with a payment problem mid-trip waited as long as someone with a general question.
• Duplicate contacts were common. Riders submitted a ticket, then called to get an answer sooner.

To route riders well, we first needed to know why they contacted support. We tagged one month of tickets with the help of AI. Calls were already tagged by the support team, and we checked that their tags matched our categories.

• Needs the trip
• Needs the transaction
• Needs neither

1. Lost items11.1
2. Trip status changed6.8
3. Unpaid fare6.4
4. Questions about Snapp services6.2
5. Talkative driver5.7
6. Transaction follow-up3.7
7. Unsafe driving3.3
8. Checking trip status3.2
9. Financial transactions3.1
10. Payment method questions3.0
11. Trip cancellation dispute2.7
12. Poor vehicle condition2.3
13. Driver charged extra2.3
14. Not dropped at destination2.1
15. Driver asked for card transfer1.8
16. Passenger or luggage limits1.8
17. Account blocked1.6
18. Driver asked for a higher fare1.6
19. Paid cash, also charged in-app1.5

Lost items was the largest single reason, at about 11% of tickets, so it got a dedicated flow. Almost every other reason was tied to a specific trip or transaction, which shaped how the new flow asks questions.

Instead of choosing between tickets, calls and chat, riders now have one way into support. Based on their problem, the flow collects what it needs and sends them to the channel that fits.

1. One support entry point
2. Choose a problem category
3. Pick the trip, add details

Routed by problem and urgency

• Solved in chatAuto answer or a one-tap action
• Call supportUrgent, needs an agent right away
• Chat with an agentCan be solved in chat, needs an agent
• TicketNot urgent, an agent reviews it later

The biggest question was how much to ask before a rider reaches an action or an agent, and in what order.

1. Collect the trip before the agent

For about 90% of contacts, solving the problem required knowing which trip or transaction it was about. Asking for it before handing the rider to an agent, in chat or on a call, means the agent starts with a clear case and every conversation gets shorter.

2. Problem first, then the trip

We followed the rider’s mental model. We listened to about 1,000 random support calls, and in about 87% of them riders described the problem first, then named the trip or transaction when asked. So the flow asks for the problem category first, then the details that problem needs.

3. Layers instead of one long list

There were about 15 problem categories. Instead of a 15-item list on the first screen, we merged them into broader groups and showed each group’s subcategories in the next step. Each step stays light, and riders share their information piece by piece.

Each category was designed around what riders in that situation actually need.

Lost items

Riders need to reach the driver fast to find out whether their item is still in the car. They pick the trip where they think they left it, and get a button to call the driver directly. Contacting support is still available.

Trip payment issues

Riders pick the trip, then choose what happened from the most common cases. Each case leads to a different channel.

1. Trip payment issue
2. Pick the trip
3. What happened?

• Hasn’t paid the farePay againOne-tap retry in chat, no agent needed
• Paid online and in cashRefund claimClaimed in chat, an agent verifies it
• Disputes the fareTicketAgents review it later, with more time

This flow shows the logic of the whole system: riders are sent to the most fitting channel, not always the fastest one.

Trip or driver issues

Riders pick the trip, then choose what went wrong from a set of common options. If their problem isn’t listed, they can type it in.

A change this big needed buy-in from engineering and stakeholders. In about one day, we built a quick prototype with Figma Make and Claude, and used it in alignment sessions so every team agreed on one shared picture.

Once the teams signed off, we tested the wireframes with 15 riders.

The handoff from bot to agent was confusing

When the chat moved from automated answers to an agent, riders didn’t realize a person was now replying. We made the transition smoother and more explicit: a clear message and a change of profile in the chat now show that a human agent has joined.

Lost items

Trip payment issues

We launched to 10% of riders to measure the impact. Within that group:

• Lost items. This category was about 11% of tickets, and its calls dropped 70%.
• Other categories. Calls dropped 5–7%.
• Cost. More agents were handling chats, but chat costs less than a call, so call-center costs fell about 3%.

• Riders don’t care about the channel. They care about how fast their problem is solved.
• Being clear about when a human takes over matters as much as the answer itself.
• The best route is the most fitting channel, not always the fastest one.