Workflow App Sprint Category
Support Routing Gate
For support, CX, and product teams that need consistent routing before queues move, owners change, or policy outcomes are applied.
The workflow
Where this breaks today.
Current failure mode
Support routing depends on inconsistent macros, scattered policy notes, queue owner judgment, and missing evidence.
Focused app surface
A ticket intake, routing rulebook, Decision Record, and support handoff that returns route, escalate, request evidence, approve, or block.
Runtime or record layer
Binding mode: direct_rulebook. Customer executable rulebooks are outside the current production contract.
Example boundary
What the app decides or hands off.
Ticket includes customer tier, issue type, SLA risk, refund or cancel request, evidence, confidence, current owner, and missing-input state.
Route, escalate, request more evidence, approve, block, or assign owner before the queue changes state.
Repeated routing mistakes create escalations, inconsistent customer outcomes, SLA risk, and avoidable support cost.
What ships
One useful workflow surface, not a broad project.
Trigger, current path, owner, failure modes, and the boundary where work should proceed, block, review, or route.
Required fields, evidence standard, missing-input states, and examples of acceptable requests.
Direct declarative Rulebook v1, trusted-adapter fact contract, or Decision Record-only path depending on the workflow.
A focused Krafthaus page, notary, packet builder, score, dashboard row, or handoff artifact the team can review.
What gets stored, where the record travels, and who or what receives the next action.
What to automate, measure, or turn into repeat runtime usage after the first workflow proves useful.
Trust boundary
Start with metadata and handoff shape.
Runs on ticket metadata first. Full customer history and private conversation logs are not needed for the first sprint.
One workflow
The sprint deliberately avoids broad AI transformation, platform rebuilds, or customer executable rulebooks.
Metadata first
The first sprint can use request metadata, policy fields, evidence status, owner, risk, and desired handoff before private-system integration.
15-minute review
The low-friction next step is to confirm the workflow owner, required inputs, Decide binding, and whether a Krafthaus surface is worth scoping.
Workflow App Sprint
Map your version of Support Routing Gate.
Use this category as the public pattern. The company-specific artifact comes after the workflow is real enough to review.