The Typeform notification email is one of the quietest cash-flow leaks a small company has. You set up a contact form months ago, pointed it at "team@" or "hello@", and now 200 submissions a week land in a shared inbox that nobody owns. The sales person archives the support tickets, the support person archives the partnership pings, and the partnership pings die. The survey responses get starred for "later" and "later" never arrives.
The fix is not a smarter inbox. The fix is to stop the form from dumping into an inbox at all. Each submission has a clear intent that is decidable from its content, and each intent has a clear destination that already exists somewhere in the stack. The job of the routing agent is to read the submission, decide the intent, enrich the contact, and deliver the response to the destination where it will actually get worked. It does not reply. It does not write copy. It routes.
What this agent does
Every time Typeform fires a webhook for a new submission, the agent wakes up, reads the response, classifies the intent into one of a small fixed set, enriches the contact from the email domain, looks up the destination for that intent in a configured map, writes a one-line summary, and delivers the response to the destination. The submission lands as a CRM record for a sales lead, a ticket in the support inbox for a support ask, a Slack message in the partnerships channel for a partnership pitch, an ATS candidate for a recruiting submission, a quiet log entry for spam, and a row in the research database for a survey response.
It does not write a reply to the submitter. It does not edit the submission. It does not call the submitter. The output is delivery plus a one-line summary, nothing more. If you want the agent to draft replies, that is a different agent on the other side of the destination, not this one. The boundary matters because routing is reliable in a way that response drafting is not, and conflating the two is the most common reason these setups stall in pilot.
For the broader pattern of what a single-purpose agent should and should not own, see what an AI agent can actually do. For agents that combine multiple tools cleanly, see how to give an agent multiple tools.
Sources of truth
One webhook is the only trigger. The agent does not poll Typeform; it listens for the form submitted event and acts on the payload. Typeform's developer documentation publishes the webhook schema and signature verification model, and the agent treats that contract as the source of truth for what arrived.
- Typeform webhook payload. Form ID, response ID, answer fields, hidden fields, submitted-at timestamp.
- Webhook signature. Verified on receipt before any processing.
- Contact enrichment provider. Domain-to-company lookup, role enrichment, optional plan-fit signals.
- Destination map. A small configuration file you own; the agent reads it, never edits it.
What the agent does not read: the rest of your CRM, the rest of your support inbox, the rest of the company's email. Stay scoped to the submission and the destination.
The six intents to classify
Most general contact forms collapse to six intents. The number matters less than the discipline of fixing the set in advance and routing each one to a distinct destination.
- Sales lead. "We're evaluating", "pricing", "demo", "trial", a known buyer role from a fitting company.
- Support request. Existing customer, account email matches a record, language signals an issue or how-to question.
- Partnership ask. Co-marketing, integration, channel, agency offer, "partner with us".
- Recruiting. Candidate inbound, resume attached, role mentioned, application-shaped language.
- Spam. SEO outreach, generic agency pitches, link-building offers, gibberish.
- Survey or research. Journalist, student, analyst, "I'm writing a piece on", "for my thesis".
If the agent is uncertain between two intents, it routes to the more conservative one and tags the response for human review. Sales lead is more conservative than spam (a lost spam tag is harmless, a lost sales lead is not). Partnership is more conservative than recruiting. The conservative-default rule keeps the failure mode aligned with the cost of the failure.
Destination mapping
The destination map is a small configuration file that you write once and update rarely. Each intent maps to a primary destination and an optional secondary mirror. The primary destination is the system of record where the response will be worked. The secondary mirror is a notification surface where the team that owns the destination gets pinged.
- Sales lead. Primary: CRM record in the inbound queue. Mirror: #sales-inbound Slack channel.
- Support request. Primary: support inbox or helpdesk ticket. Mirror: #support-triage Slack channel.
- Partnership ask. Primary: a partnerships Notion or Linear queue. Mirror: #partnerships Slack channel.
- Recruiting. Primary: ATS candidate record. Mirror: #recruiting-inbound Slack channel.
- Spam. Primary: a quiet archive log. Mirror: none.
- Survey or research. Primary: a research-requests Airtable. Mirror: #pr Slack channel if the submitter is a journalist.
The agent reads this map and routes accordingly. New intents require a new entry; the agent does not invent destinations. For the Slack mirror surface specifically, see how to connect an agent to Slack; the same boundaries apply to webhook deliveries elsewhere.
Enrichment
Before routing, the agent enriches the contact from the submitter's email domain. Enrichment is a small, fixed set of fields, not a panel. The point is to give the destination owner enough context to triage in one glance, not to build a profile.
- Company name. From the domain, falling back to the raw domain if the lookup fails.
- Industry and size band. Coarse buckets, used as routing signal for sales lead vs spam.
- Role. From the submitter's name and the company directory if available.
- Plan-fit signal. A boolean that the destination owner can sort by, computed from your existing ICP rules.
Free webmail domains (gmail, outlook, yahoo) skip the company lookup and route on language signals alone. Enriching a personal email returns nothing useful and risks routing a hobby project as an enterprise lead.
The enriched fields write to the destination record (CRM custom fields, ATS notes), not to the Slack mirror. Slack stays as a one-line summary plus a link back. For the broader pattern of compressing enriched data into a notification, see how to monitor agent activity.
Guardrails
- Never auto-reply. The agent has no outbound channel to the submitter. Replies belong to the destination owner.
- Verify the webhook signature. Every submission. Unsigned payloads are dropped, not processed.
- One destination per intent per run. No duplicate routing to "be safe".
- Slack summary strips PII. Company, role, intent. No email address, no free-text body.
- Conservative-default on ambiguous intent. Route to the higher-cost-of-miss destination and tag for review.
- Human approval on first-touch destinations. The first week, every routing decision gets a quick human ack before delivery. Graduate by intent.
For the human-in-the-loop pattern during the pilot phase, see how to add a human approval step to an agent. For broader operational guardrails, see AI agent safety and guardrails.
Common mistakes
- Single destination for everything. "Just send it all to Slack" recreates the inbox problem with a different surface.
- No enrichment. The destination owner spends 30 seconds per submission re-doing the lookup the agent could have done once.
- Over-routing. Mirroring every submission to four channels means no one channel owns the response.
- Letting the agent reply. A polite "thanks, we'll get back to you" from the agent feels off and complicates the human reply that follows.
- Static destination map. The org changes, the map does not, and a year later the sales channel is dead and submissions land in a ghost queue.
- Treating spam as a hard delete. Quiet log first, hard delete after a month of review. Spam misclassifications happen.
If you have already built an inbox triage agent, the form routing agent runs in parallel and removes load from that one rather than duplicating it. Structured webhooks are easier to route than free-form email; the form agent should be doing the deterministic work and leaving the inbox agent to handle the unstructured remainder.
Frequently asked questions
How is this different from an inbox triage agent?
An inbox triage agent reads free-form email and decides what to do with each message. A Typeform routing agent receives structured webhook submissions where the fields are known in advance, so classification is faster and routing is deterministic once intent is set. The two agents share guardrails but operate on different sources. If your form notifications all dump into one inbox, the routing agent removes that bottleneck at the source rather than untangling it downstream.
Does this agent ever reply to the person who submitted the form?
No. The routing agent never sends an outbound message to the submitter. Replies belong to the team that owns the destination. Sales replies to sales leads, support replies to support tickets, recruiters reply to candidates. The routing agent stops at delivery. If you want auto-acknowledgement, Typeform's built-in respondent notification covers that without involving the agent.
What intents should the agent classify into?
Six is a reasonable default for a general contact form: sales lead, support request, partnership ask, recruiting, spam, and survey or research. You can collapse to four if your form is narrower. Avoid creating ten intents that look distinct but route to the same destination; the destination map is the real test, not the intent label.
How does the agent know which destination to route to?
A destination map you configure once. Each intent maps to a primary destination (a CRM stage, a Slack channel, a support inbox, an ATS) and an optional secondary mirror. The agent reads the map; it does not invent destinations. New intents require a new map entry, not a guess. This is what keeps routing predictable for the team that watches the destinations.
Will the enrichment step leak PII into Slack?
Only if you let it. The one-line summary the agent posts to Slack should include the company name, role, and intent, not the full submission body. The full record lives in the destination of record (CRM, ATS, support tool) which has its own access controls. Slack is a notification surface, not a system of record. The default Gravity template strips email addresses and free-text fields from the Slack post and links back to the source instead.
Three takeaways before you close this tab
- Route at the source. The form is the right place to fork, not the inbox downstream.
- Destination map is the contract. Intents without a destination are just labels.
- Routing is not replying. Keep the boundaries clean or the agent stalls in pilot.
Sources
- Typeform Developer, "Webhooks: receiving responses", retrieved 2026-05-12, typeform.com/developers/webhooks
- Typeform Developer, "Webhook payload reference", retrieved 2026-05-12, typeform.com/developers/webhooks/example-payload
- Oldroyd, J., McElheran, K., Elkington, D., "The Short Life of Online Sales Leads", Harvard Business Review, March 2011, hbr.org/2011/03/the-short-life-of-online-sales-leads
- Lead Response Management Study, "Response time and contact-rate findings", retrieved 2026-05-12, leadresponsemanagement.org/lrm_study
- Aryan Agarwal, "Gravity form-routing agent guardrails", internal v1, May 2026, About