The wrong questions end discovery calls before they start.
Not because the buyer isn't serious. Not because the price is wrong. The call stalls because the buyer asks a question that has no answer yet—and when you say "it depends," they hear "you don't know what you're doing."
The three questions below are the ones that derail automation projects before the scope is even clear. If you're shopping for automation right now, you've probably asked at least one of them. Here's why they backfire, and what to ask instead.
Quick Answer
Before you can price automation, you need to know three things: which process you're automating (not "everything"), what the current process actually is (not what you think it should be), and what success looks like in measurable terms. Buyers who ask "how much does automation cost" before answering those three questions get quotes that are either wildly wrong or so vague they're useless. Ask the right questions first, and the price conversation becomes simple.
1. "How much does automation cost?"
This is the question that sounds reasonable and lands nowhere.
You're asking for a number before the scope exists. It's like calling a contractor and asking what a kitchen remodel costs before you've said whether you're replacing cabinets or tearing down a wall. The answer is always "it depends"—and it should be.
What the question actually reveals: you don't know what you're automating yet. You have a feeling that things take too long, that your team is buried, that stuff falls through the cracks. That's real. But "automation" isn't one thing with one price. It's a category that includes everything from a two-hour Zapier flow to a six-week custom AI pipeline.
The difference isn't complexity for its own sake—it's scope. A client onboarding flow that sends three emails and updates a CRM is a different build than one that validates contracts, provisions accounts, schedules kickoffs, and triggers internal task assignments across four tools.
What to ask instead: "What would it cost to automate [specific process]?" Name one workflow. One repeating task your team does manually every time. If you can't name it in one sentence, you're not ready to get a quote yet—you're ready to map your processes first.
The tighter the question, the tighter the answer. "What would it cost to automate our lead follow-up from form submission to first sales call?" gets you a real number. "What would it cost to automate our sales process?" gets you a meeting to figure out what you actually mean.
2. "How long will this take?"
This one sounds like project management. It's actually a scope question in disguise.
The timeline depends entirely on what "this" is—and most buyers haven't defined "this" yet. You think you're asking for an estimate. What you're really asking is: how long until my problem is solved? And the problem isn't one thing; it's ten things that all feel urgent right now.
The trap: you want everything automated at once, but you're pricing it like it's one project. So when someone says "two weeks," you hear "in two weeks, all my operational chaos is over." What they mean is "in two weeks, the first system is live"—and you still have nine more on the list.
Here's what actually happens on most projects: the first workflow goes live in days. Then you realize three adjacent processes feed into it, and those need automation too. Then you see that the data coming out of the first system could trigger two other workflows you hadn't thought of yet. The work doesn't take longer because the vendor is slow—it takes longer because the problem is bigger than you thought.
One client described their event ticketing process on a call: people showed up through Instagram posts and word of mouth, everything was open to the public, and they wanted a system where applications went through a Typeform, got stored in a CRM, and VIP or regular attendees were automatically approved when applications closed. They also asked how to handle repeat applicants in the Typeform. That level of clarity—knowing the current flow, the desired flow, and the edge cases—is what makes a project move. Later in the conversation, they described how the same infrastructure could let them pre-sell tickets for future events, manage VIP lists, and embed a calendar on their website. The original scope didn't take longer—the vision expanded once they understood what the foundation could support.
What to ask instead: "How long until the first workflow is live?" Scope one process, build it, test it, and then decide what's next. The ones who try to automate everything at once spend months in discovery without a single system live.
If you want speed, shrink the scope. One live system beats ten half-planned ones.
3. "Can you automate everything we do?"
This is the question that sounds ambitious and actually guarantees nothing gets done.
Yes, technically, most things can be automated. No, you should not automate everything at once. And no, automating everything doesn't mean your business runs itself—it means you've built a system so complex that no one understands it anymore.
The real issue: you're trying to solve every operational problem in one project. You want the vendor to audit your entire business, identify every inefficiency, prioritize the fixes, and build them all. That's not an automation project—that's Operations as a Service, and it's a completely different engagement.
Automation works when you know what to automate. It fails when you're hoping the vendor will tell you. If you don't know which processes are costing you the most time, the most money, or the most errors, start with an operations audit—not a build.
What happens when you try to automate everything: you get a proposal so big you never sign it, or you sign it and six weeks later you're drowning in half-built systems that don't talk to each other. The clients who get the most value are the ones who say "fix this one thing first" and then come back for the next thing once the first one is working.
What to ask instead: "Which process should we automate first?" If the vendor is any good, they'll ask you three questions back: where do tasks fall through the cracks most often? Where does your team spend the most time on repetitive work? Where do errors cost you money or credibility? The answer to those questions is where you start—not with everything.
One process, live and working, teaches you more about automation than ten processes planned on a whiteboard.
What the right questions actually sound like
Here's a real example from a discovery call. The client ran events and their team was buried in manual ticketing. Instead of asking "how much does automation cost," they walked through their current process:
"Our current flow, people just show up. We post on Instagram or the artist posts, word of mouth spreads, and it's all open to the public. What we want is: we post on Instagram or send an email blast, people click the link, they go to the Typeform, and when applications close, anyone marked as VIP or regular in the CRM gets automatically approved for the event."
That's a scope. That's a process with a start, a middle, and an end. That's something you can price and build.
They also asked: "If they've already submitted the form before, how do we handle repeat applicants in the Typeform?" That's the kind of question that makes a project go faster, not slower—because it's specific enough to answer before the build starts.
And then they expanded it, because they had a foundation that actually ran.
The question no one asks (but should)
Here's the one question that almost never comes up on a discovery call, and it's the most important one:
"What does success look like for this automation?"
Not "I want it to save time." Not "I want it to reduce errors." What does success look like in terms you can measure? How many hours per week does your team spend on this process now? How many errors happen per month? What's the cost of those errors?
If you can't answer that, you can't measure automation ROI—and if you can't measure ROI, you have no idea whether the system worked.
At Systemized Flow, our clients have seen results like cutting manual follow-ups by 70% and saving teams 15 to 20 hours per week. Those numbers exist because the clients knew what they were measuring before we built anything. The ones who don't know what success looks like end up with a system that works perfectly and still feels like it didn't solve the problem—because they never defined the problem in measurable terms.
What to do before you talk to a vendor
If you're shopping for automation right now, do this before you get on a call:
1. Pick one process. Not your whole business. One workflow that repeats at least weekly and involves at least three manual steps. Write down every step, in order, from trigger to completion. If you can't do that in ten minutes, the process isn't clear enough to automate yet.
2. Measure the current state. How long does this process take right now? How many times per week does your team do it? How many errors or delays happen per month? You don't need perfect data—you need a baseline.
3. Define what success looks like. If this process were automated, what would change? Time saved? Errors eliminated? Faster response time? Pick one metric and write down the target. "Cut this from 30 minutes to 5 minutes per instance" is a success condition. "Make it better" is not.
Do those three things and the discovery call becomes focused and efficient—because you're not figuring out what you want while the vendor is on the clock.
Why this matters more than the tools
You'll see a lot of content about which automation platform is best—Make.com vs n8n vs Zapier, whether to use AI-powered workflows, how to choose between no-code and custom code. None of that matters if you don't know what you're automating.
The tool is the last decision, not the first one. The first decision is: which process is costing you the most right now, and what does solving it look like? Answer that, and the tool question answers itself.
Most discovery calls die because the buyer is asking tool questions when they haven't answered process questions yet. The vendor can't give you a number until you give them a scope. The scope doesn't exist until you map the process. And the process doesn't get mapped until you stop trying to automate everything and pick one thing.
What happens when you ask the right questions
When you show up to a discovery call with a process mapped, a baseline measured, and a success condition defined, three things happen:
1. You get a real quote. Not "it depends." Not a range so wide it's useless. A number, with a scope, and a timeline.
2. The project starts faster. No three-week discovery phase. No endless back-and-forth about what you actually want. The vendor knows what to build, so they build it.
3. You know whether it worked. You had a baseline. You had a target. You can measure whether the automation hit it. If it didn't, you know what to fix. If it did, you know what to automate next.
The clients who get the most value are the ones who show up with one process, clearly defined, and a specific outcome in mind. They see the results immediately. And they come back for the next process, because they know exactly what they're buying.
Frequently Asked Questions
What if I don't know which process to automate first?
Start with the process that causes the most pain right now—not the one that sounds most impressive to automate. Ask your team: where do tasks fall through the cracks most often? Where do you spend the most time on repetitive work? Where do errors cost you money or credibility? The answer to one of those questions is your starting point. If you still can't decide, run an operations audit before you talk to a vendor.
How do I know if a process is actually automatable?
If the process has clear steps, repeats regularly, and doesn't require human judgment at every decision point, it's automatable. The easiest processes to automate are the ones that follow the same path every time: a form is submitted, data is validated, a record is created, an email is sent, a task is assigned. The hardest processes to automate are the ones where every instance is different and requires creative problem-solving. If you're not sure, describe the process to a vendor—they'll tell you in five minutes whether it's a good fit.
What's a reasonable timeline for the first automation?
Timeline depends entirely on scope—how many systems the workflow touches, how much custom logic it needs, and how clean your data is. A well-defined workflow with clear inputs and outputs goes live faster than one that requires heavy transformation or integration work. If a vendor quotes you months for a single process, ask what's driving the timeline—it's either a genuinely complex scope or a sign the project needs to be broken down. The fastest projects are the ones where the buyer shows up with the process already mapped.
Should I automate the process exactly as it is now, or fix it first?
Fix it first. Automating a broken process just makes the broken process faster—and harder to change later. Before you automate, map the current process, identify the steps that don't add value, and remove them. Then automate what's left. The best automation projects start with a process audit, not a build. If the vendor doesn't ask you to walk through the current process before they quote you, they're guessing.
How do I measure whether the automation actually worked?
Measure the same thing you measured before the automation went live. If the process took 30 minutes per instance before, time it after. If errors happened five times a month before, count them after. If follow-ups took two days before, measure them after. The baseline you set before the build is the only way to know whether the system delivered. If you didn't set a baseline, you can't measure ROI—and if you can't measure ROI, you have no idea whether the money was worth it.
What if I need to automate more than one process?
Automate them one at a time. Build the first one, test it, let your team use it for a week, and then decide what's next. The second process will be easier to scope because you'll understand how automation actually works in your business. The clients who try to automate five processes at once end up with five half-finished systems and no idea which one to fix first. The clients who automate one process per sprint end up with a stack of working systems that compound on each other.
Ready to Stop Guessing What Automation Costs?
If you can describe one process your team does manually every week, you're ready for a real quote—not a "it depends." Book a discovery call and we'll walk through the process, measure the baseline, and give you a number: https://cal.com/systemizedflow-javier-recio/discovery-call