Week 7: The Toll Road's Business Model, in Software

A toll gate doesn’t fail the way a jammed ticket machine fails — it succeeds exactly as designed, and the failure is that you can’t find out the price until the bill arrives. That’s not a UI bug. It’s a concession contract wearing a transponder.

Outline#

• e-tolling as the clearest case this semester of a business model, not a usability failure, showing up as a machine: the price genuinely can’t be known until after you’ve already paid it
• reading a concession contract to find the incentive a toll gate’s interface was built to protect — a minimum-revenue guarantee behaves very differently from a straight per-kilometre fee, and the gate can’t tell you which one it’s enforcing
• what “dynamic pricing” is doing when the driver has no way to see it coming

The argument#

Most machines in this course fail in a way you can point to: a button that doesn’t respond, an instruction that doesn’t match what happens next. A toll gate is different — it does exactly what it was built to do, and what it was built to do is protect a concession contract’s revenue guarantee, not tell you the price before you owe it. There’s no bug to find, because nothing is broken.

That’s what makes it the clearest business-model-as-interface case this semester studies: a minimum-revenue guarantee and a straight per-kilometre fee produce very different incentives for the operator, and the gate gives you no way to tell which one is actually governing your trip. “Dynamic pricing” sounds like a feature. From the driver’s seat, it’s a bill you can’t predict, arriving after the decision it should have informed.

Question to carry: if you can’t find out the price until after you’ve paid it, in what sense did you agree to it?