Porter, quoted before the loading starts

The two uncertainties in a Porter trip, and who owns each

Porter moves goods inside Indian cities. Somebody sets a pickup and a drop, picks a vehicle class, says what the goods are and books. The Mumbai page offers a 3 Wheeler at 500kg from ₹202, a Tata Ace at 750kg from ₹236, an 8 FT Pickup at 1250kg from ₹385 and a Tata 407 at 2500kg from ₹775. A number appears before anybody has verified anything about the job.

Two things are unknown at the moment of booking: when the vehicle will arrive, and what the bill will say. Porter’s own pages treat those as separate problems and hand them to different people. The time risk it disclaims outright and blames on the road. The money risk it enumerates, and almost every item it names is something the person booking did.

My reading is that the second one is the product problem, and that loading is the largest part of it. That belongs at the top labelled as a hypothesis and not conceded at the bottom as a caveat. I cannot see the spread of final fares against their estimates from outside. Porter can measure it. I cannot.

Porter blames traffic, and its own fare list does not

On reliability the Spot FAQ says this, and the whole sentence is the point: “We would like to assure you of the accuracy of our ETA & the estimated travel time. However, given the unpredictable nature of traffic & road conditions, we do not provide any service guarantee.” That is scoped to arrival and travel time, it arrives with its reason attached, and it is not a refusal to stand behind anything. Porter states confidence in the estimate and still declines to guarantee it.

The fare answers on the same page run on a different logic. The trip fare is calculated after a trip is ended, and the page lists what makes it rise: the pickup and drop changing a lot from the ones originally entered, loading and unloading exceeding 60 mins, multiple stops in the trip, a route the person insisted on that differs from what Porter recommended, and other unforeseen issues.

Traffic is not on that list. The catch-all at the end could swallow it and I am not going to pretend otherwise. Four of the five named items are things the person who booked caused. One of them is measured in minutes.

Two more figures off the same page. Cancel once a partner is assigned and the fee is ₹50. Parking is borne by the person booking, over and above the fare, paid to the driver directly.

The Packers and Movers page carries both halves of this in one scroll. Near the top: “Our charges are fixed. What you see is what you pay.” Further down: “Prices are subjected to revision if there is change in the location or final item list. Rates can also change basis the complexity of shifting.” Both can be true. The second sentence is the one that governs.

What the booking form does not ask

The flow collects pickup, drop, extra stops, vehicle class, type of goods and a payment method. It does not ask which floor, whether there is a lift, whether the vehicle will stand at a dock or at a kerb, or whether anybody will be at the drop to help lift. Loading assistance is bookable, sitting alongside the vehicle with its own price rather than inside the estimate.

So the one item on Porter’s own fare change list that is counted in minutes is the one item the form collects nothing about. The reason is not mysterious. Every field in a booking flow costs conversion, and a distance and vehicle estimate is cheap to compute and good enough to win the job.

One limit on my own argument, and it is a real one. Porter also runs a two-wheeler goods service, and on a parcel run the loading bay barely exists. Whatever share of trips that product carries, and I do not know it, dwell cannot be the dominant variance there.

Where a shop and a household move stop wanting the same thing

Somebody shifting a fridge wants the lowest number. Variance is absorbable there: the trip is a one-off, the amount is small in absolute terms and nothing downstream is riding on it.

A shop has already quoted somebody else. A distributor has promised a retailer a window. For that buyer a bill that lands well over its estimate is worse than a higher bill that was certain, because the certain one could have been priced into the quote it gave. That is a belief about willingness to pay and I have not tested it. No interviews, no pricing research, nothing but the shape of the problem.

The same split runs through reliability. A household move needs no service guarantee and Porter declines to offer one for the reason it publishes. A business needs one, and neither the app nor the public Enterprise page offers it. What sits inside an actual Enterprise contract I do not know.

Porter knows the business demand is there. Enterprise exists, it ends in a Request Callback button, activation takes one business day, and what the page lists is a prepaid wallet, multi-user access, unified trip details and what it calls “Complete Clarity and Control”. Those answer who pays and how it gets reconciled. Neither is an arrival promise.

The number I would put on the wall, and how it gets gamed

Quote hold rate: the share of completed trips whose final fare lands inside a stated tolerance of the number shown at booking. Both of those numbers already exist inside Porter, so this is measurable now with nothing shipped. The tolerance gets fixed once and does not move afterwards.

Underneath it, three layers.

Two guardrails, both on the supply side. Partner earnings per online hour, because the lazy route to a better quote hold rate is to make drivers absorb waiting unpaid. Unfilled request rate, because the other lazy route is to quietly stop serving awkward loads.

Now the failure modes, which matter more than the definition. The metric is gameable by quoting high: pad every estimate and it climbs while the product gets worse, so median rupees per kilometre by vehicle class has to be pinned beside it rather than left to float. The denominator is wrong in a way it cannot fix from inside, because it counts completed trips, so the quoting failures that mattered most are the ones it will never see, where somebody read the estimate and shut the app. And it says nothing at all about arrival. A trip can bill to the rupee and still turn up late. The arrival window needs its own number.

What I would build, ordered by what the next thing depends on

One rule, and it is dependency rather than effort. Nothing here can be banded, capped or priced until the dwell data exists, so the measurement work goes first even though the form change is cheaper to ship. The efficiency ordering would put the two booking questions at the top and I am not using it.

What I am giving up, and who pays for it

I am choosing the shop over the household move, and the bill for that lands on the household side.

A loading clock, two extra questions and a band where a number used to be all make the flow slower and the headline price look worse. Porter’s own city pages sell on a price each vehicle starts from, and I would be putting a range in that slot. If one-off household moves are the bulk of trips and mostly price led, this is the wrong call, and the split is not something I can size from outside.

So the rollout is bounded. Ship the questions and the clock to Enterprise accounts and repeat bookers first, leave the single number on a first time booking, then compare the two populations on disputes, repeat rate and completed booking conversion. There is a hole in that plan worth naming: below Enterprise there is no account segmentation to target, so the first version reaches only the accounts Porter can already identify.

The capped fare is the other exposure, since it puts Porter on the hook for the exact tail it currently passes through. I would not price a cap before the dwell data exists.

What would change my mind, and what it costs to find out

If the spread of final against estimated fare turns out tight for most trips with the pain sitting in a thin tail, the premise is mostly wrong. The problem is then allocation and arrival, and everything below the measurement row drops down the list.

If business bookings are a small minority and the volume is genuinely household moving, predictability is a niche and I have built for the wrong buyer.

If Enterprise contracts already carry fixed rate cards and an arrival promise with a remedy attached, the capped fare exists already in a form the public pages do not show, and I would read one of those contracts before writing a line of spec.

If drivers are already declining long dwell jobs at the acceptance step, the binding constraint is supply side selection and not the number shown at booking, and the fix is compensation design.

Three of those four are cheap to answer and this piece rests on none of them having been answered. One booking on a 3 Wheeler in Mumbai starts at ₹202 and shows what the screen actually does while the vehicle stands there. The Request Callback on the Enterprise page costs nothing and activation takes one business day. Standing a day each at a wholesale market, an apartment block and a factory gate measures how long loading takes, which is a different question from how often the bill misses, and worth doing second.

The cheapest thing on this list is the booking I have not made.