Ticket volume is climbing, the team's underwater, and the instinctive fix is the same one it's always been: open a req. Hiring is a completely reasonable answer to a real capacity problem. But it's also the slowest, most expensive lever in the toolbox — and it's worth running one checklist before you post the job, because a growing backlog is often a process and tooling gap wearing a capacity-problem costume.
Before you post the job
- Have you actually categorized what's in the backlog? "We're behind on tickets" isn't a diagnosis. Pull a week of tickets and sort them — how many are genuinely novel judgment calls versus how many are a version of the same five questions?
- Do you know what fraction is repetitive? If a meaningful share of the backlog is structurally the same request over and over (order status, password resets, basic account questions), that's the exact shape of problem automation solves well — and hiring solves it by paying a person to do the same repetitive thing, indefinitely.
- Have you calculated what the backlog is actually costing you? Hours/week on repetitive tickets × blended hourly cost gives you a real monthly number to compare against a new hire's fully-loaded cost — not a guess.
- Have you priced out the full cost of the hire, not just the salary? Recruiting time, onboarding, ramp-up to full productivity, management overhead — a new rep's real cost and real time-to-value is usually 2-3x what the offer letter says, and further out than it feels.
What automation can absorb vs. what still needs a person
This isn't an "AI replaces support" argument — it's a capacity-allocation argument. The honest split looks like this:
Good fit for automation
- High-volume, repetitive requests
- Structured, predictable inputs
- A known, correct answer exists
- Answer depends on data you already have (order status, account state, docs)
Still needs a human
- Novel or ambiguous situations
- Emotionally sensitive conversations
- Judgment calls with real exceptions
- Anything outside a known, bounded set
A new hire covers both columns, at full headcount cost, for as long as they're employed. A scoped automation build only ever targets the left column — which is usually exactly the part of the backlog making the job miserable for the humans handling the right column too.
The math, side by side
In a comparable support-triage build — the same one broken down here — the system took about three weeks to design, build, and deploy, and it absorbed the repetitive slice of an e-commerce support queue at scale:
Compare that timeline and outcome against a typical hiring cycle: weeks to source and interview, more weeks to onboard and ramp, and then a permanent addition to monthly payroll that only ever handles one queue at a time — versus a system that, once built, keeps absorbing that same repetitive volume indefinitely at no added headcount cost.
The question isn't "AI or a human." It's whether the next hire's day one responsibility should be doing something a system could already be doing by the time that hire finishes onboarding.
When hiring is still the right call
None of this means never hire. It means hire for the right reason:
- Your backlog is mostly genuine judgment calls — low on repetitive volume, high on nuance — automation won't move the needle much here.
- You're scaling relationship-driven support where the human touch is the product, not a cost to minimize.
- You've already automated the repetitive slice and the remaining backlog genuinely needs more people, not more process.
In all three cases, running the automation math first doesn't cost you the hire — it just makes sure the hire you make is doing work that actually needs a person, instead of quietly absorbing what a two-week sprint could have handled.
Not sure which bucket your backlog falls into?
Answer 6 quick questions and get a free, personalized estimate of what automation could realistically recover before you decide.