How to automate client intake for an agency or consultancy

This guide from AR Labs is for founders and client-services leads at owner-led marketing, design, web, software and consulting firms who want to automate client intake. A prospect writes "we need a new website, can we talk?", you book an hour, and most of it goes on questions a form could have answered. The guide shows how to turn that enquiry into a confirmed brief before the first call: what the brief contains, who gets a call, which tools already do most of the work, and where custom software or AI could add something after that.

It applies our general method for mapping a business process before automating it, and rests on agency owners' and consultants' posts in public forums and on the tool vendors' own pages. The closest thing we have built is a browser demonstration of a guided discovery conversation, described near the end; we have not built an intake system for an agency.

Why discovery calls get used up on basics

In public discussions about onboarding, one agency operator described spending 40 minutes of a 60-minute kickoff collecting basic information, and others in the thread described the same. Another agency owner put high client churn down partly to not saying no to the wrong kind of customer. Consultants talk about wanting a defined process they can guide each prospect through, which captures expectations and agrees the next step.

Behind those accounts sit a few specific failures. The contact form collects a name, an email and a free-text box, but not the facts needed to decide whether a call is worth having. Prospects book before need, fit and timing are understood, and a senior person asks the same opening questions every time. Gaps such as who must approve the work or what the budget really is surface during or after the call, and what the prospect said in sales does not reach the people who deliver the work.

flowchart TD
  E["Enquiry: contact form or email"] --> R["Owner reads a short message"]
  R --> B["Call booked by reply or calendar link"]
  B --> C["Discovery call: basics collected live"]
  C --> G{"Owner: is this a fit?"}
  G -->|"unclear"| F["Follow-up emails for missing details"]
  F --> G
  G -->|"yes"| P["Proposal written from call notes"]
  G -->|"no"| X["Polite decline, after the hour is spent"]
  P --> H["Delivery team re-asks the basics"]

The common current flow: the fit decision and the basic facts both arrive late, and the delivery team starts again.

What existing tools already do

Established tools already cover most of this, and several have free plans. Before building anything, check what these categories do:

• Form builders such as Typeform, Fillout, Tally, Jotform and Google Forms ask different questions depending on earlier answers. Typeform offers branching and automated workflows, with integrations into tools such as Salesforce and Google Sheets (Typeform). Fillout's free plan includes review pages, resuming in-progress forms, scheduling forms and most of its integrations (Fillout pricing and features). Tally offers conditional logic and calculations, with unlimited forms and submissions on its free plan within its fair-use guidelines (Tally).
• Scorecard tools such as ScoreApp build quizzes that calculate scores, show different results by score tier and connect to a CRM, the customer relationship management software that holds your contacts and deals (ScoreApp).
• Chat builders such as Landbot run scripted flows and AI answers on a website, with a team inbox and hand-over to a person (Landbot).
• Client-request tools such as Content Snare collect information and files through templated requests, scheduled reminders and a client portal, and let you reject a single wrong item (Content Snare).
• Client-management suites such as Dubsado cover lead capture forms, questionnaires, proposals, contracts and invoices in one place (Dubsado features).
• Proposal tools such as Qwilr produce proposals from CRM records in Salesforce and other CRMs (Qwilr integrations).

A form follows the rules you set; noticing that an answer is vague or contradicts another, and asking a sensible follow-up, is left to the person who reads it. For many firms that is enough, and the steps below make that reading quick.

Step 1: Decide what the first call is for

What to do. Write one sentence for the purpose of your first call and one for what it is not for. Then list the decisions you want to make before it happens.

Why. Everything that can be known before the call should be, and the list of pre-call decisions becomes the brief.

Example. "The first call tests our understanding of the problem and agrees whether a paid discovery phase makes sense. It is not for learning what the company does, who decides, or when they need it."

• Purpose of the first call written in one sentence
• Decisions to make before the call listed
• Agreed by everyone who takes first calls

Step 2: Define the brief in five to eight areas

What to do. Choose the information areas the brief must cover. A workable starting set for project work: the problem and its context, the outcome wanted, scope clues (what is in and out), the current state (existing site, systems, suppliers), constraints, stakeholders and who approves, timeline, and budget or readiness. For each area, write what a good answer looks like and what a vague one looks like.

Why. Naming areas rather than questions lets you ask differently for different prospects and still know when the brief is complete. The vague version tells the reviewer when to ask again.

Example. For "outcome wanted", a vague answer is "more leads". A usable one is "twice as many demo requests from mid-size manufacturers, measured in our CRM". For "stakeholders", a vague answer is "me and the team"; a usable one names who signs the contract.

• Five to eight information areas chosen
• Good and vague examples written for each
• Budget or readiness asked in a form prospects can answer, such as ranges

Step 3: Set clear routing outcomes

What to do. Decide the outcomes of a reviewed enquiry and the rule for each. Three are usually enough: book a call, ask for more information, or decline or defer. Name the person who decides.

Why. Without explicit outcomes, every enquiry gets a call by default. Simple rules also let someone other than the founder triage. Keep any score secondary to the brief itself: a number alone hides why someone was declined.

Example. Book: problem and outcome are clear, budget range fits, the decision-maker will attend. Ask for more: the outcome is vague or the approver unknown. Decline or defer: the work is outside your services or too far out, with a reply that points them somewhere useful.

