An intake record people can use
The starting point is the information needed to act: who is making the request, what they need, the relevant dates, and who should receive it. Optional detail should not obscure those essentials. A first version might use a staff-entered record, an agreed connection to an existing inbox, or a separately scoped client-facing intake page.
Ownership and status
A request should have an owner and a set of states with ordinary meanings. “Waiting for information” is different from “ready for review.” We define which people can change a state, what they need to supply, and how exceptions return to a responsible person. Permissions follow actual roles, rather than giving every user the same access.
Useful views and reminders
Potential features include a shared work queue, a personal task view, due-date filters, related documents, and a history of important changes. A reminder needs a recipient and a reason; it should not become another source of noise. Search and reporting are defined around the questions the team actually asks.
What can be delivered
A scope may include workflow definitions, screen designs, a reviewable prototype, an agreed application build, and setup documentation. Hosting, data migration, notifications, and maintenance are specified separately where needed. An illustrative request journey on this site explains the concept; it is not a live client system or evidence of a completed engagement.