Customer support
The resolution desk.
Our agents fix what the ticket is about. They issue the refund, correct the order and reproduce the fault, then tell the customer it is done.
A ticket
The work
Reply
-
- Telemetry · E-41 at cold start
- Replica · fault reproduced
- Controller · start delay set
- Engineering · failing test filed
Line 2 is running again. We reproduced E-41 on a copy of your setup and changed a start-up setting on your controller.
-
- ERP · order 5530 held · old address
- Transport · ships today
Your replacement had been held on an old address. It ships today, tracking attached.
-
- ERP · 88412 repeats 88397
- ERP · credit note posted
We credited the second invoice. Credit note attached.
Sent 6 minutes later
Every sentence in this reply had already happened.
Under their service contracts, the 212 other controllers on firmware 4.2 got the same setting within the hour. 37 more duplicate invoices were credited. Those customers never had to write.
Faults
Your engineers start from a failing test.
The desk reproduces the fault on a replica of the customer's setup. Engineering gets the failing test and every account that shares it.
Software products
- For software, the replica is a copy of the customer's tenant: their version, their settings and their data with personal fields masked.
- The failing test lands in your repository as an ordinary test, so your CI tells the desk when the fix is in.
- The desk writes to each affected customer when the release reaches them, not when it is merged.
Closed
The ticket closes when your systems confirm the fix.
- 6 min Reply sent
- Day 1 Credit settled
- Day 2 Controller delivered
- Day 6 Firmware fix installed
- Day 13 Seven days without E-41
- Closed
No agent marks it solved. When a case reopens, the reason becomes a test that every past case must pass before the change ships.
What counts as a check
- A payment settled in your ERP, not a credit note drafted.
- A delivery scanned by the carrier at the customer's site.
- Telemetry quiet for the period your product team sets per fault.
- A release version reported by the device or the tenant itself.
- A customer reply that confirms, when the fix is something only they can see.
Your team
Your support leads set the limits once.
- Credit
- Up to 2 % of contract value
- Parts
- On warranty, checked by serial
- Settings
- Changed remotely under the contract
- Calls
- Key accounts also get a personal call
Your people take the cases that need judgement, with everything the desk found.
The limits as code
Each limit is code with tests. Change a limit and every agent follows it on its next case.
support/limits.py
credit.limit = 0.02 * account.contract_value
def can_ship_part(case):
return warranty.valid(case.serial) and stock.confirmed(case.part)
if account.tier == "key":
ask(account.owner, to="call", case=case) # the fix does not wait for the callArchitecture
-
Operating Code
Limits, playbooks and closing checks run as tested code.
- support/triage
- support/entitlement
- support/fault
- support/replica
- support/parts
- support/billing
- support/reply
- support/close
- support/limits
- support/memory
-
Gate
Each agent has its own identity. Every write needs a grant and is recorded.
-
Your infrastructure
Memory per case, account and product, on your servers or on Marbell Cloud in Switzerland.
-
Fleet
Agents take each case from triage to closed. A restarted agent never ships a part twice.
For your engineers
- Operating Code is what a support veteran knows, written as code. A goodwill rule is an if and a troubleshooting playbook is a loop. An account's history is a typed variable and a closing check is a test. It grew out of the recursive self-improvement harness our own persistent agents run on.
- When a case reopens, the desk writes the check it missed, replays it on every past case of that class and ships the change when the suite passes. Your leads can rerun any case and see what changed.
- Replicas are built from the installed-base record: model, firmware, configuration and the telemetry around the fault.
- On a call the desk reads the live transcript, checks the contract and books the exchange before the caller hangs up.
- Every action carries a key built from the case, its state and the action, so a restarted agent never sends a second credit note.
- A failed action is retried twice from its checkpoint, then rerouted by the coordinator.
Gate policy
Grants are written per case class and per resource. Withdraw a grant and the agent's next request is denied.
// Gate policy (Cedar)
permit (principal in Agents::"desk", action in [Action::"read", Action::"draft"], resource in Support::"all");
permit (principal in Agents::"billing", action == Action::"credit", resource is Invoice)
when { resource.amount <= resource.contract.value * 0.02 };
forbid (principal, action == Action::"write", resource in Pricing::"master");Systems
- Salesforce Service Cloud
- Zendesk
- ServiceNow
- SAP S/4HANA
- Your device cloud
- Jira
On calls the desk does the work before the caller hangs up.
All systems
- CRM for cases, accounts and contracts
- ERP for entitlements, warranty, orders and credit notes
- Transport and returns for shipments and advance exchange
- Field service scheduling for engineer visits
- Telemetry and device management for the installed base
- Manufacturing build records for hardware
- Manuals and field bulletins in your document stores
- Your issue tracker and CI for failing tests
Email, portal, chat and phone reach the same desk. Complaint handling under a quality system is the next pilot on it.
The pilot starts with your hardest tickets.
We run a case type for a quarter, first on last month's tickets and then live. It is paid against first-contact resolution, reopen rate or hours returned.
