Case Study Skeleton: Email Ops Agent for a Mid-Market Retailer
Status: SKELETON. Sections marked [PILOT DATA] are populated only with measured results from an actual engagement — never estimated.
The client
Mid-market online retailer, ~400 support emails/day across orders, returns, and wholesale inquiries. Two-person team drowning in the inbox. [CLIENT NAME PENDING CONTRACT]
The problem
- Median first-response time: 9 hours; SLA target: 2
- 70% of volume is repetitive (order status, return policy, invoice copies)
- Overtime costs spike every Q4
What we deployed
An Email Operations Agent running our standard loop, wired through:
- a provider adapter (IMAP/API) for inbox access — swappable without core changes
- a draft-and-approval gate: no outbound email leaves without passing rule checks (recipient allowlist, banned-content patterns, length caps) and human sign-off above sensitivity thresholds
- daily quality reports: resolution rate, escalation rate, lesson-application
Results framework (fill during/after pilot)
| Metric | Before | After | Source |
|---|---|---|---|
| First-response time (median) | [PILOT DATA] | [PILOT DATA] | ticket timestamps |
| % fully handled by agent | — | [PILOT DATA] | loop logs |
| Approval-gate rejections caught | — | [PILOT DATA] | gate audit log |
| Human hours freed / week | — | [PILOT DATA] | client timesheets |
| Cost per resolved email | [PILOT DATA] | [PILOT DATA] | token ledger |
Why the approval gate matters
Trust is the product in email automation. Our contract is simple: the agent can read anything but send almost nothing without passing explicit rules. Every sent message is attributable to a draft ID, a gate verdict, and a loop cycle.
Lessons learned section
[POST-PILOT: list top 3 lessons from data/loops/<project>/ — real ones, verbatim.]