First-response messaging for businesses handling people at their worst moment

Architecture, feasibility and cost model complete; no code written. This page describes a design, not a running system.

The problem

Some businesses are contacted by people having one of the worst weeks of their lives. The contact is unpredictable, often outside office hours, and every engagement turns into a case with the same tedious checklist of documents to gather.

Two things are true at once, and they pull in opposite directions. The document-chasing is repetitive enough to automate. And the first message someone sends is emotionally charged enough that a wrong-toned automatic reply does real damage — the kind that loses the client and travels by word of mouth.

Most automation projects here fail by treating the second problem as though it were the first.

What it does

Handles incoming messages on the channel clients already use. Structured requests — status, document checklists, confirmations, menu-driven intake — get instant templated replies. Anything open-ended goes to a language model with the live case context attached. Anything sensitive escalates to a human.

Staff get a dashboard: case list, conversation log, document status, manual override.

How it’s built

Three layers, with the language model sitting inside the backend as one branch of a router — never as the front door.

The decision that mattered

Structured input never reaches the model.

Templates handle status updates, document requests and confirmations. They are instant, free, and identical every time — which is exactly what you want when the same message goes to hundreds of families. The model handles only what templates cannot: acknowledging a loss before anything procedural, explaining a form to someone distressed, and the 3am message where consistency of tone is the entire product.

Every model call gets the system prompt plus live case context — who the client is, which documents are outstanding, what stage the process is at. That context is what makes a reply read as personally informed rather than generically kind, and it costs a fraction of a cent.

A human handoff exists on every path, including mid-conversation with the model. There is no acceptable version of this where a distressed person is stuck talking to an automation.

Consent capture sits inside the intake flow, not bolted on afterwards. Retrofitting it means migrating live case records, which is a bad week nobody needs.

Outcome

Not built. Feasibility, architecture and the cost model are complete and documented, with the build scoped into five modules — the first two of which stand alone as a proof of concept, because they carry all the risk. The remaining three are conventional work with predictable effort.

Scoping it that way is the point: the routing and tone question gets answered for the cost of two modules, before anyone commits to five.