A customer's view of what was promised: one shared page instead of a thread of status emails

How the customer promise page workflow will publish a page per customer with each promise, its state and what shipped, once a person approves it.

A customer’s view of what was promised is a workflow for customer teams and the customers they serve. It will publish one page per customer, shared by link, with each promise the team made, the state of each one and what shipped. CommitOps holds the promises and will build the page, RepoOps will attach the delivery evidence, and a person will approve the page before it goes live.

The workflow is partly built. The CommitOps promise ledger it reads from works today, and the delivery evidence on the promise page is merged and off by default.

The problem

Customers ask when it will ship, and they ask by email. Each person on the account answers from what they remember, so the answers drift. The account manager says next month, the engineer says next sprint, and the customer gets two dates for the same feature.

Then the thread grows. Every status update is another email, every email is a chance to say something slightly different, and nobody on either side has one place to look.

How the workflow solves it

CommitOps already records every promise somebody made to the customer and whether it shipped. The workflow will turn that ledger into a page the customer can open. RepoOps will attach the delivery evidence for each promise, so a promise marked shipped will link to the work that shipped it.

Only promises in the ledger will appear. When an agent records a promise as a candidate, it will stay off the page until a person keeps it, so the customer will never see a promise nobody on the team has confirmed.

Step by step

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

A run will start when a person publishes the page. After that it will refresh daily.

1. CommitOps lists the customer’s promises with list_assertions.
2. RepoOps will attach delivery evidence to each promise, through the feed it shares with CommitOps.
3. CommitOps will build the page, with each promise, its state and what shipped.
4. A person approves publishing it in PromptCompute, under commitops.page.publish.

The first publish is the decision that matters, because it puts the page in front of the customer.

What the customer will see

Each row on the page will be one promise from the CommitOps ledger. CommitOps already keeps, for each promise, the sentence somebody said it in, who said it and to whom, and whether it shipped, and it links each promise to the work that keeps it. The page will show the customer the promise, its state and what shipped, with the delivery evidence from RepoOps next to anything marked shipped.

CommitOps already gives the same kind of answer in other places. On HubSpot, Salesforce and Attio deal cards, and in Slack, it answers whether a promise has shipped, is projected before its date, is projected after it, or says it cannot tell. The page will put that state in front of the customer, so they read the answer the account team would have given them.

The ledger also links each promise to the revenue that depends on it. Which of those fields the customer’s page will leave out is not settled in the plan. [author: confirm which ledger fields the customer page will hide, such as the revenue linked to a promise]

What the workflow will report

Each run will report two things:

• The status emails per account per month, so you can see whether the page replaced them.
• The promises shown with delivery evidence, out of all the promises on the page.

The second number is the honest one. A page where most promises say shipped and few link to the work is a page the customer has to take on trust.

Why it matters to a customer team

One page will replace a thread of status emails, and the customer will see the same record the team sees. When the account manager and the engineer both point at the page, the customer gets one answer.

A late promise will show as late on the page, next to the ones that shipped. Nobody will have to decide how to phrase the delay in an email, because the page will state it.

How to set it up

GitHub is the only outside connection, linked through RepoOps.

When the runner and the signed-in app ship, setup will be:

1. Sign in with PromptReports ID and pick your org.
2. Connect CommitOps and RepoOps, and link GitHub through RepoOps.
3. Register the agent that will refresh the page.
4. Set the approval policy for commitops.page.publish. It defaults to high risk; keep the first publish at Require approval.
5. Pick the customer and start a dry run. It will show which promises would appear without delivery evidence.
6. Publish the page, approve it, and send the customer the link.

An agent will start the run through the PromptReports MCP server or API, with the proposed start_run tool.

The workflow is on every plan. Plans are per user per month: $25 for 100 workflow requests, $50 for 500, and Enterprise above 500. There is no free tier. Each daily refresh of the page will count as one workflow request, and the allowance is pooled across your organization.

Without the runner you can read the same promises yourself. CommitOps serves list_assertions and get_assertion on its MCP server and its HTTP API, with a key a person issues for each caller.

What is built today and what is planned

The workflows page lists this workflow as partly built: one of two parts is merged, and the RepoOps delivery evidence through the feed is still to go.

In the products today:

• The CommitOps promise ledger, with each promise, who made it, and whether it shipped.
• list_assertions on the CommitOps MCP server.
• PromptCompute approvals for the publish step.
• The CommitOps customer promise page, shared by link. It can show a dated line per piece of shipped work from a signed RepoOps delivery fact (commitops #154), which is off by default.

Planned:

• RepoOps sending delivery evidence per promise through the feed, so the page has shipped work to show.
• The workflow runner. No runner exists today. The plan is a durable runner service in the PromptCompute stack, with one run id across products, approvals as steps, and each run metered as one workflow request.

Read more

• Every workflow and its state
• Pricing
• The revenue loop: from a forecast to a promise kept
• CommitOps and RepoOps