Every enterprise browser pitch has the productivity slide: hours saved per user per week, seven figures a year, an ROI multiple with a decimal point for credibility. The number is not fake, it is manufactured, there is a standard method, and once you know the method you can rebuild any vendor's figure from scratch in five minutes. You can also see which numbers a real deployment will actually confirm, and they are not the ones on the slide.
The arithmetic machine
The method takes a small, true, per-action delta and multiplies it until it becomes money. Here is the standard construction, invented numbers, real recipe.
Start with something you can time with a stopwatch: the browser fills SSO credentials and skips a redirect chain, saving 40 seconds per login to a legacy app. Assume six of those logins a day, plausible, someone in the pilot did six. That is 240 seconds a day, 20 minutes a week, about 17 hours a year, per user. Multiply by 5,000 seats and you have roughly 87,000 hours. Price it at a loaded cost of $55 an hour and the slide reads $4.8 million in annual productivity gain. Stack a second delta on top, say tab search across a hundred open tabs, and you can double it before lunch.
Every individual step survives scrutiny. The delta is real, the frequency came from somewhere, the seat count is on the contract, the loaded rate is from finance. The product of the steps is fiction anyway, because the multiplication smuggles in three assumptions that never hold. It assumes 100 percent adoption, when a third of the fleet is still on the old flow six months in. It assumes zero behavior change, when friction removed from a workflow mostly changes how the workflow feels, not how much of it happens. And it assumes the big one: that shaved seconds convert into productive work. They do not. Forty seconds saved on a login becomes a slightly longer glance at the phone, or a better coffee. Time saved in slivers does not aggregate into time worked in blocks, and the entire seven-figure edifice depends on pretending it does.
The survey layer
When the arithmetic looks too obviously assembled, the fallback is the survey: employees report saving four hours per week. That is a satisfaction score wearing a stopwatch costume. Ask someone who likes a tool how much time it saves and they answer with how much they like it, denominated in hours. Self-reported time savings inflate reliably, in one direction, and every vendor who runs these surveys knows it, which is why the actual survey question never appears next to the number. "Roughly how much time do you feel you save each week" and "log your time for two weeks" produce answers that differ by integer multiples, and only one of them fits on a slide.
What survives contact
Some numbers do survive procurement diligence, and they share one property: they are measured by the customer's own systems. Not the vendor's telemetry, not a survey the vendor wrote. They are smaller and duller than the slide, which is exactly why you can trust them.
| On the slide | What survives deployment |
|---|---|
| Hours saved per user per week | Helpdesk ticket categories that drop to zero |
| Seven-figure productivity gain | VDI seats retired, with their license and infra line items |
| Employees report saving 4 hours | Contractor time-to-provision, days to minutes |
| Faster, safer browsing | Incident counts in categories the browser controls |
Take them in order. Password resets, VPN client failures, "site broken in the approved browser" tickets: these exist as named categories in the customer's ticketing system with monthly counts, and when a category collapses after rollout, the helpdesk lead can pull the before-and-after without asking the vendor anything. A VDI seat retired because contractors now work in a managed browser is an invoice that stops arriving plus hardware someone decommissions, finance verifies it against actual spend. Time-to-provision a contractor going from shipping a laptop to sending a link shows up in the onboarding queue itself, days to minutes, and it is the single realest number in the category. Incident counts in the paths the browser actually controls come out of the SOC's own tooling, on the SOC's own definitions.
None of these will be seven figures in year one. All of them close renewals, because at renewal the internal champion has to defend the spend with figures a CFO can audit, and "employees feel faster" does not audit.
The buyer test
Two questions cut through most of it. First: for each number on this slide, did it come from your instrumentation or from the customer's systems? The vendor-instrumented ones are not lies, but they measure engagement with the product, not value from it. Second: what did these numbers look like for the deployment that churned? Every vendor has one. If the productivity metrics looked just as good for the customer who left, the metrics do not measure the thing that keeps customers.
I build in this category, at Ulaa, and I have sat on the vendor side of the slide while the multiplication got assembled, so this is not sniping from outside. I ship the category anyway, because underneath the manufactured number the dull ones are real. If you are evaluating an enterprise browser, ignore the hours-saved line, ask for ticket categories, retired seats, and provisioning time from a reference customer's own systems, and price the deal against those.