TemplatesGet a demo →Book a meeting

Assistance applications sorted by urgency, written up for the decision-maker

Each application arriving from your intake system is sorted by urgency and completeness, then set against your assistance criteria with the criteria quoted. The decision-maker starts from a consistent write-up, and the flow is instructed never to recommend an amount.

Operations · Pensions & retirement · Something arrives from another system · 10 steps · Reads your documents

AI Factory · Assistance application triagethe flow as it opens in the builder
When something arrivesIt arrives
RouteWhat kind of question?
RetrieveRetrieve — Urgent case
RetrieveRetrieve — Routine case
RetrieveRetrieve — What is missing
AnswerPolitely decline
AnswerUrgent case
AnswerRoutine case
AnswerWhat is missing
Answer shownAnswer shown
10 steps in the flowDrag the canvas, or any step, to move it around.

Why teams run it

Hardship and assistance applications arrive in every state of completeness, and an urgent case about housing or medical costs can sit behind routine ones until somebody reads the whole pile. Committees then spend their meetings working out what each application says instead of deciding it.

How it is governed

  • Every path is instructed never to recommend an amount; deciding stays with people.
  • Only a correctly signed webhook call can start a run.
  • Every application, the path it took and its write-up are kept in the run history.
Who runs it
Assistance program administrators; Hardship committee members; Member services managers.
What you supply
A webhook from wherever applications arrive; Your assistance criteria as a knowledge source.
What “a person approves” looks like in the product: the run stops, the banner says what approving will do, and until someone decides, nothing leaves the system. A demo workspace on synthetic data.

From template to a live agent

The same builder, tests and release review apply to a template as to anything built from scratch.

Open it as a working flow
Every step, source, branch and approval is already in place, and every one of them can be changed before it runs on your data.
Prove it before it ships
An evaluation set can gate the release, so a change that breaks an answer never reaches anyone. A question it cannot answer from the sources leaves the gate unproven, not passed.
Keep a person on the decisions
A run that needs a decision stops and says exactly what approving will do, and who it is waiting for.
Publish where people work
A form, an embedded widget, Microsoft Teams or a scheduled batch — with its own access and limits per deployment.
What teams usually change
Rewrite the categories to match how your committee triages cases; Point retrieval at your current assistance criteria and guidelines; Change the tone of the note that goes to applicants.
Step 02, in the product: an evaluation set that gates the release. A question it cannot answer from the sources leaves the gate unproven, not passed. A demo workspace on synthetic data.

Questions buyers ask

Does it decide who receives assistance?
No. It sorts and writes up; every path is instructed not to recommend an amount, and the template has no step that records a decision or makes a payment. The decision-maker reads the write-up and decides.
Where does the write-up go?
It is the result of the run and appears in the Output queue, where it can be assigned to a reviewer and marked reviewed. A team that wants it delivered elsewhere adds that step in the builder.
What if something arrives that isn’t an application?
The routing step has a path for anything that fits none of the categories, which answers in one line that it does not look like an assistance application. Nothing is assessed against your criteria for it.

See it run on your own data

We open it in the builder, point it at a sample of your documents and systems, and run it with you.