What we were aiming at was that a clinician could finish a task without stopping to look for a control. Here is how the shipped product differs from what came before it.
.png)
We looked at how case handlers actually dealt with requests coming in from different places . A tenant might call, email, leave a message with the answering machine, or show up in person . People kept their own workarounds for keeping track, flagged emails, mental notes on who owned what, because the ticket system only ever saw the requests that came in structured. When a case handler was out, nobody else had a way into what they’d been sitting on. Management’s complaint was different: no reliable way to tell what was actually outstanding, since the same fault could land as several disconnected tickets depending on which channel it came through. What people wanted, across the board, was one shared picture that didn’t depend on remembering to update it by hand.

Mapped how a case handler actually works onto an intake, classify and match split, and set the rule for which decisions live inside the ticket system and which outside.
Ran nine explicit questions against the real test instance, from who creates tickets to whether a firm’s reply returns to the right sub-ticket, before writing any dependent code.
Built and validated the schema against one real building’s occupancy, contract and contact data before scaling to the full portfolio.
Implemented mailbox polling with per-mailbox watermarks, forwarded-message resolution, rule-based pre-filtering and a single confidence-logged "ticket, yes or no" model call.
Built the webhook-triggered matching cascade and duplicate detection, then wired the tradesperson loop, tenant confirmations, text modules and the 24/48/72-hour escalation ladder.
Reworked the website enquiry form so submissions land on the real ticket flow, and logged failed runs, uncertain matches and processing cost so the system can be audited.
