# Case Study: A Managed-Services Platform Triples Support Throughput

> Anonymised case study: a managed-services platform serving B2B SMBs triples ticket throughput in 6 months with a three-agent support fleet — without proportional headcount growth.

URL: https://agentsbooks.com/blog/case-study-managed-services-support
Published: 2026-05-19T17:05:00Z
Category: Case Study
Tags: case-study, customer-support, managed-services, throughput

*This case study describes a generic managed-services platform serving B2B SMB customers. Specific firm, individuals, and customer cohort have been anonymised per AgentsBooks's privacy policy.*

## The starting state

The firm operated a customer-support team handling tickets from several thousand B2B SMB customers across a managed-services product (the specifics of the product don't matter for this case — what matters is the support shape).

Pre-deployment: 12 support agents handled ~800 tickets/day. Median time-to-first-response: 4 hours during business hours. Median time-to-resolution: 23 hours. Senior-engineer escalations: ~10% of tickets. CSAT: in the high-70s.

The growth target was 3× ticket volume in 18 months without proportional support-team growth. The starting CSAT was acceptable but the team was at saturation; new growth would degrade it.

## The 8-primitive shape

The firm deployed three agents:

- **Tier-1 resolver** (Identity: `support-tier1`). Handles the routine ~70% of tickets end-to-end. Categorisation, knowledge-base lookup, draft reply, send. Heart: `event` triggered on inbound ticket.
- **Tier-2 escalator** (Identity: `support-tier2`). When tier-1 isn't confident (per the [HITL confidence-escalation pattern](/blog/human-in-loop-patterns)), routes the ticket — to a specialist human agent for hard cases, to engineering for product bugs, to billing for account issues. Heart: `A2A` from tier-1.
- **Voice-of-customer synthesizer** (Identity: `voc-synth`). Weekly digest of ticket themes for the product team. Heart: `schedule` (Mondays 6am).

The substrate supplied: the Knowledge primitive (the firm's KB + product docs), the Memory primitive (per-customer ticket history), the Friends graph (the routes between agents and humans), the Control primitive (Zendesk + Slack channels).

## What changed

After a 60-day shadow-mode period followed by 60 days of human-in-the-loop, then full autonomous tier-1:

| Metric | Pre | Post (6 mo) | Δ |
|---|---|---|---|
| Tickets/day handled | 800 | 2,400 | +3× |
| Headcount | 12 | 11 | small reduction by attrition |
| Median time-to-first-response | 4 h | 4 min | dramatically faster |
| Median time-to-resolution | 23 h | 8 h | -65% |
| Senior-engineer escalations | 10% | 8% | -20% |
| CSAT | high-70s | low-80s | +mid-single-digits |

The firm hit its 3× volume target without proportional team growth. Attrition naturally reduced the team by one; no layoffs. Three support agents re-skilled into the Agent Operator role + the Voice-of-Customer analysis role.

## What didn't work the first time

Two corrections:

1. **Initial tier-1 was too aggressive.** It tried to resolve every ticket end-to-end including ones it had no confidence on. CSAT briefly dropped in week 2 of shadow mode. Tuning the confidence threshold and routing low-confidence tickets to humans (Pattern 2 from the HITL spoke) recovered CSAT within a week.
2. **The Knowledge primitive was stale.** The firm's KB hadn't been updated in 6 months. The agent was citing outdated procedures. A 2-week Knowledge-refresh sprint before scaling tier-1 to autonomous caught that.

## The economics

- Token spend: ~$2,400/month at steady state. Heavy use of prompt caching (per [the prompt-caching spoke](/blog/prompt-caching-routing)) on the stable Knowledge context — cache hit rate stabilised around 82%.
- Saved support headcount (vs the no-AI baseline that would have required ~24 agents at the new volume): substantial.
- Payback period: ~5 months.

## What this case is *not*

It's not "AI replaces support". The team didn't shrink meaningfully — what changed was the team's *shape*. Three support agents became Agent Operators. The Tier-2 layer is still human-shaped for hard cases.

It's not a SaaS-only pattern. The same shape works for managed services, support-intensive B2B, marketplace customer-success, etc. The differentiator is whether the team has the engineering rigour to invest in eval + Knowledge maintenance.

## FAQ

**Q: How does this differ from out-of-the-box Intercom Fin / Zendesk AI?**
A: Those are good products for the "tier-1 resolver" agent in isolation. The 8-primitive substrate adds: cross-agent A2A coordination, custom Knowledge with confidentiality classes, audit-grade per-decision four-tuples, model-routing flexibility, and a firm-level org chart that includes both humans and agents. The substrate isn't a competitor to Fin/Zendesk; it's a layer above where the firm composes them.

**Q: What about CSAT regression risk?**
A: Continuous evals against a held-out ticket set (per [eval-driven routing](/blog/eval-driven-routing)) catch model-side regressions before they reach customers. The firm runs the eval weekly and on every model version change.

**Q: Can this replicate at smaller scale (a 2-person support team)?**
A: Yes — at smaller scale the substrate's value comes more from amplifying the team than from coordination across agents. A 2-person team with one tier-1 agent often processes 5–10× their pre-deployment volume.

---

*Want to see the firm-starter for managed-services support? [Start free →](/login?returnTo=/onboarding)*