Phone intake forms
Web forms are efficient for people who can see, complete, and submit them. They are less useful when someone is driving, has limited internet access, needs clarification, or simply prefers to call. A free-form phone message solves the access problem but creates another one: missing spellings, incomplete dates, vague descriptions, and records that staff must re-enter.
A phone intake form uses a conversation to collect a defined set of fields. The AI phone agent asks one question at a time, follows conditional branches, confirms important answers, and submits a structured record through an approved integration. It is a configured call flow rather than a packaged artifact. Industry-specific decisions still belong on the relevant industry workflow; this page covers the collection function itself.
A concrete phone intake
Suppose a property services company needs a request type, service address, contact details, access notes, and preferred timing before it can review a job.
Agent: I can collect your service request for review. I’ll ask for contact, location, and job details. What name should the team use?
Caller: Maya Chen.
Agent: Please spell your last name.
Caller: C-H-E-N.
Agent: Thank you. What is the service address, including unit number if there is one?
Caller: 840 Pine Street, unit 3B.
Agent: I have 840 Pine Street, unit 3B. What needs attention?
Caller: Water is dripping under the kitchen sink. I have shut off the valve.
Agent: I’ll record the leak and that the valve is off. Is water still spreading or creating an electrical hazard?
Caller: No.
Agent: Thank you. I’ll finish the contact and access questions, then submit the request for the team to review. This call does not confirm an appointment.
The agent confirms high-error fields, uses a safety branch, and distinguishes intake from approval or scheduling. If the caller reports active flooding near electricity, the configured urgent route should take priority over finishing every question.
How to configure it on ThunderPhone
Begin with a field map owned by the team that receives the record. Mark each field as required, optional, conditional, or prohibited. Then express the sequence and branches in the agent prompt:
- Explain the purpose of the intake and what submission does or does not guarantee.
- Collect identifying and contact fields using the organization’s policy.
- Ask the core questions in a stable order, then open conditional branches from specific answers.
- Read back names, email spellings, phone numbers, addresses, dates, and other error-prone details.
- Skip irrelevant branches without silently inventing a value.
- Confirm the summary, obtain any required acknowledgment, and submit or route the record.
- Stop ordinary intake when an urgent, unsafe, sensitive, or out-of-scope condition is reported.
Connect the submission destination from the real integration catalog. HubSpot or Salesforce can receive intake for workflows already managed there. Google Sheets can hold a lightweight reviewed intake table. A custom system can expose a REST action, or a remote Zapier MCP server can provide an approved tool after it is added by URL, synchronized, and attached to the agent. Static HTTP headers are supported for remote MCP. Use only the fields and actions the receiving workflow actually exposes.
For event-driven processing, ThunderPhone supports multiple webhook endpoints with separate secrets and subscriptions, HMAC-SHA256 signatures, and exponential-backoff retries for non-blocking deliveries. Include a stable source identifier from the receiving workflow where available, along with the captured fields, completion state, exception reason, and final call disposition. Decide how the receiving system handles a retry so the same completed call does not create duplicate work.
If the intake ends in booking, connect Cal.com or Google Calendar through the approved scheduling workflow and keep the distinction clear: submitting an intake record is not the same as confirming a time. A dedicated appointment scheduling flow should check availability and read the confirmed details back to the caller.
Use an inbound demo U.S. number for early tests, remembering that demo numbers are not intended for production. Move the final agent to the appropriate production number. Configure a transfer target for exceptions; warm transfer requires an eligible production number with an outbound SIP leg, while demo and browser calls are limited to cold transfer.
Test every branch, not just the happy path. Include missing required fields, corrected spellings, ambiguous dates, a caller who does not know an answer, an integration failure, an urgent condition, and a failed transfer. Reusable scenarios and graded call logs can enforce completion and boundary rules as the prompt changes.
What to measure
Measure whether the receiving team gets a usable record:
- completion rate by intake type and branch;
- required-field completeness;
- correction rate for names, dates, addresses, and contact details;
- successful submission and integration-failure rates;
- duplicate records from retries or repeat calls;
- records returned to staff for clarification; and
- urgent or out-of-scope calls routed correctly.
A short call with missing fields is not efficient. Review the call flow where callers abandon, repeatedly correct the agent, or reach a question they cannot answer.
Honest limits
A conversational intake cannot validate every statement, inspect supporting evidence, or decide whether a request should be approved. It should not collect secrets or unnecessary sensitive data, and it should not imply that submission creates a contract, appointment, eligibility decision, or guaranteed response time. Complex explanations, distressed callers, disputed details, and judgment-heavy cases need a person.
Use narrower workflows when the next decision is specialized: client intake for professional services, quote request intake for estimating, or support triage when the caller needs troubleshooting rather than field collection.
Create your ThunderPhone account to configure and test a phone intake form.