How to Turn a Recurring Operational Complaint Into an AI Hypothesis

I don't treat a complaint as an AI use case. I treat it as a witness statement about work that is breaking, slowing down, or getting repeated.

When I taught product managers to move from writing specifications to building and shipping products, the recurring problem was often that nobody could say what done meant. That is a locked teaching observation from Marius Manolachi's F-pms entity fact, not a measured study. The same ambiguity appears one step earlier, when a team tries to turn “we keep dealing with this” into a pilot.

The card below gives that complaint somewhere precise to go.

Sourceable artifact: A complaint becomes a testable AI hypothesis only after the team preserves the original wording, maps one workflow step and owner, records a baseline or explicit unknown, compares AI with a simpler fix, and precommits a smallest test set, threshold, review boundary, and continue/revise/stop rule.

All three worked cases in this post are synthetic scenarios created on 2026-08-23. No client corpus, production log, measured frequency, model run, or outcome is hiding behind them.

Synthetic case	Decision recorded
Inbound request routing	Repair intake fields and rules first, then test an AI suggestion layer only if a bottleneck remains.
Weekly status chasing	Choose a required form, owner deadline, and reminders. Do not build AI yet.
Purchase-order exception investigation	Build a structured queue and linked-record report, then test read-only AI evidence gathering.

Why a complaint is not yet an AI hypothesis

A complaint describes a symptom. A testable hypothesis names the workflow change, the expected outcome, and the condition that would make you stop.

“We spend too long routing requests” leaves out the step, owner, baseline, and consequence. “If a supervised system suggests a route for the intake step, it should reduce review time without increasing misroutes on a bounded set of representative requests” is testable. It may still fail. That is the point.

The OpenAI Academy sequencing worksheet starts with recurring work, first users, the main workflow constraint, intended outcome, and workflow owner or ownership gap. Microsoft's Discover and Define guidance makes a related distinction: connect a business challenge to a use case, requirements, and success criteria before architecture and implementation.

Use this sentence to expose the missing parts:

If we apply [AI mechanism] at [workflow step] for [owner], then [measurable outcome] will move from [baseline or unknown] to [threshold] on [smallest test set], while staying inside [review boundary]. If it does not, we will [continue, revise, or stop].

Fill the card before choosing a model

Copy this card into a working document. Unknown is a valid value. It tells you what the first evidence-gathering task is.

Field	What to record
Provenance	Real workflow record, anonymized corpus, or synthetic rehearsal. Add the date.
Original complaint	The speaker's words. Do not translate it into AI language yet.
Workflow step and owner	The exact step where the symptom appears and the person accountable for the result.
Frequency and consequence	How often it occurs, what it delays or risks, and whether the value is measured or unknown.
Current workaround and baseline	What happens today. Name the baseline metric or write unknown and define how to collect it.
Proposed AI mechanism	One bounded assistive action, such as classify, extract, retrieve, compare, or draft.
Simpler non-AI alternative	A form, rule, checklist, reminder, training change, integration, or removal of a step.
Smallest representative test set	Normal, edge, and failure cases. Mark a synthetic set as provisional.
Success threshold	The result that justifies continuing, including quality and review effort.
Review boundary	What the system may suggest or read, what a person must approve, and what it cannot do.
Continue, revise, or stop rule	The outcome for a pass, near miss, missing prerequisite, and failure.
Decision log	The selected path: AI test, simpler fix, evidence collection, revise, or stop.

How do you check the artifact before testing a model?

Run a field-completeness check before collecting real cases or asking a model to do anything. This catches an incomplete decision card. It does not test model quality, workflow frequency, or business impact.

const required = [
  "provenance", "complaint", "stepAndOwner", "frequencyAndConsequence",
  "baseline", "aiMechanism", "simplerAlternative", "testSet",
  "threshold", "reviewBoundary", "decisionRule", "decision"
];

const cards = [
  { name: "inbound routing", fields: required },
  { name: "weekly status", fields: required },
  { name: "purchase-order exceptions", fields: required }
];

for (const card of cards) {
  const missing = required.filter((field) => !card.fields.includes(field));
  console.log(`${card.name}: ${missing.length ? "FAIL" : "PASS"}; missing=${missing.join(",")}`);
}

Test method: run the snippet with Node.js after mapping each real or synthetic card to the twelve required fields. A pass means the card is structurally ready for baseline collection. It is not evidence that the AI hypothesis is good.

Observed output from the three synthetic records:

inbound routing: PASS; missing=
weekly status: PASS; missing=
purchase-order exceptions: PASS; missing=

The check passed because each record in this article has all twelve fields. The next test still requires approved workflow cases, a measured manual baseline, and human review.

The card deliberately asks for the non-AI option. The National AI Centre's opportunity guidance scores pain points for volume, repetitiveness, data availability, error tolerance, and current cost. It also advises process repair first when AI fit is low and impact is high, listing templates, rules, removed steps, training, and integration as simpler choices.

How should the three worked decisions be read?

Read each case as a pre-test decision, not a result. The frequencies, baselines, test sets, and thresholds are synthetic working records. They demonstrate how to make the decision falsifiable; they do not show that any workflow improved.

Case A: inbound request routing

