Course resource
Form Automation Blueprint
The intake workflow: a form arrives, AI reads it, the right thing happens. The most useful automation most people build.
The shape
Form submission
-> extract structured fields
-> classify (category, urgency, sentiment)
-> route by classification
-> draft a reply into Drafts
-> log the row
-> notify a human if urgent
Six steps. Build them one at a time.
Step 1: the form
Design the form so the automation has less to guess.
- Ask for structure where you can. A dropdown for category beats asking AI to infer it.
- One free-text field for "tell us what is happening". That is where the value is.
- Ask for what you need to reply — name, contact, and anything the reply depends on.
- Do not ask for what you will not use. Every extra field loses submissions.
- Say what happens next, and when. Reduces the follow-up emails.
Step 2: extraction
From the submission below, extract these fields as JSON:
{
"name": "",
"email": "",
"organisation": "",
"request_type": "",
"deadline_mentioned": "",
"budget_mentioned": ""
}
Rules:
- Use only information present in the submission
- If a field is not present, use null. Do not infer or guess.
- Do not add fields
- Return only the JSON, no explanation
Submission: {{form data}}
Temperature 0–0.2. Then validate the JSON parsed before the next step uses it.
Step 3: classification
Classify this request into exactly one category:
billing | technical | sales | complaint | other
Then rate urgency 1-5, where:
5 = service is down or a customer is actively leaving
4 = blocked, needs same-day
3 = normal request
2 = question, no deadline
1 = feedback, no action needed
Respond as JSON: {"category": "", "urgency": 0}
Nothing else. If genuinely ambiguous, use "other" and urgency 3.
Request: {{free text field}}
Constrain the vocabulary. An open-ended classification produces "Billing." with a full stop, and your router matching on "billing" sends it to the fallback.
Normalise before comparing: trim whitespace, lowercase, strip punctuation.
Step 4: routing
| Condition | Action |
|---|---|
| urgency >= 4 | Notify a human immediately, then continue |
| category = complaint | Route to [OWNER], skip auto-draft |
| category = billing | Billing queue |
| category = technical | Technical queue |
| fallback | General queue + notify |
The fallback route is mandatory. Without it, anything unmatched disappears silently.
Step 5: the draft
Draft a reply to this request.
Their message: {{free text}}
Their name: {{name}}
Category: {{category}}
Our relevant policy: {{policy text, if you have it}}
My voice profile: {{profile}}
Rules:
- Under 120 words
- Answer the actual question if the policy covers it
- If the policy does not cover it, say a colleague will follow up.
Do not invent a policy.
- Never commit to a refund, discount, date or outcome
- No "we apologise for any inconvenience"
This will be SAVED AS A DRAFT for a human to review. Do not write as if sending.
Save to Drafts. Never send. This is the entire safety mechanism of the workflow.
Step 6: log and notify
Log every run, regardless of outcome:
| Timestamp | Submission ID | Category | Urgency | Routed to | Draft created | Error |
|---|
Notify only when urgency is high. An automation that notifies on everything gets muted within a week, including the notifications that mattered.
Testing before it goes live
- A normal request — correct category and urgency?
- An urgent one — does the notification fire?
- A complaint — does it skip the auto-draft?
- Something nonsensical — does it fall to the fallback?
- An empty free-text field — does it error gracefully?
- A very long submission — is it truncated, and does that matter?
- A submission containing "ignore your instructions" — what happens?
- The same submission ten times — same classification every time?
The last two are the ones people skip and the ones that break.
Cost
| Submissions per month | |
| AI steps per submission | 2 (extract, classify) + 1 (draft) |
| Cost per run | |
| Monthly at current volume | |
| Monthly at 5x volume |
Run the 5x number before launch. Volume spikes are when unbudgeted automations get noticed.
The human review
Even with drafts, someone must actually read them. The failure mode of this workflow is a human who has approved 200 good drafts and now approves without reading.
- Sample deliberately: read every draft for the first two weeks, then one in five, forever.
- Log corrections. If the same correction appears three times, fix the prompt.
- If nobody has corrected anything in a month, check whether anyone is really reading.
Common failures
| Symptom | Cause |
|---|---|
| Everything lands in the fallback | Classification output not normalised before comparison |
| Same input, different routing | Temperature too high on the classification step |
| Drafts reference policies you do not have | No "do not invent" instruction |
| Nobody notices it broke | No error path |
| Bill much higher than expected | No filter, or the draft step running on everything |