How to systemise your consulting intake process

Pick one lead path, map it end to end, and automate that single path before touching anything else. That is the whole strategy.

A working intake system has five parts. Capture collects the lead. Qualification filters for fit. Routing decides who handles it. Booking puts a call in the diary. Record creation opens the client file. Get those five working on one path and you have something you can replicate.

Decisions to make before you build:

• Who owns intake? Name one person, not "the team".
• What data do you need to qualify a lead? List the exact fields.
• What are your routing rules? Which lead types go to which person?
• What is your maximum response time before a lead goes cold?
• Where does the client record live, and who has write access?

---

Why systemising intake matters for £1M+ consultancies

Speed wins clients. A lead who submits a form and hears nothing for 24 hours has already gone elsewhere. A lead who gets an instant acknowledgement, a qualification question and a booking link inside a few minutes converts far more often.

For a £1M+ founder-led consultancy, the bigger prize is your own hours. Right now you are probably the bottleneck. Leads wait for you to qualify them. Proposals wait for you to approve them. An intake system built on clear routing rules takes you out of the routine decisions so you only handle conversations that need your judgement.

That is the same pattern behind why consultants struggle to scale. The work is not too hard. It is too dependent on one person.

---

Map your current intake before buying or building anything

Do not buy a tool until you know exactly what is broken. Automating a broken process just breaks it faster.

Mapping checklist:

1. List every entry point. Website form, referral email, LinkedIn DM, phone call.
2. For each one, write down what happens next, step by step.
3. Note who does each step and how long it takes.
4. Mark every decision point. "Does this lead qualify?" "Who books the call?"
5. Record every output. Confirmation sent, record created, invite sent.
6. Note where the process breaks or slows down.

Bring in your intake owner, one ops person, and your compliance contact if you handle sensitive data. Record the map in a shared document, not in your head.

Pro Tip: Ask your intake owner to walk you through the last five leads in real time. You will find two or three manual steps nobody ever wrote down. Those are the ones that fail at scale.

---

How to design an intake system with clear routing rules

Think of this as writing a recipe your team, or an AI agent, can follow without asking you. Each stage needs a defined outcome, a routing rule and a handoff condition.

Outcomes by stage:

• Acknowledge: the lead gets a confirmation within five minutes.
• Qualify: the lead answers three to five questions, and the system scores or flags fit.
• Book: qualified leads get a calendar link. Unqualified leads get a polite decline or a nurture sequence.
• Onboard: booked leads get a welcome pack and a pre-work form automatically.

A typical flow: form submitted, confirmation sent, qualification questions triggered, response scored, booking link sent if qualified, booking confirmed, CRM record created, delivery team notified.

Define what a "ready" record looks like for your delivery team. Name, company, budget range, service interest, booked call date, and any compliance flags. If a field is missing, the system should pause and ask for it, not pass an incomplete file downstream.

Pro Tip: Write your routing rules as plain "if this, then that" statements before you touch any tool. If you cannot write the rule in plain English, the automation will not work either.

---

What to automate first

Start with the highest-friction, most repetitive tasks.

Priority order:

• Instant confirmation on form submission.
• Qualification questions.
• Calendar booking for qualified leads.
• Document collection and e-signature for engagement letters.
• CRM record creation and team notification.
• Payment collection, if you take one at intake.

The integration pattern is capture, validate, persist, route, notify. Data flows one way. Nothing gets rekeyed. If a field fails validation, the flow pauses and flags the error before creating a record.

For consulting workflow automation at this level, a proper orchestration layer beats a single all-in-one platform, because your routing rules are almost certainly more complex than a standard intake form can express.

---

Where AI fits, and where it does not

This is where most intake projects go wrong. Founders reach for a connector like Zapier or Make, wire up a few triggers, and find the system still needs them. That is not a tooling failure. A connector moves data between apps. It cannot decide anything, so every judgement call still lands back on your desk.

The step up is an agent that carries your qualification logic. Not "if budget field is over X, route to senior consultant", but the actual reasoning you apply when you read an enquiry and know within ten seconds whether it is worth a call.

That reasoning is your IP. Writing it down so an agent can run it is the real work, and it is why we build these with Claude Code rather than a no-code connector. A non-technical founder can ship a working triage agent in days. Our guide on how AI replicates consultant reasoning covers how that encoding works in practice.

Concrete AI uses in consulting intake:

• Intent triage: an agent reads a free-text enquiry and classifies it for service type, urgency and fit before routing.
• Qualification summary: it turns a long discovery form into three bullets for the consultant.
• Document parsing: it pulls key fields from uploads so nobody re-reads them by hand.
• Drafted follow-up: it writes the personalised reply using your own material and the lead's answers.

Keep chains short. Three to five steps is manageable. Longer chains break in ways that are hard to diagnose.

UK GDPR note: you need a lawful basis for processing personal data collected at intake, and you must state your retention period in your privacy notice. If a US-based AI tool processes personal data, check the data processing agreement and transfer mechanism. The ICO's UK GDPR guidance sets out what is required.

