Customer escalation to recovery: one case from the complaint to the kept promise

How the escalation workflow will join the customer's report, the error, the fix and the deal into one case, with the fix and the customer notice approved together.

Customer escalation to recovery is a workflow for engineering leads and customer teams, for the day a customer reports that something they were promised broke. It opens one case that runs from the complaint to the kept promise. CommitOps holds the promise, RepoOps traces the cause and measures the recovery, PromptCompute holds the fix and the customer notice for one decision, and Sales as Code shows the result on the deal.

One of its four parts is built today. The rest of this guide says what each part does and which are still to go.

The problem

Three teams see three pieces of the same failure. Support sees the complaint. Engineering sees the error. Sales sees the deal that depends on the customer staying happy. Nobody sees all three, so the fix ships and the customer hears about it last, if at all.

The promise makes it worse. A customer who was told a feature would work by a date is not filing an ordinary bug. They are checking whether you keep your word.

How the workflow solves it

The workflow will treat the escalation as one case with one record. It will match the customer’s message to the promise at risk, trace the error to the change that likely caused it, and propose a fix. Then it will put the fix and the customer notice on one approval card, so the person who approves the code also approves what the customer will be told.

The notice will wait for proof. The plan says the workflow sends the notice only after RepoOps marks the recovery verified, so a customer will never hear “fixed” about a fix that has not held.

Step by step

When the workflow runner ships, a run will take the steps below. Present tense means the part works in its product today; “will” means it is still to build.

A run will start from a customer message that names a promise, or from a broken-promise case in CommitOps.

1. CommitOps will open a case from the customer’s message and match it to the promise at risk. A broken promise opening a case in RepoOps is already built and switching on; reading the case straight from a support message is the new part.
2. RepoOps traces the error to its likely change and agent session. It names the commit when it can, and when it cannot it says why, using one of twelve named reasons. It never fills the gap with a guess.
3. RepoOps proposes the fix.
4. PromptCompute will hold the fix and the customer notice for one decision. The card will show the promise and the deal value next to the diff and the draft notice. If the approver rejects the notice text, neither action will run, and the run will go back to the draft.
5. RepoOps measures recovery after the fix deploys. Each success criterion reads met, not met or not measured, and RepoOps keeps watching for 14 days before it calls a fix worked.
6. CommitOps marks the promise kept or broken. This is built and switching on.
7. Sales as Code shows the kept promise on the deal. It records the promise as a driver on the deal and never moves the odds without saying so.

The notice step is the one that faces the customer, so it is the one that will wait twice: once for the person, and once for verified recovery.

What the workflow will report

Each run will report three things:

• The hours from the customer’s report to verified recovery.
• The promises at risk that end kept.
• The customer notices sent before the fix was verified. The plan sets this at 0.

The run will also leave a record of each step: what it saw, who approved what, and how the promise ended.

Why it matters to an engineering lead

Your customer judges you on two things after a failure: how fast you recovered, and whether you told them. This workflow will make both visible and give the account team proof they can show. When the customer asks what happened, the answer will be a case with a cause, a fix, an approval and a measured recovery, not a summary someone wrote from memory.

It will also remove a step that teams get wrong under pressure. Approving the fix and the notice together will mean nobody has to remember to tell the customer, and nobody can tell them too early.

How to set it up

You connect three things outside the family: Slack or your support inbox, GitHub, and your CRM (HubSpot, Salesforce or Attio).

With the runner and the signed-in app in place, setup will look like this:

1. Sign in with PromptReports ID and pick your org.
2. Connect CommitOps, RepoOps, PromptCompute and Sales as Code. Link Slack or the support inbox, GitHub and the CRM through the product that reads each.
3. Register the agent that will run the case, with a version manifest.
4. Set the approval policy for building the fix (repoops.build_fix), notifying the customer (commitops.customer.notify) and updating the deal (crm.deal.update). Start each at Require approval.
5. Name the trigger, a customer channel or broken-promise cases, and start a dry run to see which steps would record missing evidence.
6. Start the run, approve the card when it reaches you, and read the record when the promise ends kept or broken.

An agent will start the run through the PromptReports MCP server or API, using the proposed start_run and get_run tools, and the runner will call each product for it.

The workflow is on every plan. Plans are per user per month: $25 for 100 workflow requests, $50 for 500, and Enterprise above 500, with no free tier. One escalation taken to recovery is one request, however many steps it takes.

Today an agent can call the products one at a time, each with its own key. RepoOps serves incident attribution on its MCP server (get_incident_attribution), and CommitOps serves the promise ledger on its MCP server (list_assertions, check_claim). Nothing joins those calls into one case yet.

What is built today and what is planned

The workflows page lists this workflow as partly built: two of four parts are merged, and the RepoOps trace and fix and the PromptCompute approval are still to go.

Built:

• Sales as Code shows a promise kept after a risk on the deal, without moving the odds (Sales-Intelligence #2808). It switches on when CommitOps is joined for that customer.
• CommitOps marks a promise at risk when a customer message reports a failure on it, and will share it with RepoOps through the family feed once that is switched on (commitops #148).
• In the products, RepoOps already traces errors to changes and sessions, proposes fixes and measures recovery, and a broken CommitOps promise opening a RepoOps case is built and switching on.

Still to go:

• RepoOps tracing the case from the CommitOps feed to its change and agent session inside the workflow, and sending the fix for approval.
• One PromptCompute approval for the fix and the customer notice together.
• The workflow runner. No runner exists today. The plan is a durable runner service in the PromptCompute stack, with one run id carried across products, approvals as steps in the run, and each run metered as one workflow request.

Read more

• Every workflow and its state
• Pricing
• From a production error to a tested lesson
• CommitOps, RepoOps, PromptCompute and Sales as Code