Support load is not a property of how well you build — it is mostly a property of what the product touches. Hold the price and the income constant and only vary the vertical, and the weekly support hours move by a factor of 6.6: from 1.9 hours a week to 12.6, which is 79 per cent of a nights-and-weekends week before anything is built. The minutes below are our estimates and the page says so throughout.
Six verticals, one price, very different weeks
At $49 a month against $4,000 of income you need 82 customers. What those 82 customers cost you depends on what they are asking about:
| Vertical | Minutes per customer | Hours a week | Band | Why we estimated that |
|---|---|---|---|---|
| SaaS metrics & analytics pains | 6 | 1.9 | light | Read-only dashboards; a wrong number is annoying, not urgent |
| Content & creator pains | 10 | 3.1 | moderate | Single-player output; mistakes are visible immediately and fixed by the user |
| Booking & scheduling pains | 18 | 5.7 | moderate | Two parties and a calendar; every edge case involves somebody else's time |
| Invoicing & payments pains | 30 | 9.4 | heavy | Touches money, so every question is urgent and none can be deferred |
| Real-estate & property pains | 35 | 11 | heavy | Imported listings and third-party feeds, which break without anyone being at fault |
| Small-agency operations pains | 40 | 12.6 | heavy | Multi-party and about other people's money — the two drivers stacked |
The hours and the bands are computed by the same function behind the support calculator. The minutes are ours — estimates, not measurements, which is why each one is published with its reason attached rather than on its own. Change a minute figure you disagree with and the row recomputes; that is the intended use.
3 of the six land in the band where support is the job rather than a cost of doing it. Nothing in that column is about how hard the software is to write — it is about how much of somebody else's mess the product agrees to absorb.
The three drivers, which are more useful than the ranking
The ranking depends on our estimates. The mechanism behind it does not, and you can apply it to a vertical that is not in the table.
- Does it touch money? A question about an invoice, a payout or a charge is urgent by definition, cannot be deferred to a documentation page, and arrives with an annoyed customer attached.
- Does it import somebody else's data? Feeds, integrations, exports, uploads. These break without anyone doing anything wrong, which means the ticket volume is not a function of how good your software is. You inherit the failure rate of every system you read from.
- Does it coordinate more than one party? The moment a second person is involved — a client, a guest, an assistant — every edge case involves somebody else's time, and "just re-send it" stops being an acceptable answer.
Against our own estimates the three are not equally expensive, and the ordering is not the one we expected when we wrote them down:
Mean estimated minutes for the rows with each driver, divided by the mean for the rows without it. Computed from the table rather than asserted — an earlier draft called money the biggest multiplier and the arithmetic says it is the smallest of the three. What the division cannot do is escape its inputs: the minutes are our estimates, so these factors describe how we expect the drivers to behave, not a measurement of how they do.
So the one we would fear is coordinates more than one party at 3.8 times, not the money — an ordering that comes out of our own estimates and is the first thing to overwrite with a month of your own inbox. Then count how many of the three your idea has and check the count against the hours:
Mean hours at each driver count, computed from the rows above rather than asserted. The trend holds at the top of our own estimates, and the count does not order the rows cleanly: there are 2 places where a row carries fewer drivers than the one below it, and it does not separate the heavy rows from the rest either — one two-driver vertical lands heavy and another does not.
Both inversions are left in on purpose. A read-only analytics product reads somebody else's data — one driver — and still generates fewer tickets than a single-player writing tool with none; and a property product with two drivers lands above an invoicing product with three. Urgency and volume are not in the count. Reordering our estimates to make the mechanism look tidier would have been fitting the numbers to the story.
So the count is a rough warning, not a ranking and not a band. Zero or one is a product one person can run for years; two or three is a business that will need somebody answering messages long before it needs another feature — and which of the two or three you have matters more than how many.
The lever is the price, and the arithmetic is unforgiving about it
The obvious response to a heavy row is to reduce the minutes — better onboarding, more docs, fewer edge cases. Worth doing, and it moves that column slowly.
The fast lever is the other one. The worst row here sits at 12.6 hours a week at $49. Raise the price to $79 and the same income needs 51 customers instead of 82 — support falls to 7.8 hours a week and leaves the heavy band, with no change to the product at all.
That is the same finding the pricing arithmetic reaches from the other side: fewer, better-paying customers is not merely more money, it is fewer hours. In a support-heavy vertical it is the difference between a business that fits a week and one that does not.
What these numbers are not
They are not measurements. Nobody has instrumented a support inbox per vertical and published it, including us, and a page that presented estimates as benchmarks on this site would be arguing against itself.
What is real is the arithmetic on top of them and the band boundaries, which are calibrated to a solo founder's week rather than invented for this page. Use the table as a shape — the ordering and the size of the gaps — and replace the minutes with your own the moment you have ten customers and a real inbox to count.
One honest caveat about your own first estimate: it will be low. The tickets you imagine are the ones you designed for. The ones that arrive are the misconfiguration, the stale integration and the customer who did something nobody anticipated.
The short version
- Same price, same income, six verticals: 1.9 to 12.6 support hours a week, a factor of 6.6.
- Money, imported data and multiple parties are the three drivers, and against our own estimates the biggest is coordinates more than one party at 3.8 times, not money at 2.
- 3 of six land where support is the job. That is a property of the vertical, not of your engineering.
- Raising the price from $49 to $79 pulls the worst row out of the heavy band without touching the product.
- The minutes are ours and they are estimates. The arithmetic is not. Replace them as soon as you have a real inbox.