Use casesCustomer support

Build shared memory for AI customer support.

Pellam sells accounting software to small businesses and answers 1,900 tickets a week from Manchester and Lisbon. A drafting agent wrote the first reply on every ticket, and reviewers edited six in ten. Thirty days of memco on the billing queue changed what the reviewers spent their time on.

Listen: the Pellam deployment

3:44

Organisation
Subscription accounting software, 70-person support organisation
Agents in use
A triage and drafting agent built on Claude inside Zendesk; Claude Code in the support engineering team
Tools connected
Zendesk, Jira, Confluence, Slack
Pilot
The billing queue, both sites, thirty days
Memory networks
Pellam, support, one per queue, personal
Review gate
Human approval on policy insights; automatic on routing and product insights
Residency
Managed tenant in the EU. Customer records never enter memory.

01Starting point

Where Pellam started

Pellam's drafting agent reads the ticket, checks the Confluence knowledge base, proposes a reply and a resolution, and a reviewer approves or edits it before anything reaches the customer. The draft is good on the cases the knowledge base covers and poor on everything the desk knows and never wrote down: a pro-rata refund on an annual plan, a bank-feed defect that only shows on one tier, which complaints go to security before they go anywhere else.

The support operations lead measured a fortnight of the billing queue before connecting anything. Reviewers edited 61 percent of drafts. Nine corrections accounted for 38 percent of the edits, and most of those corrections had been made by the same reviewers the week before. One escalation in eight landed in the wrong queue. New reviewers took two months of shadowing to learn the desk's unwritten policy, and the agent never learned it at all.

The cost was rework and tone. Reviewers rewrote drafts they had corrected on Monday, again on Thursday. Policy boundaries were crossed in drafts and caught late, and once in a while not caught. Every model release reset the prompt tuning the support engineers had done. The desk was getting faster at correcting the agent and the agent was not getting better at Pellam.

02Day one

Day one

The drafting agent was connected over MCP in an afternoon. The policy desk spent two days writing the rules that must never drift. Nothing about the ticket flow changed for the reviewers.

  • The drafting agentMCP connection in the agent's configuration, knowledge-work domain. Before drafting, it retrieves what applies to the situation and how this kind of reply is normally written.
  • Reviewers in ZendeskSigned in through single sign-on. When a reviewer edits a draft, the agent proposes the lesson it has drawn and the reviewer saves, edits or skips it. Nothing is captured silently.
  • Jira and ConfluenceKnown defects and policy pages link to the insights that cite them, so a lesson can be traced to the ticket or the page it came from.
  • PoliciesTwelve rules written by the policy desk: refund windows, what never goes in a reply, what never goes in memory. Served to every agent on every draft and never re-ranked.
  • Claude Codememco plugin for the four support engineers who maintain the agent, so fixes to its behaviour are recorded alongside the desk's lessons.
  • SparkQueue networks, validation rules and the review queue set up by the support operations lead in spark.memco.ai.
  1. PellamPolicies: refund rules, data handling, the escalation map, the tone the brand allows.Every agent and every reviewer.
  2. SupportDesk procedure, handover format, incident conduct, how to cite a known defect.Every support agent and reviewer, both sites.
  3. Billing queue, one network per queueCase patterns, plan-specific edge cases, which fixes resolved which complaints.Agents and reviewers assigned to that queue.
  4. PersonalA reviewer's own phrasing preferences and shortcuts.That reviewer's agent only.

fig. 01Scope map

Pellam memory networksNested scopes: the Pellam network holding the twelve policies, the support network inside it, four queue networks inside that with the billing queue as the pilot, and personal networks per reviewer; an insight that mentions money waits for a human before it is served.PELLAMtwelve policies, never decaySUPPORTdesk procedureQUEUE NETWORKS, ONE PER QUEUEBillingTechnicalAccountsOnboardingPersonal · one per reviewer · phrasing and shortcutsHELDMENTIONS MONEYReads inherit downward · Writes stay local · Both sites read the same queues
Pellam memory networksNested scopes: the Pellam network holding the twelve policies, the support network inside it, four queue networks inside that with the billing queue as the pilot, and personal networks per reviewer; an insight that mentions money waits for a human before it is served.PELLAMtwelve policies, never decaySUPPORTdesk procedureQUEUE NETWORKS, ONE PER QUEUEBillingTechnicalAccountsOnboardingPersonal · one per reviewer · phrasingand shortcutsHELDMENTIONS MONEYReads inherit downward · Writes stay local · Both sites readthe same queues
Policies sit in the Pellam network and are served on every draft. Queue insights serve after five reviewed tickets. The dashed line is the hold: anything that mentions money, a deadline or a legal right waits for a person.

