The right request.
The right team.

An explainable routing assistant for a hypothetical university housing desk. Compare simple rules with text matching—and see when the system should ask a person.

Synthetic data · Independent prototype · No university deployment or customer interviews claimed

One inbox.
Four different owners.

A hypothetical housing desk receives maintenance problems, connectivity questions, contract changes, and community concerns. Before helping, staff must work out who owns the issue.

The design goal is a useful suggestion with an explanation and a clear review path. Queue definitions and workflow requirements remain discovery assumptions until validated with staff.

Make a request. Inspect the reasoning.

Both approaches run locally in your browser. Try a clear request, then a vague or multi-team request. Neither approach understands urgency or replaces staff judgment.

Use fictional requests only. No ticket is sent, and text is not saved. This demo cannot assess emergencies.

Staff confirmation required

IT Support

Ask staff to verify the suggested owner and collect the details required by that team.

Rules abstain on a tie or no keyword match. A distinct keyword match can still be wrong.

Matched keywords

wifi · laptop

The simpler approach performed better.

A reproducible comparison on 24 hand-authored synthetic development cases: 16 single-team requests and 8 intended for human review. These results describe this small test set, not production performance.

Current development-set results · 32 synthetic training examples
ApproachExpected decisions matchedAuto-suggestion coverageAccuracy among suggestionsReview cases caught
Keyword rules23 / 24 (95.8%)70.8%94.1%7 / 8
TF-IDF matching22 / 24 (91.7%)75.0%88.9%6 / 8
Recommendation: keep the rule baseline as the default prototype.

TF-IDF suggests an owner more often, but makes more mistakes. Keep staff confirmation for both. No claim of time savings, real-world accuracy, or readiness for unattended routing is supported.

Inspect every test case and failure
RequestExpectedRulesTF-IDF
The sink keeps leakingFacilitiesFacilitiesFacilities
Please repair the broken window latchFacilitiesFacilitiesFacilities
The shower drain needs repairFacilitiesFacilitiesFacilities
My heater needs replacementFacilitiesFacilitiesFacilities
I need a password resetIT SupportIT SupportIT Support
My laptop cannot connect to wifiIT SupportIT SupportIT Support
The portal login is lockedIT SupportIT SupportIT Support
My ethernet connection keeps droppingIT SupportIT SupportIT Support
Please cancel my housing agreementHousing AdministrationHousing AdministrationHousing Administration
I have a question about the move out deadlineHousing AdministrationHousing AdministrationHousing Administration
I need a room transferHousing AdministrationHousing AdministrationHousing Administration
My housing bill was charged twiceHousing AdministrationHousing AdministrationHousing Administration
I need help with a roommate conflictResidence LifeResidence LifeResidence Life
My neighbors are making noise during quiet hoursResidence LifeResidence LifeResidence Life
How can I join community social activitiesResidence LifeResidence LifeResidence Life
I want to meet the resident assistantResidence LifeResidence LifeResidence Life
What should I doHuman reviewHuman reviewHuman review
Can you help me tomorrowHuman reviewHuman reviewHuman review
I need to discuss somethingHuman reviewHuman reviewHuman review
The sink is leaking and wifi keeps droppingHuman reviewFacilitiesHuman review
My roommate is noisy and I need a password resetHuman reviewHuman reviewIT Support
The heater is broken and my housing bill is incorrectHuman reviewHuman reviewFacilities
I lost a blue umbrellaHuman reviewHuman reviewHuman review
I need a dining meal plan refundHuman reviewHuman reviewHuman review

The evaluation set informed development: a minimum-evidence guard was added after a regression test. This is not an untouched holdout. Paraphrases, negation, new queues, and sensitive scenarios need independent evaluation.

A small architecture you can explain.

01Synthetic request
02Tokenize text
03Rules or TF-IDF
04Review checks
05Staff decision

Why these alternatives?

Manual routing preserves context. Rules are transparent but brittle. TF-IDF reuses example language but still relies on words in common. LLM routing would introduce additional cost, privacy, and evaluation needs; it is not implemented or benchmarked here.

What is implemented?

Python routing and evaluation, a browser demo using the same exported weights, four queues, review gates, and explanations. No external inference, request storage, authentication, or ticket-system integration is implemented.

What would a pilot need?

Housing staff validate ownership. IT and Facilities check boundaries. Integration specialists assess approved APIs. Privacy reviewers define role access and retention. These are proposed delivery roles, not existing partnerships.

What would change the recommendation?

Discover

Ask staff where routing fails today, which details they need, and what incorrect assignment costs. Validate the four-queue assumption before expanding scope.

Learn

In a consented pilot, categorize corrections: wrong owner, missing context, multiple issues, or unknown request. Prioritize missed review cases over higher coverage.

Prove

Evaluate on newly labeled examples, compare staff correction rates, and test access controls before integrating. No customer feedback has been collected for this project yet.

Inspect the work. Walk through the tradeoffs.

Built as an independent portfolio prototype with AI-assisted implementation. Synthetic examples only. Proposed production controls are documented separately from working features.