How to Prepare for an Automation Discovery Call: The 7 Questions You Will Be Asked (2026)

What to bring, what not to send, and what each of the seven questions is really for, so a 30-minute call ends in a recommendation rather than a pitch.

Last verified: 10 September 2026 · Prem Patel, Nex Automations

An automation discovery call is worth 30 minutes when the business problem is real but the right scope, platform or approach is not yet clear. Prepare one process, expect seven questions, and leave with a recommendation rather than a pitch. That is the shape of a good one, and knowing the questions in advance is what turns a pleasant chat into a decision.

This guide is what to bring, what not to send, and what each question is really for, written from running these calls for 210+ clients across 12+ countries as a Make.com Level 5 Expert and Zapier Certified Expert. If you have read enough and want the slot, the free 30-minute consult is on Google Meet, in your timezone.

Who should book one, and who should not

Book when a repetitive process crosses several tools, a live automation keeps failing, your team disagrees about how the workflow should run, or AI might help but nobody knows how much autonomy is acceptable. Book too when you have a budget and a deadline and want a straight answer on whether either is realistic.

Do not book when you only need instructions for a standard native integration two tools already offer, when the process has never been run manually even once, or when nobody with authority over the process can attend. In the first case the answer is a help article; in the other two, the call cannot produce a decision anyone can act on.

What to bring

Five things, none of which need to be polished:

1. A plain-language description of the current process. What starts it, what happens, what it ends in. "Every morning we copy new Shopify orders into a sheet and email the warehouse" is enough.
2. The outcome you want. Faster, fewer errors, less manual work, a person freed up. Name the one that matters most.
3. Rough volume. Events per day or per month, and how quickly each needs handling. This is the number that decides which platform tier you would pay for, so an estimate beats a shrug.
4. The tools involved, including the one everybody complains about.
5. The known exceptions. The order that is always different, the client who needs the manual step, the report that is late every quarter-end.

A two-minute screen recording of the process, or a redacted sample record, does more than any of the five. It shows the fields and the clicks a description leaves out.

What not to send

Do not put production passwords, API keys, customer exports, payment data or health records in a booking form or an email. Discovery needs none of it. Describe the data instead: the fields, the volume, where it lives, who can see it.

If a later audit or build needs access, it should be the least privilege that does the job, through delegated access or a separate collaborator account with multi-factor authentication, with credentials that stay yours and can be revoked at handover. A consultant who asks for your master login before an engagement exists is telling you something about how they work.

The seven questions, and why each one is asked

1. What should be different afterwards? Faster, safer, cheaper, more reliable, or someone's evening back. This decides what "done" means, and it is asked first because everything else is measured against it.

2. How does the process run today? The trigger, the decisions, the handoffs, and the final system of record. Most automations fail on the handoff nobody mentioned, so this question is deliberately slow.

3. Which cases cannot follow the happy path? The exceptions are where the cost lives. A workflow that handles 95 percent of cases automatically and routes the other 5 percent to a person is a good system; one that tries to handle 100 percent is usually a broken one.

4. How much, and how fast? Events per month, bundles per event, polling frequency and the acceptable delay. This is the question that turns into a platform tier and a price. The Zapier vs Make vs n8n cost calculator does the same arithmetic in public if you want to see it before the call.

5. What could go wrong that matters? Customer contact, payments, deletions, compliance, data residency. The answer decides how much of the build is error handling, and whether AI is allowed to decide anything alone.

6. Who owns this after launch? Who approves changes, who gets the alert at 2 a.m., who maintains it. If the answer is "nobody yet", that is a finding, not a problem with you.

7. What is the sensible next step? No build, a documented audit, a fixed-scope workflow, or a phased custom system. This is the recommendation, and it is allowed to be "do not automate this".

The call is not a substitute for paid architecture when the process is genuinely complex. Its job is to decide whether deeper discovery is warranted and what that discovery would have to answer.

What you should receive afterwards

For a suitable project: a written summary of the understood problem, the assumptions made, the proposed engagement, the exclusions, what is needed from you, and the next commercial step. Any price should reference that scope and carry a validity date. A quote with no scope attached is a guess with a currency symbol.

