# Customer problem → solution recommendation

## Discovery hypothesis
A hypothetical housing service desk receives mixed facilities, connectivity, contract, and community requests. Staff must identify ownership and collect missing details. This hypothesis draws on the domain of Residence Life but has not been validated with customers for this project.

## Questions before a pilot
- Which queues exist, who owns them, and what is the escalation policy?
- How many requests contain multiple issues, sensitive information, or urgent risks?
- What fields are necessary for an authorized staff member to route a ticket?
- What does incorrect routing cost relative to manual review?
- Which systems, access controls, retention rules, and integration APIs are approved?

## Acceptance criteria for the prototype
Known-example requests produce a queue and explanation; empty and unknown inputs defer; model behavior is reproducible; results show failures as well as correct predictions. The browser does not transmit or persist request text.

## Alternatives and competitive positioning
| Option | Strength | Tradeoff | Recommendation |
|---|---|---|---|
| Manual triage | Staff context and judgment | Recurring review effort | Keep as fallback and pilot comparator |
| Keyword rules | Transparent, inexpensive to run | Brittle wording; rule maintenance | Best result in this synthetic comparison |
| TF-IDF nearest example | Reuses example language; inspectable matching | Lexical overlap is not understanding | Experimental comparator |
| LLM routing | Potentially richer language handling | Vendor cost, privacy, latency, evaluation requirements | Not implemented or benchmarked |

These are architectural alternatives, not a vendor benchmark. No unsupported vendor claims are made.

## Feedback → product strategy
No feedback interviews have been conducted. For a future pilot, collect anonymized correction categories with staff consent: wrong owner, missing information, multiple issues, or unknown request. Review these weekly, update queue definitions, then evaluate on a newly labeled set. Prioritize missed review cases before expanding automation coverage.

## Pilot decision
The 24-case development evaluation favors rules over TF-IDF (23 vs. 22 expected decisions). Both still route some intended-review inputs incorrectly. Keep all suggestions staff-confirmed. Before any deployment, obtain institutional review, confirm queue ownership, validate on an independently labeled set, measure staff correction rate, and test privacy/access controls.

## Delivery dependencies
Housing operations owns queue definitions. Facilities and campus IT validate routing boundaries. An authorized integration engineer evaluates ticket-system APIs. Security/privacy reviewers define access and retention. These are proposed responsibilities, not actual partner relationships.