Route support requests with a reproducible triage step

Start with a decision that can be explained

A support workflow does not always need a model to choose its next step. If a user has already selected a category and marked urgency, a small deterministic router can provide a useful baseline. This fixture accepts those two fields and returns a destination with a reason. It creates no queue, sends no email and changes no customer record. The aim is an inspectable decision that a support owner can compare with the organization’s actual intake policy.

Define the three destinations

The example maps billing to billing and access to account when urgent is false. Every urgent request goes to human review. Unknown categories, empty categories and editorial subjects also go to human review because the fixture has no approved automated handling for them. The rule is intentionally strict about spelling and types. A category named Billing does not silently become billing; it follows the uncertain path. That makes normalization a separate design choice rather than an accidental property of a comparison.

Prepare the input contract

Each request must contain exactly category and urgent. category is bounded text, and urgent must be a real Boolean rather than a string such as yes. A production intake form should explain the meaning of the urgency choice and prevent confusing input before it reaches the router. The backend must still validate the request. Client-side labels and a friendly interface cannot replace the server’s enforcement of the contract, particularly when another tool can submit the same request.

Run and compare the returned reasons

Save route_requests.py and run it using Python 3.12. The main block prints one known billing result and one unknown-category result. test_workflows.py exercises billing, access, urgency, unknown labels, missing fields and a wrong urgency type. A destination is a suggested handoff location only. There is no hidden transport adapter that forwards the request. This lets the reader practice the rule without access to a live mailbox, customer service account or paid model provider.

Treat failure and uncertainty differently

A malformed request raises a validation error because the contract cannot be interpreted reliably. A well-formed unknown category returns a human destination because the policy has no approved automated rule for it. Those are different outcomes and should produce different interfaces. Do not discard an unknown request as invalid merely because it does not fit today’s taxonomy. Preserve the task through the authorized intake system and let an accountable person decide what happens next.

Extend from observed support work

Review a small set of legitimately handled requests and ask whether the category definitions were understandable. If many requests reach human review, determine whether the form needs clearer labels before adding a model. A future classifier should propose the same bounded category values and retain a separate uncertain result. Compare it with this deterministic baseline using expected outcomes defined before the trial. A more complex method is useful only if it improves the actual handoff while preserving the fallback the support team needs.

Keep responsibility attached to the destination

A named destination needs a real owner, service expectations and a way to reassign work. This fixture does not implement those operational arrangements. Avoid interpreting a successful routing result as proof that someone received or answered the request. A deployed integration would need delivery state, access controls, duplicate handling and recovery evidence. The local exercise establishes only the explicit decision rule. It gives the team a clear starting point for discussing authority and failure before automating communication.

Runnable Python fixture

"""Deterministic support triage; no model, outbound messages or real queues."""
def route(request):
    if type(request) is not dict or set(request) != {"category", "urgent"}:
        raise ValueError("unexpected request shape")
    category, urgent = request["category"], request["urgent"]
    if type(category) is not str or len(category) > 40 or type(urgent) is not bool:
        raise ValueError("invalid routing values")
    if urgent:
        return {"destination": "human", "reason": "urgent-review"}
    if category == "billing":
        return {"destination": "billing", "reason": "explicit-category"}
    if category == "access":
        return {"destination": "account", "reason": "explicit-category"}
    return {"destination": "human", "reason": "unknown-or-editorial-category"}

if __name__ == "__main__":
    print(route({"category": "billing", "urgent": False}))
    print(route({"category": "new-category", "urgent": False}))

Verification and references

The router passed four fixture tests on 16 October 2026 using Python 3.12.10, including human fallback and malformed input. No support message was delivered. Run route_requests.py for the example and test_workflows.py for the complete suite.

• Python 3.12 control-flow tutorial (living reference; accessed 2026-10-16)