• Three outcomes defined with plain rules
• A named person decides on each enquiry
• Polite templates written for "ask for more" and "decline or defer"

Step 4: Build the intake form

What to do. Build a form that covers your areas, using a form builder you already own if possible. Start with a short opening question that sorts the enquiry type, then branch. Use open text for the problem and outcome, and choices or ranges for timeline and budget. Add a review page so the prospect sees their answers before submitting. Tell them how long the form is, what happens next, and how you will store and use what they send.

Why. Prospects finish a short form that asks only what applies to them; a long fixed one loses good prospects. A review page is the cheapest correction you will get. A prospect's details are personal data, so data-protection law applies to how you collect and keep them; check the rules where you operate and ask only for what the decision needs.

Example. A web agency's form asks "What do you need help with?": new site, redesign, ongoing support or not sure. "Redesign" asks about the current site, what is not working and who maintains it; "not sure" asks two open questions and offers a short call.

• Form covers every area from step 2
• Opening question branches by enquiry type
• Review page before submission
• Expected length, next step and use of the data stated at the start

Step 5: Review, then confirm the brief with the prospect

What to do. When a submission arrives, the named person reads it against the good and vague examples, writes a short brief in your own template, and sends it back to the prospect: "Here is what we understood. Is anything wrong or missing?" Book the call only after they reply or correct it.

Why. Confirmation separates what the prospect said from what you inferred. A correction now costs one email; the same correction mid-project costs far more.

Example. "You want to replace a site built in 2019 because product pages are hard to update. Success is your marketing lead updating pages without a developer. Your MD approves spend. You mentioned launching before a trade show in spring. We have assumed the existing hosting stays. Is that right?"

flowchart TD
  E["Enquiry"] --> F["Branching intake form with review page"]
  F --> S["Submission stored with original answers"]
  S --> R{"Named person reviews against brief template"}
  R -->|"vague or missing"| M["Ask for more: one targeted question"]
  M --> S
  R -->|"not a fit"| X["Decline or defer with a useful pointer"]
  R -->|"fit"| B["Draft brief sent to prospect"]
  B --> C{"Prospect confirms or corrects"}
  C --> K["Call booked; brief in CRM"]
  K --> D["Delivery team receives the confirmed brief"]

The target flow. Diamonds are decisions made by a person: the reviewer and the prospect.

• Each submission reviewed by a named person
• Brief written from a template and sent back for confirmation
• Inferred items labelled as assumptions
• Call booked after confirmation

Step 6: Connect scheduling and the record

What to do. Decide where the confirmed brief lives (your CRM, project tool or a shared folder) and use the form builder's built-in integrations to send submissions there. Offer a booking link only to enquiries routed to "book", rather than putting it on the public page.

Why. A brief that sits in an inbox gets re-typed or lost, and a public calendar link with no questions turns every enquiry into an hour of your time. Automate the replies only once your routing rules and templates work by hand.

Example. Submissions become CRM deals with the original answers attached; when the reviewer marks "book", the CRM sends a calendar link.

• One agreed home for confirmed briefs
• Submissions arrive there without re-typing
• Booking link sent only after review

Step 7: Carry the brief into delivery

What to do. Make the confirmed brief, with the call notes added, the first document in the project. The kickoff starts by reading it back rather than asking from scratch.

Why. The delivery team starts from what the client has already told you and confirmed, and the client does not answer the same questions twice.

Example. The project manager opens with "this is what we agreed in the brief; what has changed?"

• Brief attached to the project record
• Kickoff agenda starts from the brief

Step 8: Measure and adjust

What to do. Track, for a period, how many enquiries were booked, asked for more, or declined, how many briefs prospects corrected and what they corrected, and how much of each first call went on basics.

Why. Corrections show which questions are unclear, and time on basics shows whether the change worked. An area where prospects routinely answer vaguely is the one place an adaptive follow-up might help.

Example. If most corrections are about who approves the budget, add a direct question about the approval process and make it required.

• Routing outcomes counted
• Corrections recorded by area
• Questions revised from what the counts show

Choosing how far to go

Each row costs more than the one above it; the ladder of changes in the process mapping guide explains the general rule.

Approach	What it involves	Good fit when	Limits
By hand	A brief template, a short form or email questionnaire, the founder reviews and replies	Low enquiry volume; founder takes every first call	Founder's time is the bottleneck
Configure an existing tool	Branching form with review page in a form builder or client-management suite; scoring if useful	Volume is steady and enquiry types are known	Reads answers but does not ask follow-ups; a person still interprets
Connect tools	Form to CRM, calendar link sent on review, brief template filled from the submission	Briefs are being re-typed or lost between tools	Each connection needs testing and an owner
Build custom	A guided conversation that notices vague or missing answers, asks one follow-up, drafts the brief and asks the prospect to confirm it, then hands it to a person	Measured gaps remain: vague answers in the same areas despite good questions	More cost and testing; must deliver into your CRM, not become another inbox

The custom row describes the pattern behind our Salesbot, a voice agent that runs in the browser and holds a short discovery conversation. It is a structured conversation: the language model talks, while code tracks which answers are still missing and when to move on, and the answers are read back before it closes. Salesbot is a demonstration of the pattern, not a packaged intake product.

AR Labs offers this kind of discovery and design work to owner-led firms; more about us is on the about page.