Support Operations Waste Assessment

What this is, precisely

We examine one function — support operations — using your own data. We identify where effort and money are going, price each pattern with the arithmetic shown, rank what is worth fixing against what is not, and hand the whole thing to you in a working session with your support leadership.

Delivery is fifteen business days, counted from the day we have complete data, not from the day you sign.

You end the engagement with a decision you can defend in a budget conversation. You do not end it with a dependency on us — we do not implement, and the recommendations are written to be executed by your own team.

The problem this addresses

Support is the function where cost most easily hides, because so little of it stays on the support line.

Escalations consume engineering hours that are booked to engineering. Tooling is split across owners. Ramp time for new agents is booked to headcount. Credits and goodwill refunds land in revenue. Each fragment is individually defensible; the total is never assembled. So when support asks for more people, there is nothing to test the request against — the alternative to hiring has never been priced.

Meanwhile the operation accumulates the ordinary sediment of growth: questions answered repeatedly because the answer was never written down, requests that travel by three different routes depending on who receives them, tools bought to solve a process problem, and judgments that live in two people's heads.

None of this is a crisis. It compounds quietly, and it is expensive.

What gets examined

Six evidence sources, read against one another. Most of what matters shows up in the places where they disagree.

• Ticket and conversation data — volume and drivers, repeat contacts, reopen rates, handling time by category, seasonality
• Workflow and handoff paths — how a request actually travels end to end, including the informal routes that were never designed
• Tooling — what is licensed, what is actually used, what functionally overlaps, what is paid for twice
• Documentation — coverage, currency, findability, and which answers exist only in someone's memory
• Escalation into engineering — the hours that leave support and never get counted against it
• Decision points — where work waits on a judgment that only one or two people are able to make

What you receive

• Priced waste account — every material pattern found, its estimated annual cost, the method used to derive that figure, and how confident we are in it. Estimates are labelled as estimates.
• Prioritised shortlist — what to fix first, sequenced by return against effort and risk, each with a suggested internal owner.
• Do-not-fix list — what we found and recommend leaving alone, with the reasoning. It carries the same evidence standard as every other section of the report.
• Decision briefing — a working session with you and your support leadership to walk the findings and pressure-test the sequence before you commit to anything.

Written for a finance audience, specific enough for support leadership to act on Monday.

Request a fit conversation →    Inspect the worked example first →

Not ready for either? The calculator gives you a rough number in ten minutes without talking to anyone.

Where the engagement stops

Stated in full, because the boundary is the product.

• You implement, we diagnose. We find the patterns, price them and sequence them. Your team builds, configures, migrates and staffs — and the recommendations are written for them to execute.
• The engagement ends at the briefing. We hand over the findings and walk them with you. Running, supervising or embedding in your support function stays with you.
• Scope is support operations, and it stays there. If the evidence points somewhere else we will tell you, and leave it outside this engagement.
• We sell no software and hold no vendor relationships. There is nothing in the report we profit from you buying.

What we need from you

The engagement is only as good as the data, so the requirements are specific and they are not optional.

• Ticket metadata covering up to 12 months — the facts about each ticket rather than what was said in it: volume, queues, tags, timestamps, who it was assigned to, whether it was reopened. We do not ask for message contents, customer names or email addresses by default.
• Current support tooling list with licence counts and annual cost
• Access to existing documentation, macros, and knowledge base
• Team roles and staffing levels with cost bands — fully loaded cost (pay plus taxes, benefits and overhead) in ranges, not individual salaries or a named roster
• Roughly 6–8 hours of your support leadership's time, plus short conversations with a sample of the team

Where metadata genuinely cannot answer a question, we may ask for a limited sample of conversation content — agreed with you in advance, scoped to the specific question, and reduced or de-identified where reasonably possible. Full detail of what we ask for, how it is stored and when it is deleted is on How we handle your data.

How scheduling works. We reserve a start date for you. The required data is due approximately five business days before that date, and we check it for completeness promptly on arrival. If something is missing or incomplete, we will tell you immediately and work with you to close the gap — but if it cannot be closed in time, the reserved start moves. We would rather move a date than run an assessment on partial evidence and hand you a number you cannot defend.

The fifteen business days begin when the data is complete.

Who this is for

• Software companies where support has grown faster than the process around it
• A CFO or equivalent — someone who controls the budget and can act on what the findings say
• Support leadership willing to give straight answers about how the work actually runs
• Support teams of roughly eight people or more

We would turn the work down if you need the fixes carried out rather than identified; if the underlying trouble is product quality rather than support process; if the required data cannot be pulled; or if there is no one senior enough to act on the result. We would rather establish this on a first call than three weeks in.

Questions a CFO usually asks

Why fifteen days? Because the scope is narrow and fixed. We examine one function, using data you already have, against a method already built. In a longer engagement most of the elapsed time goes on working out what the engagement is — we removed that by doing one thing only.

How do I know the numbers are real? Every figure arrives with its derivation and a stated confidence level, and estimates are labelled as such. The test we hold ourselves to is whether a finding would survive your own finance review. If it wouldn't, it doesn't ship. You can see the reasoning style in advance — the Workaround Tax Calculator shows its arithmetic for exactly this reason.

What does it cost? Fixed fee, agreed in writing before anything starts. We scope it on the fit conversation once we know the size and shape of your operation, and there is nothing variable or hourly in it.

What if you don't find anything worth the fee? Then we will tell you that, and say so in the briefing. It is a real outcome and you should factor it into the decision. It is also why we would rather disqualify you on a first call than take an engagement we do not believe in.

Do you implement the recommendations? No. That is a deliberate constraint — it removes any incentive for us to inflate findings in order to sell a build phase.

Who needs to be involved? You or your equivalent as the decision-maker, and your support leadership as the operational stakeholder. The rest is a few short conversations with people doing the work.

Next step

Request a fit conversation. We will ask what your support operation looks like, tell you whether an assessment would be worth your money, and scope the fee if it would. If it wouldn't, we will say so and point you at whatever is actually useful.