Build it with AI
Create an intake workflow that captures the right information before work begins.
Build structured intake for customers, projects, requests, cases, or internal work and route it into the right workflow.
Introduction
What an intake system has to hold.
Most teams end up with an intake system the same way: requests arriving by email, phone, and hallway conversation into no consistent queue. Free-form requests are fine while the person receiving them can fill the gaps from context. It breaks when the receiving team grows past the point of shared context, and every incomplete request becomes a round trip that costs two days.
Requests arrive through as many channels as there are people, so the queue is whatever each person remembers. There is no definition of what a complete request contains, no routing rule that survives a reorganisation, and no record of how long a request waited before anyone looked at it.
What follows covers building an intake system: the records it holds (the request, who made it, what it needs, priority, owner, and current state), the systems it reads (Gmail and Slack), and what it does not fix.
The problem
Work arrives in six formats and none of them are complete.
Forms capture structure and are avoided because they are slower than a message. Ticketing systems route well and model the requester’s problem as a category chosen from a list they do not understand. Both push the completeness problem onto the receiving team.
The records are the request, who made it, what it needs, priority, owner, and current state, and the authoritative copy of most of them already lives in Gmail or Slack. The request came in via chat, was copied into a ticket with half the detail, and the original thread has the answer that the ticket is now asking for.
The cost is not the inconvenience: a request made in a corridor is the one that gets forgotten.
You're likely here because
- Most requests need at least one round trip before work can start
- Requests arrive through as many channels as there are people, so the queue is whatever each person remembers.
- When it is wrong, a request made in a corridor is the one that gets forgotten
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Dynamic intake form
- • Request queue
- • Routing view
Operated through Grow
- • Qualification
- • Follow-up
- • Scheduling
Systems it reads
- • Gmail
- • Slack
- • Google Drive
The record model
What a complete request contains.
- Request type
- Chosen by the requester, which means the taxonomy must be navigable without thinking. When it is not, people pick the first plausible option and the routing data becomes fiction.
- Completeness state with the named gap
- Validated at submission, naming the specific missing item. That turns a two-day round trip into a ten-second correction, which is most of the total delay.
- Routing rule applied
- Recorded, so a misroute can be traced to a rule rather than to a person. Routing that lives in one head is a single point of failure that surfaces during holidays.
- Arrival channel
- Form, chat, or email. Portal-only intake produces a clean queue that omits the requests most likely to become problems.
- Queue age
- From arrival rather than from acceptance, so the wait a requester actually experiences is what gets measured.
- Requester-visible status
- Because most chase contact is a request for confirmation that the request exists, and it consumes the receiving team at exactly the wrong time.
- Attachments and their source
- Held with the request rather than in the thread it arrived in, so the work can start from one place.
How it runs
From requests in an inbox to a routed queue.
Step 01
Describe what an intake system has to do
Define what complete means per request type. Intake systems fail when the form asks what the receiving team wants to know rather than what the requester can actually answer.
Step 02
Connect the systems of record
Email and chat are where requests genuinely originate, and the document store holds what gets attached. Accepting requests where people already are is what determines whether intake is used.
Step 03
Build the operating surface
Request types with conditional fields, a routing rule per type, a queue with ownership and ageing, and the path from a complete request into the workflow that handles it.
Step 04
Start narrow
One request type — the one causing the most round trips — with its completeness definition enforced. One type done well teaches the pattern; a general form covering everything teaches avoidance.
Step 05
Route the exceptions
An incomplete request goes back to the requester with the specific gap named, rather than into a queue where it waits for someone to notice and ask.
Step 06
Measure requests entering the tracked queue as a share of requests actually received
Measure the share of requests that are complete on first submission, and the wait before first human contact. The first drives the second, and both are objective.
Implementation path
Building intake that people actually use.
- 01
Take twenty real requests from last month and identify what was missing in each. That list is the form, and it is a better specification than any workshop.
- 02
Baseline the round-trip rate and the wait to first response. Both are reconstructable from existing threads and both are the argument for the work.
- 03
Accept requests through the channels people already use rather than requiring a portal visit. Portal-only intake produces excellent data about the minority of requests that use it.
- 04
Route on request type before adding conditional logic. Routing is where the time is lost; conditional fields are refinement.
- 05
Build the narrowest useful version first: one intake form feeding one queue with an owner and a triage state.
- 06
Taking twenty real requests from last month and listing what was missing in each is a morning, and it is a better specification than any workshop. Accepting requests from chat and email as well as a form is the technical work that decides adoption. One request type live within two weeks; extend once the round-trip rate for that type has fallen.
- 07
After the first type is complete on submission more often than not, add requester-visible status to remove chase contact, then the second request type. Conditional fields are refinement and come after routing.
Controls
Controls that matter.
Control 01
Completeness validated at submission with the specific gap named, so the round trip happens in seconds rather than in two days
Control 02
Routing rules held as configuration with an owner, since routing that lives in one person’s head is a single point of failure that surfaces during holidays
Control 03
Requests accepted from chat and email as well as a form, because intake that is harder than a message will be bypassed by exactly the urgent requests
Examples
Three chases that stop happening.
The request missing the one thing needed
Validation at submission that names the specific gap turns a two-day round trip into a ten-second correction, which is most of the total delay in typical intake processes.
The request that went to the wrong team
Routing as owned configuration rather than tribal knowledge stops the reassignment chain that adds days and loses context at every hop.
Where is my request?
Status visible to the requester removes the chase messages that consume the receiving team’s attention and produce nothing except reassurance.
How it goes wrong
Three ways intake systems get avoided.
The form asks what the receiving team wants to know rather than what the requester can answer, and gets abandoned.
Every field must be answerable by the person filling it in. Unanswerable fields produce either abandonment or a placeholder, and the placeholder is worse because it looks like data.
Request types accumulate until there are thirty and nobody can find the right one.
Prune the taxonomy on a schedule. An unnavigable taxonomy is worse than a coarse one, because it produces confidently mis-categorised data rather than obviously coarse data.
Classification is automated and a misrouted request is treated as deliberate by the receiving team.
Let classification propose and a human confirm where routing has a real cost. A misroute is expensive precisely because the recipient assumes the routing was intended.
Limitations and considerations
What structured intake will not fix.
- Structured intake does not reduce demand. It makes demand visible and comparable, which frequently reveals that the volume problem was a prioritisation problem.
- Over-specified forms produce abandonment and workarounds. Every field must be one the requester can genuinely answer, or the form teaches people to route around it.
- Intake systems accumulate request types until nobody can find the right one. Prune the taxonomy on a schedule or it becomes the thing people avoid.
- If requests arrive complete already, structure adds friction and removes nothing. If the queue is long because of capacity rather than incompleteness, better intake makes the backlog more legible and no shorter.
- Connector coverage varies: Gmail, Slack, Google Drive are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build an intake system with AI: common questions.
Will people actually use a form?
Only if it is not slower than the message they would otherwise send. Accepting requests from chat and email, and applying the structure on the way in, is what makes structured intake survive contact with an urgent request.
How many request types should there be?
Few enough that a requester picks the right one without thinking. When they cannot, they pick the first plausible option, and the routing data becomes fiction that looks like structure.
Can AI classify free-form requests?
It classifies and extracts usefully, and it should propose rather than decide where the routing has a real cost. A misrouted request is expensive precisely because the receiving team assumes routing was deliberate.
Should requesters see status?
Yes. Status visibility removes the chase messages, which are typically a substantial fraction of the receiving team’s interruptions and produce no information the system does not already have.
What should the first version contain?
One intake form feeding one queue with an owner and a triage state. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure requests entering the tracked queue as a share of requests actually received against the baseline taken before anything changed.
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build an intake system around the process you actually run.
Derive the form from twenty real requests, accept them from chat and email, and measure first-submission completeness.