Pro Tip: Use AI for summarisation and routing. Keep deterministic fields (client ID, contract reference, compliance flags) generated by your system, not by a language model. Language models make things up. Your client IDs cannot.

---

How to pick the right tools

Decision checklist:

1. Which systems must connect? CRM, calendar, e-sign, accounting.
2. How complex are your routing rules?
3. What is your monthly lead volume?
4. What response time do you need to hit?
5. Do you handle sensitive personal data with specific compliance controls?

An off-the-shelf intake platform suits simple, linear flows at low volume. An orchestration layer plus point tools suits complex routing, multiple service lines, or anything involving judgement. A partner-built prototype suits founders who want a working system in 90 days without building it themselves.

What actually drives the cost:

Phase	Main cost drivers
Discovery and mapping	Consultant time, process documentation
Prototype build	Number of integrations, routing complexity, AI components
Pilot and iteration	Testing, fixes, staff training
Rollout and support	Hosting, maintenance, ongoing tuning

Indicative timeline:

Week	Phase
1 to 2	Discovery. Map one lead path, define outcomes and routing rules
3 to 5	Prototype. Build the automation for that single path
6 to 8	Pilot. Run in parallel with the manual process
9 to 10	Iterate. Fix errors, adjust routing, retrain staff
11 to 12	Rollout. Switch off manual process, monitor response times

Devwiz makes the same argument from the delivery side in how to productise a service, which is a useful companion read if you are deciding how far to standardise.

---

How to run a pilot that actually tells you something

Start with one lead path. Run the automation in parallel with your manual process for two to four weeks. Do not switch the manual process off until the automation has handled at least 20 to 30 real leads without a critical failure.

Pilot metrics:

Metric	What to measure	Target
Response time	Form submission to first contact	Within a few minutes
Qualification rate	Share of leads that pass qualification	Baseline your current rate first
Booking conversion	Share of qualified leads that book	Compare to your pre-automation baseline
Time per lead	Staff time spent per lead	Reduction from current baseline
Data quality errors	Errors logged per lead volume	Near zero

Log every failure. A dropped lead, a misrouted record or a missed response window is a signal, not a one-off. If the same failure appears three times, fix the rule before you expand to other lead paths.

---

Week-by-week rollout checklist

1. Weeks 1 to 2, discovery. Founder and ops lead map one lead path. Compliance reviews data handling. Routing rules written in plain English.
2. Weeks 3 to 5, build. The prototype gets built. Founder reviews the flow once before testing starts.
3. Weeks 6 to 8, pilot. Automation runs in parallel. Ops lead logs failures daily. Nothing switched off yet.
4. Weeks 9 to 10, iterate. Fix every logged failure. Retrain staff on the new handoff points. Update the rules document.
5. Week 11, acceptance gate. Review the pilot metrics. If data errors are low and response time holds, proceed. If not, extend the pilot.
6. Week 12, rollout. Switch off the manual process. Set alerts for missed response times and record errors. Assign one owner for governance.

Rollback plan: keep the manual process documented and ready to restart. If something critical breaks after rollout, switch back immediately and fix before relaunching.

---

Common mistakes that kill intake automation

Most failures come from one of three places. Automating a broken process. Trying to do every lead path at once. Building with no error alerts.

Red flags during a pilot:

• Leads landing in the CRM with missing fields.
• Booking confirmations going to the wrong person.
• Qualification emails reaching unqualified leads.
• No alert when a step fails silently.

Assign one person to check the system weekly. Log every error. Review the log monthly and fix what recurs. A small data problem at intake becomes a large data problem in delivery.

---

The two traps worth naming

The first trap is building before writing. Founders know intake is broken but cannot say exactly where, so they buy a tool and hope it surfaces the problem. It does not. Write the routing rules in plain English first. Build nothing until they are written. Then automate the rules, not your instinct.

The second trap is scope creep. You start with one lead path and, halfway through, add three more. The prototype never ships. Pick one path. Finish it. Prove it works. Then replicate.

Both traps have the same root cause. Intake feels like admin, so it gets treated as a tooling problem. It is not. It is the first place your judgement leaves the business, which makes it the first place worth encoding properly.

---

The 90-day Program that builds your intake system

If you run a consultancy or education business at £1M+ and your intake still runs on manual effort and founder time, the 90-day Program from The AI Orchestrators is built for this.

It starts with a diagnostic that maps your current intake, your IP and your routing rules. From there the team builds a working prototype for your highest-volume lead path, runs a live pilot, and hands over a system your ops team can manage. No generic templates. No coaching calls about what you should build. An actual working system.

It suits founder-led consultancies and education businesses with paying cohorts and proprietary frameworks that need to scale without the founder in every new client conversation.

Next step: Take the IP assessment to see how monetisable your current process is, or read what the 90-day Program covers.

---

Useful sources

• ICO: UK GDPR guidance and resources, the UK regulator on lawful basis, retention and processor duties.
• Anthropic: Claude Code documentation, the build tool behind the triage agents described above.
• Devwiz: how to productise a service, the delivery-side view on standardising a service offer.

---