03The first weeks

The first weeks

The first useful lessons were corrections reviewers were already making. The difference was that each one was made once, previewed, and read by the next draft on either site.

fig. 02Deployment timeline

Pellam: baseline fortnight to readoutTimeline from the baseline fortnight through connection, the first reuse across sites on day five, the plan-scope mistake on day eleven, the refund window change on day seventeen and the readout on day thirty.BASELINE FORTNIGHTTHIRTY-DAY PILOTDAY 5First reuse, in LisbonDAY -14Baseline on thebilling queueDAY 0Agent connected;twelve policiesDAY 3Refund reply rewrittena fourth timeDAY 11Pro-plan lesson hits aStarter ticketDAY 17Refund window changes;two lessons retiredDAY 24Reopened-complaintruleDAY 30Readout: every queue
Pellam: baseline fortnight to readoutTimeline from the baseline fortnight through connection, the first reuse across sites on day five, the plan-scope mistake on day eleven, the refund window change on day seventeen and the readout on day thirty.Baseline fortnightThirty-day pilotDAY -14Baseline on the billing queueDAY 0Agent connected; twelve policiesDAY 3Refund reply rewritten a fourth timeDAY 5First reuse, in LisbonDAY 11Pro-plan lesson hits a Starter ticketDAY 17Refund window changes; two lessons retiredDAY 24Reopened-complaint ruleDAY 30Readout: every queue
Spacing is proportional to elapsed days. The filled mark is the first reuse: a correction made in Manchester applied by a draft in Lisbon.
  • Day 3. A reviewer rewrites a refund reply for the fourth time that week.Annual plans refund pro rata only within fourteen days of renewal. After that, offer credit, and route anything above the desk limit to a billing lead.Day five: a draft in Lisbon applies the rule to a ticket that Manchester taught it. First reuse across sites. The reviewer's weekly count of that correction goes from eleven to none.
  • Day 6. An agent proposes opening a new bug for a bank-feed export failure that Jira has tracked for a month.Bank-feed export failures on the Growth plan are defect PEL-4471. Link the ticket, send the workaround, and do not open a new issue.Duplicate bug reports from the desk stop. Engineering closes the loop by attaching the fix to the insight when it ships, and the insight retires itself.
  • Day 9. A draft about a shared invoice link reaching the wrong person is routed to engineering.Any ticket mentioning a shared link reaching the wrong person goes to the security queue first, never to engineering or billing.A policy, not an insight: written by the policy desk, served on every draft, never decays. Misrouted escalations on the billing queue fall from one in eight to one in forty.
  • Day 11. A refund lesson learned on the Pro plan is applied to a Starter plan ticket, where the rule is different. A reviewer catches it and says the agent is now wrong in new ways.Refund rules are scoped by plan. A lesson that names a plan applies to that plan only.The insight is split into two, each scoped. The support operations lead adds a validation rule: any insight that mentions money waits for a human. The reviewer approves the next week's billing insights herself.
  • Day 17. Pellam changes its refund window from fourteen days to thirty.Annual plans refund pro rata within thirty days of renewal, from 17 October. The fourteen-day rule is superseded.The policy desk updates the policy in the morning. By the afternoon memco has flagged the two insights that contradict it, and both are retired with the change as provenance. Before memco, the old rule would have survived in drafts for a month.
  • Day 24. A customer on a reopened complaint is told the clock has restarted.A reopened complaint keeps its original response deadline. State the original date in the first paragraph.Approved by the policy desk and served across both queues. Nothing in the knowledge base had ever said it; two senior reviewers had known it for years.

04Governance

Governance

  • The policy desk owns what must not driftRefund rules, data handling, escalation routes and brand tone are policies: written by people, served on every draft, never scored and never decayed. Insights can elaborate a policy. They cannot contradict one without being flagged.
  • Human approval where money or policy is involvedAn insight that mentions money, a deadline or a legal right waits for the support operations lead or a policy desk member. Routing and product insights serve automatically once they have held on five reviewed tickets.
  • Customer records stay in ZendeskThe agent reads the ticket where it lives. What reaches memory is the lesson: the plan, the pattern and the rule, never the customer's name, address or payment detail. Handover notes carry the ticket number only.
  • Scopes follow the queuesA queue network is readable by the agents and reviewers assigned to it. Site is not a boundary; Manchester and Lisbon read the same lessons. Personal networks never leave the reviewer.
  • Provenance, audit and retentionEvery insight links to the ticket, defect or policy page it came from. Every read, write, approval and retirement is logged. Insights with no reuse in ninety days are reviewed, and anything citing a closed defect retires when the fix ships.

