Product design exploration

Signal-to-Fix Engine

One support platform for three stages of AI adoption, shown through the support-to-product loop.

Solo product explorationInteractive prototypeSynthetic data · modeled numbers

The problem: support is where product issues surface first, but the fix reaches the front line slowly.
The design challenge: enterprises are at very different stages of AI adoption, and a platform can't force a rebuild to move up.
The answer: one data model and three integration tiers. Each tier removes a different kind of waiting.

1The use case: the support-to-product loop

Orders show "delivered" but never reach customers in apartment buildings. Every system says success, so support hears first.
Goal: shorten the time from the first affected conversation to every rep giving the right answer.
The support platform triages (spots the pattern, reports it with evidence). The enterprise investigates and informs (finds the cause, gets guidance to reps).

2The design problem: three stages of AI adoption

Enterprises won't adopt AI all at once. Some work in tickets and dashboards, some have engineers living in AI assistants, some will run their own agents.
A platform that forces a rebuild to move up loses the ones that aren't ready and underserves the ones that are.
So: one engine, one data model, three ways to plug in.

Agent-led is specced, not built. Result figures are modeled (see section 5).

3Five decisions that shaped it

One data model, every tier

Moving up a tier means adopting a new interface, not re-integrating.

IssueCaseEvidenceInfoRequestGuidance

MCP tools map to intents, not endpoints

The model pays for every call, so return meaning, not rows.

get issuelist casesaggregate→investigate_issue

Approval follows risk, not tier

Rep-facing questions can be automated. Customer-facing text always gets a human.

rep-facing: automatecustomer-facing: human

Every speed metric has a guardrail

Reporting faster must not mean more rejected reports.

conversations needed ↓paired withrejected reports ↔

Design for the engineer, not just the buyer

Engineers want to spend as little time as possible on support issues, so their goals don't automatically line up with the north star. If the product makes that experience better, they use it, and the loop closes. Developer satisfaction is the primary metric for investigation.

Buyer: VP CS / CX≠Engineer: gates the outcome

4Prototype

Clickable walkthrough of the Mixed tier: a webhook creates a ticket, the engineer investigates in an AI assistant over MCP, asks customers a question, and the issue resolves.
Built to explore the interfaces, not the scoring pipeline. Data is synthetic.

Open the interactive prototype Design notes: metrics, signals, specs, tradeoffs

5How I'd measure it

Economic buyer · VP CS / CX

North star

MetricConversations without the right guidance ↓

GuardrailPoor-outcome rate after guidance

CX Lead

Triage

MetricConversations needed to report with confidence ↓

GuardrailRejected reports

Enterprise engineer

Investigate & inform

PrimaryDeveloper satisfaction ↑

SecondaryTime to investigate ↓

GuardrailGuidance retraction rate

Modeled: conversations handled without the right guidance, by tier

Human-led~100

Mixed~70

Agent-led~3

How the numbers were modeled

Same incident and contact rate in every tier. An engineer investigates in 2h (dashboard) or 30 min (MCP or agents) and fixes in 6h. Engineers work 09:00 to 18:00. Writing guidance from scratch takes about 5h; reviewing a draft takes about 1h. These are assumptions, not measurements.

6What I'm unsure about, and what's next

Unsure: webhooks. Do product teams want issues pushed to a tracker, or a different channel such as chat, paging, or a digest? Validate with a handful of product teams first.
Unsure: agents. Will enterprises run their own release, engineering, and KB agents? Build the agent-led tier with one or two design partners.
Next: version the data model and every interface; offline evals for classification and clustering.
Measure: tier adoption and migration friction; which MCP tools engineers actually use.

Prototype uses synthetic data and fictional companies. Tier figures are modeled from stated assumptions, not measured.