Sample engagement · Customer support
Anonymized profile of the kind of company we build for. Same shape an actual engagement takes — discovery, build, shadow, cutover — with the architecture, integrations, and target outcomes we’d commit to.
The client (anonymized · “Frame”)
ARR
$4M
B2B SaaS, dev-productivity tools
Headcount
32
NYC, remote-friendly
CSM team
4
covering 180 paying accounts
Stack: Zendesk for support, Notion for the knowledge base, Slack for routing, Postgres for product data, Hubspot for accounts. Sound like ~30% of the companies we talk to.
The bottleneck
14 hours per CSM, every month, on work the team would describe as “answering the same five questions.” That’s the spend we’d quote against.
Repeating questions whose answers already live in the docs and in past tickets. The agent reads the same questions over and over.
Decide whether it’s billing, engineering, or onboarding. Find the owner. Pass it on with context. Median 15 minutes per ticket.
Multiple tickets with the same underlying issue, each one written-up from scratch. The triage doesn’t see the pattern.
Cost of inaction
56 hrs/mo × $80/hr loaded labor = $4,480/mo of toil.
Median first-response time sits at 6h 12m against a 4h SLA. Customer-impact on NRR isn’t measured — that’s the first thing discovery instruments.
What we’d ship
Every decision the agent makes is logged with input, output, model version, and prompt version. Audit trail is the floor, not a feature.
Incoming ticket (Zendesk webhook)
│
▼
┌─────────────────────────────────┐
│ Classifier (Claude Haiku) │
│ fast · cheap · ~120ms p50 │
└──────────────┬──────────────────┘
│
┌───────────┼────────────┐
▼ ▼ ▼
[ KB-answer ] [ Routing ] [ Escalation ]
│ │ │
▼ ▼ ▼
Drafts reply Posts to Hands to
with cited right Slack human with
KB anchors channel + full context
→ CSM 1-click owner tag window
approve
│
└──────────────┐
▼
Postgres run-log
(latency · accuracy
· override rate)Integration footprint
| Tool | What we need | Who sets it up |
|---|---|---|
| Zendesk | API key + ticket-update permissions | Client (~15 min) |
| Notion KB | Internal integration token, scoped to KB workspace | Client (~10 min) |
| Slack | Bot token, scoped channels | Client (~10 min) |
| Hubspot | API key, read-only contacts/companies | Client (~10 min) |
| Postgres | Connection string in dedicated schema (theirs or ours) | Discussed at discovery |
Engagement timeline
If we hit end of week three and metrics don’t justify cutover, we run a kill review — not a rescue.
Spec + quote in your Google Docs.
Agent runs on staging Zendesk, no outbound traffic yet.
Baseline metrics. Prompt v2.
Retainer kicks in only if 4-week metrics hit baseline.
Target outcomes (per discovery framework)
| Metric | Baseline | After 4 wks | After 12 wks |
|---|---|---|---|
| CSM hours / month on Tier-1 | 56 | 32 (–43%) | 14 (–75%) |
| Median first-response | 6h 12m | <90 min | <30 min |
| Tier-1 deflection rate | 0% | 50–60% | 70%+ |
| Misroute rate (wrong team) | 18% | <8% | <4% |
These are targets per our discovery framework, not gold-standard results from delivered work. Different baselines, different attainable numbers — that’s what discovery measures.
Pricing — applied to this scope
Compare to the bottleneck: 56 hrs × $80 × 12 weeks = $53,760 of toil over the same window. Pay-back inside the first 4–8 weeks if targets hit.
What we won’t do
That’s your decision after the metrics earn it — not our default.
ROI is too shallow. We’ll say so in discovery and you keep the spec.
Each step is its own prompt + log. Debugging is readable, not archaeological.
Code, prompts, logs are yours. Handover is a one-week doc, not a renegotiation.
Your version of this engagement