fig. 03The write path

From a reviewer's edit to a draft on the other siteSwimlane showing a Manchester reviewer rewriting a refund reply, the drafting agent proposing the lesson for preview, the reviewer saving it, memco holding it for the support operations lead because it mentions money, then serving it to the billing queue where the Lisbon agent applies it on day five.REVIEWER,MANCHESTERDRAFTING AGENTmemcoDRAFTING AGENT,LISBONRewrites a refundreplyday 3, fourth timeProposes thelesson forpreviewSaves itVALIDATION RULEHeld: mentionsmoney; ops leadapprovesServed to thebilling queue,both sitesApplies it to arenewal ticketday 5
From a reviewer's edit to a draft on the other siteSwimlane showing a Manchester reviewer rewriting a refund reply, the drafting agent proposing the lesson for preview, the reviewer saving it, memco holding it for the support operations lead because it mentions money, then serving it to the billing queue where the Lisbon agent applies it on day five.REVIEWER, MANCHESTERRewrites a refund replyday 3, fourth timeDRAFTING AGENTProposes the lesson for previewREVIEWER, MANCHESTERSaves itmemco · VALIDATION RULEHeld: mentions money; ops lead approvesmemcoServed to the billing queue, both sitesDRAFTING AGENT, LISBONApplies it to a renewal ticketday 5
Nothing is captured silently: the reviewer sees the proposed lesson before it is saved. The dashed node is the hold for anything that mentions money.

05What compounded

What compounded

The thirty-day readout compared the billing queue with its own baseline fortnight and with the technical queue, which was not connected. The decision was to connect every queue in month two and to let the lowest-risk billing categories go out without review in month three.

MetricMovementWhy
First-pass acceptance39% to 64% sent uneditedThe technical queue, unconnected, moved from 41 to 43 percent over the same month.
Repeat-error rateNine corrections to twoThe two that remained were tone corrections, which the desk decided to keep as human judgement rather than write down.
Safe autonomous completion0% to 31% by month threeSafe autonomous completion on the billing queue: only the categories the policy desk listed, only within policy, and every one logged. Anything mentioning money above the desk limit still goes to a person.
Adaptation speedA month to a dayWhen the refund window changed on day seventeen, drafts were right by the afternoon and the contradicting lessons were retired the same day. Before memco a policy change took a month to reach every draft.
Cross-person or agent learning gainDay five, across sitesLisbon reused Manchester's lessons from day five. By day thirty, 70 percent of reused insights were applied on a different site from the one that learned them.
Improvement with experienceStill climbing, month threeA model update in month two changed the agent's phrasing and nothing else. The desk's lessons carried over because they were never in the prompt.

fig. 04Connected and unconnected

Drafts sent unedited, baseline to day thirtySlopegraph: the billing queue rises from 39 to 64 percent of drafts sent without a reviewer edit, while the unconnected technical queue moves from 41 to 43.BASELINEDAY 3041%39%64%43%Billing queue, connectedTechnical queue, unconnected
Drafts sent to the customer without a reviewer edit. Baseline fortnight and day thirty.

fig. 05Costs before it pays

Reviewer edits per hundred drafts, week by weekLine chart: reviewer edits on the billing queue fall from 61 per hundred drafts at baseline to 36 by week four, with week one almost unchanged.304561BASELINE5831WK 1WK 2WK 3WK 4MO 2MO 3Reviewer edits per 100 drafts, billing queue
Edits per hundred drafts on the billing queue, against the baseline fortnight. Week one barely moved; the memory was mostly seed.

06What it cost

What it cost

  • Setup timeA fortnight measuring the billing queue before anything was connected. One afternoon to connect the agent over MCP and sign the reviewers in. Two days for the policy desk to write twelve policies.
  • Who ran itThe support operations lead and one support engineer. Reviewers spent about fifteen minutes a day on proposed lessons in month one, five by month three. No new team.
  • Licence and tokensThe Team plan for 70 members. The drafting agent's token use rose seven percent from reads and second drafts fell by half. The larger saving was reviewer time: about 45 hours a week by day thirty, on one queue.
  • What it replacedThe desk wiki nobody updated, the two-month shadowing period for new reviewers, and the prompt retuning after every model release.

See what your support agents learn in a month.

Join the waitlist

More deployments.

All use cases