How to Measure How Much Build Time Support Costs You

To find out how much build time support costs you, track every support session for two weeks. Log the time spent on replies, the work that follows from them (reproducing bugs, checking logs, updating docs) and how often support breaks into your focus blocks. Add those up and you get two numbers: direct support hours and fragmented build hours. Their sum is the true cost. You can then express it in money or in shipped work.

The rest of this post shows how to do that without much effort, which numbers to calculate, and what research does and doesn't say about the hidden cost of interruptions.

Why "time spent replying" isn't the full cost

Most founders guess their support time by thinking about the replies. That misses two parts of the cost.

1. Follow-up work. A short email like "export is broken" can turn into an hour of reproducing the bug. Zendesk's definition of average handle time counts follow-up and after-contact work as part of handling a request, not just the time spent writing.

2. Fragmentation. Support breaks up the long stretches that development needs. Paul Graham's essay Maker's Schedule, Manager's Schedule argues that makers work best in blocks of at least half a day, and that "a single meeting can blow a whole afternoon." A support thread you answer mid-afternoon can work the same way.

Research supports this, with some caveats:

• Gloria Mark and colleagues observed 24 information workers and found that 57% of their "working spheres" were interrupted. Interruptions from outside the current task context were the most disruptive.
• A later lab study, The Cost of Interrupted Work, found that people finished interrupted tasks faster and with the same quality. But they reported more stress, frustration, time pressure and effort.

A note on the "23 minutes to refocus" figure: You'll see it quoted often, but it doesn't line up neatly with the published papers. The 2005 fieldwork describes how long interrupted tasks waited before people went back to them, usually with other tasks done in between. That is a scheduling observation, not a measure of how long your brain takes to refocus. Rather than borrowing someone else's number, measure your own switching overhead using the method below.

Step 1: Set up a simple support log

You don't need special software. A spreadsheet with one row per support session is enough. A session is any stretch where you deal with support, whether it's one email or ten.

If you use a help desk, check whether it already tracks time. Zendesk, for example, has a Time Tracking app and reporting options for handle time. Plain timers or calendar blocks work fine too.

Track for at least two weeks. One week can easily be skewed by a launch, a bad release or a quiet holiday.

Step 2: Calculate the direct cost

At the end of the period, work out these figures:

• Direct support hours per week = total of (end − start) + follow-up minutes, divided by the number of weeks
• Average time per ticket = total direct support minutes ÷ tickets handled
• Repeat share = tickets marked "Repeat" ÷ total tickets
• Time by type = direct minutes grouped by bug, how-to, billing, and so on

Time by type tells you what's driving the cost. Lots of how-to time usually points to gaps in docs or onboarding. Lots of bug time is often a product quality issue that shows up in your inbox.

Step 3: Calculate the fragmentation cost

This is the part people skip, and it's often the bigger number.

• Interruptions per week = sessions marked "Interrupted a build block"
• Switching overhead per week = sum of "Minutes to get back into code" for those sessions
• Fragmented build blocks = number of focus blocks that got split into pieces too short for hard work

A useful rule: if an interruption leaves you with less than an hour before your next commitment, count the rest of that block as lost to switching, not just the minutes you spent on the reply. This is a judgment call, not a research finding. Apply it the same way every time so your numbers stay comparable from week to week.

Total weekly support cost (in hours) = direct support hours + switching overhead + time left over in blocks that got broken into unusable pieces

Step 4: Translate hours into something you can decide with

Raw hours are easier to act on once you convert them. Pick one or both:

In money: Weekly support cost in hours × your effective hourly rate. If you don't pay yourself a salary, use what you'd charge as a contractor, or what it would cost to hire someone for that work.

In product terms: Compare total support hours to your typical build hours per week. "Support takes about a quarter of my build week" is often more useful than a dollar amount when you're deciding what to change.

A hypothetical example

The numbers below are made up to show the calculation. They aren't real data.

A solo developer logs support for two weeks and finds:

• 9 hours of reply time and 4 hours of follow-up across 70 tickets → 6.5 direct hours per week, about 11 minutes per ticket
• 40% of tickets marked as repeats, mostly about password resets and exporting data
• 12 sessions that interrupted build blocks, with an estimated 15 minutes each to get back into code → 3 hours of switching overhead over two weeks, or 1.5 hours per week
• 4 afternoons fragmented into leftover gaps judged too short for hard work, about 2 hours each → 8 hours over two weeks, or 4 hours per week

Total: roughly 12 hours per week, compared with about 6.5 hours if they'd only counted replies. Nearly half the cost comes from fragmentation.

Step 5: Use the breakdown to pick a fix

Different parts of the cost call for different fixes. The suggestions below are recommendations, not proven results:

• High fragmentation cost: Batch support into fixed windows, such as first thing in the morning and late afternoon. This is the same idea as Graham's "office hours." Turn off inbox notifications during build blocks.
• High repeat share: Write help articles, saved replies, or in-app hints for the top repeat questions. Then check the repeat share again in a month.
• High follow-up time on bugs: Better error messages, logging, or a bug report template can cut down on investigation time.
• High time per ticket on unique questions: Drafting help may be useful here. AI drafting tools, including the one we're building at SupportMe, aim to write a first draft so your time goes into reviewing and editing rather than writing from scratch. Whatever tool you try, measure it with the same log. Include the time you spend editing drafts so you're comparing like with like.

Step 6: Re-measure on a schedule

Support load changes with releases, pricing changes and growth. Repeat the two-week log every quarter, or after any big change to your process. Compare:

• Total weekly support cost (hours)
• Repeat share
• Interruptions per week
• Average time per ticket

Zendesk notes that the goal of handle time metrics isn't just to lower them but to resolve issues well. Keep an eye on quality too, such as how often customers have to follow up because the first answer didn't solve the problem.

Conclusion

The cost of support has two parts: the time you spend handling tickets, and the build time lost when support breaks up your focus. Log both for two weeks, add follow-up work and switching overhead to reply time, and convert the total into hours, money, or share of your build week. The breakdown shows whether you need fewer interruptions, better docs, sturdier code, or faster drafting. Measuring again later shows whether the change helped.

References

• Mark, G., González, V. M., & Harris, J. (2005). No Task Left Behind? Examining the Nature of Fragmented Work. CHI '05.
• Mark, G., Gudith, D., & Klocke, U. (2008). The Cost of Interrupted Work: More Speed and Stress. CHI '08.
• Graham, P. (2009). Maker's Schedule, Manager's Schedule.
• Zendesk. What is average handle time (AHT) and how do you calculate it?
• Zendesk Help Center. Time tracking and handle time reporting
• Cerebra. Apparently, it takes 23 minutes and 15 seconds to refocus after an interruption