If the request is not a fit, the useful outcome is a direct explanation: use a native feature, test the process manually first, fix the source data before automating it, or hire a specialist in a different field. Being told that in 30 minutes is worth more than a proposal that pretends otherwise.

Three ways a discovery call goes wrong, and how to tell

It becomes a demo. Twenty minutes on the consultant's platform of choice and five on your process. You can tell because none of the seven questions above were asked, and the tool was named before the trigger was. A good call is platform-neutral until question four, when volume and budget make the platform obvious.

It becomes a specification session. The consultant tries to design the whole system live, and the call ends with a diagram and no decision. Discovery decides whether and what shape; it does not design. If the process is complex enough to need a design session, the right outcome is "this warrants paid architecture, here is what it would answer", not a sketch on a shared screen.

It becomes a pitch. A price appears before the exceptions and the risk have been discussed. A quote that arrives before question five is a quote for the happy path only, and the exceptions will be invoiced later. The tell is a number with no scope attached to it. Ask for the scope in writing, with the exclusions, and see whether the number survives.

None of these means the consultant is dishonest. They mean the call was run for the seller's convenience rather than the buyer's decision, and you can steer it back by asking for the question that was skipped.

When a fixed-scope package is the better door

If the trigger, the applications, the actions, a data sample and an acceptance test are already clear, you may not need a call at all. A fixed-scope build, whether direct or as a marketplace package, gets you a price and a start date faster. The fixed-scope versus custom guide is the test for whether you are there, and which automation service you need is the wider decision.

If you only have ten minutes to prepare

Write five sentences, one for each thing to bring: what the process is, what you want to be different, roughly how often it runs, which tools it touches, and the exception that annoys you most. Send nothing else. Then decide on one question to ask back, and the most useful one is "what would make you tell me not to automate this?" A consultant with a real answer has done this before; one without an answer is going to sell you a build either way.

If you cannot even name the process, book anyway and say so at the start. Mapping the confusion is a legitimate use of the 30 minutes, and it is cheaper than guessing which of your problems to describe. What you should not do is spend the ten minutes producing a slide deck; nobody on the call needs one, and it tends to describe the process as it is supposed to run rather than as it does.

Book it, or write instead

If the call is the right next step, the free 30-minute consult is on Google Meet and the calendar shows times in your timezone. If you would rather write than talk, the fit-check form on the same page takes two minutes and gets a reply within 24 hours. Either way, what we build and what it costs is on the services page, so nothing on the call is a surprise.

Frequently asked questions

What is an automation discovery call?

A short working session, 30 minutes in our case, where you describe a process that is costing you time and an automation builder works out whether automation fixes it, which tools fit, and roughly what it would cost. It is diagnosis, not a sales presentation. You leave with a recommendation even if the recommendation is "do not build this".

What should I prepare for an automation consultation?

One specific process, described in plain language: what starts it, what happens, what it ends in, and roughly how often it runs. The tools involved, the person who owns the process, and any known exceptions. A screen recording or a redacted example is worth more than a slide deck. You do not need a specification.

What questions will an automation consultant ask?

Expect seven: what outcome you want, how the process runs today, which cases cannot follow the happy path, how much volume and how fast it needs to be, what could go wrong with customers, money or compliance, who owns the process after launch, and what the sensible next step is. If a consultant asks none of those and quotes anyway, be careful.

Should I share passwords or customer data before the call?

No. Discovery needs no production access. Describe the data; do not send it. Credentials, exports, payment records and health data are discussed only after an engagement and a handling method are agreed, and then through delegated access rather than a shared master password.

Is the discovery call free?

Ours is, 30 minutes on Google Meet, no charge and nothing to buy at the end. Paid architecture work exists for complex systems, but that comes after the call and only if the call shows it is warranted.

What happens after an automation discovery call?

For a suitable project you receive a written summary of the understood problem, the assumptions, the proposed engagement, the exclusions, what we need from you, and a fixed-scope quote with a validity date. If it is not a fit, you get a straight explanation and the cheaper route: a native feature, a different plan, or a specialist in another field.

Related reading

• Which Automation Service Do You Actually Need?
• Fixed-Scope vs Custom Automation Project
• What to Look for When Hiring an Automation Expert
• How to Verify an AI Automation Expert