Selling a FASTag shouldn’t be complicated.

BlackBuck is a logistics company working to modernize India’s trucking industry. It digitizes services for truck owners and connects them with businesses, acting as a digital backbone for trucking operations.

This project involved two products:

BlackBuck app

The customer-facing app, used by truck owners, drivers, and large fleet owners.

BB Pro app

The sales app used by CROs—BlackBuck’s sales agents.

The FASTag issuance flow originally lived in the customer-facing BlackBuck app. A business decision was made to move it to BB Pro. But moving the screens alone would not solve the underlying problems: who had access to a customer’s money, how an agent tracked orders, and when costly mistakes were caught.

Many of the truck drivers we served had limited digital literacy. Since FASTag is a physical product, a CRO was usually present during issuance. Drivers would often hand over their phones and ask the agent to complete the process for them.

Access to the device also meant access to the wallet.

Existing customers often had money in their BlackBuck wallets. For large fleet owners, that balance could run into lakhs of rupees. In some incidents, an agent misused that access, exhausted the customer’s wallet balance, and disappeared.

Agents could not see their orders in one place.

A CRO typically completed five or six issuances a day, each on a different customer’s device. With the orders spread across those devices, the agent had no single place to track their status.

Moving the flow also gave us an opportunity to fix problems within issuance itself. The first was vehicle classification.

The old logic had been designed around trucks.

A FASTag’s class depends on vehicle characteristics. The NPCI classification logic we worked with considered vehicle type, gross vehicle weight, seating capacity for buses, and the number of axles.

BlackBuck’s existing flow asked for only two inputs: the number of tyres and gross vehicle weight. Those inputs were then used to assign a FASTag class.

That worked for the original truck-focused business. As the business expanded to buses and cars, the missing information became a problem.

Two gaps created downstream errors.

1. No vehicle-type input. The system assumed every vehicle was a truck, so buses were also recorded as trucks.
2. An incomplete classification model. With too few inputs, the assigned class could differ from the required class.

Incorrect assignments meant revenue lost through churn and more support and operations tickets.

A complete matrix, revealed progressively.

After reviewing the NPCI guidelines, we created a classification matrix that covered the vehicle types we issued tags for. We used progressive disclosure so the CRO saw the relevant questions as they moved through the form, rather than facing every possible input at once.

CROs often sold tags at toll gates or transport hubs. Some drivers did not have access to digital money at the point of sale. An agent would pay through their own UPI account and collect cash from the driver.

When issuance failed, the money returned to the wrong place for the agent.

The refund was credited to the driver’s BlackBuck wallet, even when the CRO had made the original payment. The agent could not access that balance. This made CROs hesitant to fund transactions, affected sales, and generated more support tickets.

We moved rejection checks to the beginning.

Looking into the failed issuances revealed two rejection reasons: the customer was hotlisted or blacklisted, or already had a FASTag issued by another bank.

We asked for the customer’s mobile number at the start and added a Verify action. If the check identified either condition, the flow stopped before payment was collected.

Full KYC was an important part of the customer’s FASTag setup, but it could be skipped during issuance, leaving the customer with limited usage. BlackBuck had an existing biometric KYC method; for the new BlackBuck FASTag offering, we did not yet have the license to use it and needed a manual full-KYC flow.

The agent’s incentive was to finish the sale.

CROs earned sales points for every issuance. Completing a tag quickly and moving to the next sale was attractive; skipping full KYC was an easy way to do that.

This led me to the idea of designing for accountability. We usually try to remove friction. Here, we intentionally introduced it to make the incomplete step visible and nudge CROs to finish the customer’s full KYC.

BlackBuck had more than 5,000 CROs, with each agent completing roughly five or six issuances a day. At that scale, the same flow could be repeated around 20,000–30,000 times daily. Small redundancies added up.

The aim was to make issuance fast and easy without removing the checks that protected customers.

Skip an empty orders screen.

When an agent had no pending or completed orders, we skipped the FASTag orders screen and took them directly into issuance.

Use a sensible default for the majority.

Trucks accounted for 98% of issuances, so we preselected Truck as the vehicle type. Other vehicle types remained available.

One question remained beneath the whole redesign: now that issuance happened on the agent’s device, how should the customer pay?

In the earlier customer-app flow, payment was handled through a payment gateway or cash paid to the CRO. After discussion, two approaches were shortlisted for BB Pro.

The final direction: issuance on BB Pro, payment on BlackBuck.

Once the order was confirmed in BB Pro, a payment request would be sent to the customer’s BlackBuck app. The agent could manage issuance on their own device, while the payment step returned to the customer’s app.

That separation was the central decision: simplify the sale without making the customer’s money depend entirely on the agent.

This project was more than a move between apps. It required deciding which steps to remove, which checks to bring forward, and where friction was necessary.

Defaults and fewer touchpoints made repeated work easier. Early verification caught known failure conditions before payment. KYC nudges made an incomplete task harder to overlook. And keeping payment in the customer’s app helped preserve their visibility and control.

The goal was not simply to issue a tag faster. It was to make the sale easier to complete—and harder to misuse.