Card field	Synthetic record
Complaint	“We keep rereading the same inbound requests before we send them to the right person.”
Step and owner	Intake triage; support lead owns the route decision.
Frequency and consequence	Recurs through the week by construction; observed frequency is unknown. Delayed routing and repeated reading are the stated consequences.
Current workaround and baseline	Support lead reads, tags, and routes manually. Time-to-route and misroute rate are unknown.
AI mechanism	Suggest category, urgency, and missing information. Keep the output as a draft.
Simpler alternative	Required intake fields plus five deterministic routing rules.
Smallest test set	Provisional 12-case synthetic set: four clear, four ambiguous, four out of scope.
Threshold and boundary	At least 10 of 12 suggested routes correct, no missed high-priority case, and review time no worse than manual baseline. A support lead approves every route and sends every reply.
Decision rule	Repair intake fields first. Continue to an AI-assisted test only after measuring the manual baseline and only if the threshold is met. Stop AI if the form and rules meet the threshold with less complexity.

Decision recorded: Conditional AI suggestion test, after ordinary intake repair and baseline collection.

Case B: weekly status chasing

Card field	Synthetic record
Complaint	“Friday status updates are always late because I have to chase everyone.”
Step and owner	Weekly status collection; operations manager owns the pack.
Frequency and consequence	Weekly by construction; observed frequency and delay are unknown. Meeting preparation is late and blockers stay hidden.
Current workaround and baseline	Individual reminders and copy-paste into a document. Completion time and missing-field rate are unknown.
AI mechanism	Draft a status pack and flag missing owner, blocker, or next-step fields.
Simpler alternative	One required status form, a shared deadline, and scheduled reminders to named owners.
Smallest test set	Provisional nine-case synthetic set: three complete, three partial, three conflicting.
Threshold and boundary	At least eight of nine packets contain the correct owner, blocker, and next step with no substantive correction beyond the source material. The manager edits and sends; AI cannot chase or publish.
Decision rule	Stop the AI path if the form and reminders remove the complaint. Continue only if a measurable drafting bottleneck remains after the process repair.

Decision recorded: Simpler process repair first. No AI build yet.

Case C: purchase-order exception investigation

Card field	Synthetic record
Complaint	“Exceptions sit until someone checks three systems.”
Step and owner	Read-only exception investigation; finance operations lead owns the recommendation.
Frequency and consequence	Recurring by construction; observed frequency is unknown. Order release is delayed. No autonomous financial approval is in scope.
Current workaround and baseline	A person checks three systems and writes a note. Investigation time, missing-source rate, and correction rate are unknown.
AI mechanism	Retrieve approved records, summarize the discrepancy with source references, and suggest the next read-only check.
Simpler alternative	Standardized exception queue with required fields, linked records, and a deterministic report.
Smallest test set	Provisional 12-case synthetic set: four complete, four missing a source, four containing conflicts.
Threshold and boundary	At least 10 of 12 recommendations complete and traceable, zero invented source references, and reviewer time no worse than the measured manual baseline. Read-only access; the finance operations lead validates every suggestion and makes every business decision.
Decision rule	Build the queue and report first. Continue to a read-only AI test only if the threshold is met. Revise if missing data dominates. Stop if the simpler queue solves the delay or AI adds review work.

Decision recorded: Process prerequisite, then bounded read-only AI test.

How do you choose the smallest representative test set?

Use the smallest set that covers the normal path, meaningful variation, and dangerous failure boundary. If a real corpus exists, sample from it and record the sampling method. Without one, label the set provisional and replace it before treating the threshold as evidence.

The three synthetic sets use clear or complete cases, ambiguous or partial cases, and out-of-scope or contradictory cases. That is a test-design choice, not a universal sample-size rule. It follows the OpenAI use case discovery playbook, which asks teams to identify inputs, outputs, owners, readiness, and evidence to collect, and recommends testing one meaningful part of the workflow rather than redesigning everything at once.

Before the test begins, write down:

1. The manual baseline and how it will be measured.
2. Which cases are normal, edge, failure, and forbidden-action cases.
3. The exact success threshold.
4. The human review boundary.
5. What a pass, near miss, or failure changes.

That is enough to falsify a narrow hypothesis. It is not permission to automate a consequential action.

What belongs in the continue, revise, or stop rule?

The rule should make every likely outcome actionable. Continue when the bounded mechanism beats the named baseline inside the review boundary. Revise when the idea is plausible but a missing field, owner, source, or case type explains the failure. Stop when the threshold is missed, the review work grows, the risk cannot be contained, or the simpler fix removes the complaint.

This is also where prioritization becomes honest. The OpenAI Academy sequencing worksheet says to mark unconfirmed signals as unknown and define the smallest credible confirmation or bounded test. The OpenAI business guide frames discovery around finding opportunities, teaching common use cases, and collecting and prioritizing candidates, while cautioning that complex use cases can slow teams down.

The decision is not “Can AI do something here?” It is “What is the cheapest change that can remove the complaint while preserving the required quality and control?” If a form or rule removes the work, an AI pilot adds a system to maintain without proving extra value.

What this artifact does not prove

This evidence pack has hard limits:

• All three cases are synthetic. They are not anonymized client cases.
• No frequency, baseline, test result, cost, latency, or model performance was measured.
• The thresholds are pre-specified decision conditions, not findings.
• The test sets are provisional until replaced with approved cases from the real workflow.
• Official sources support the card's process and prioritization logic, not the examples or selected paths.

Use the card on one real complaint next. If the team cannot name the owner, baseline, review boundary, or stop rule, the next action is evidence collection or process repair, not an AI build. For the broader sequence, see the AI opportunity pillar, then the guide to prioritizing AI use cases in a small business. If the workflow survives this card, continue with the business-process readiness test.

Marius Manolachi helps teams learn to build AI products on their own work. The AI learning and consulting page is the appropriate next step when the team needs facilitation or a second review of its evidence pack.