Thirty minutes can produce a concrete next step — or a polite waste of everyone's time. The difference is preparation, and most of it is cheaper than you'd think: one sentence, one list, a few rough numbers. Here's what to bring, what we'll ask, and how the call should end.
Quick answer
Bring your bottleneck in one sentence, an honest list of your tools and spreadsheets, rough numbers on time spent and errors made, the names of who touches the process, and a budget range. Expect questions about how work actually happens — not the official version. A good discovery call ends one of three ways: a clear no, a directly scoped proposal, or a structured paid discovery. It should never end with a big number invented in 30 minutes.
What this call is — and isn't
It's a mutual fit check and a first mapping of the problem. It is not a demo — there's no generic product to show, because everything we build is specific to one operation. It's not a free consulting hour, and it's not a pressure pitch. If you leave with more clarity and no next step, that's a legitimate outcome. We run these calls against a fixed internal structure — we've published how we run discovery on our side — this guide is about your side of the table.
What to bring
Your bottleneck in one sentence. The Monday-morning test works: which recurring task does your team quietly dread? "We re-type every lead from the portal into the CRM and lose two per week" beats ten minutes of company history. If you can't get it to one sentence yet, that's fine — say so, and we'll get there together. But try first.
The honest stack list. Every tool — and every spreadsheet. Especially the spreadsheets. The embarrassing one that a single person maintains and everyone depends on is usually the real system, and it's usually where the project starts.
Rough numbers. Hours per week on the manual process. How many people touch it. How often something slips through, and what a mistake costs when it does. Estimates are fine; "we honestly don't know" is also useful information — it tells us the process isn't measured, which is itself a finding.
Who touches the process. Not who's buying the system — who will use it. Adoption is decided by the people doing the work, and knowing who they are changes what we'd build.
A budget range. Not for negotiation leverage — for scoping honesty. A €5,000 problem and a €50,000 problem have different right answers, and knowing the range means the call ends with a recommendation that's actually buildable instead of a fantasy.
Bring the problem, not the solution
The most common way a well-prepared call goes sideways: arriving with a prescribed solution instead of a problem. "We need an app with a dashboard and a chatbot" tells us what you've imagined; "we lose two leads a week because nobody follows up within 24 hours" tells us what's actually wrong — and the second one is worth ten times more, because the right fix might not look anything like what you imagined. It might be smaller. It might be a €0 change to an existing tool. It might be bigger than you thought, in a different place than you thought.
You're welcome to bring the imagined solution too — it's useful data about how you see the problem. Just hold it loosely. If we only ever build exactly what's requested, you're paying for hands, not judgment. The call works best when the problem is fixed and the solution is negotiable, not the other way around.
What we'll ask
Expect some version of these six: Walk us through the process as it happened last Tuesday — trigger to done, the real version, not the org-chart version. Where does the data live, and who re-types it where? What breaks most often — what do you double-check by hand because you've been burned? What does "solved" look like in 90 days? What have you already tried, and why didn't it stick? And: who decides, and by when?
None of these require technical knowledge. Process knowledge beats technical knowledge in this call, every time.
What you should ask us
This list works on any provider, not just us. Who exactly will build this — the person on the call, or someone I'll never meet? What happens after go-live — who maintains it, and what does that cost? Who owns the system and the data when we're done? What have you built for businesses like ours? And the revealing one: what would you refuse to build? A provider that never says "no," never says "that part you shouldn't automate," and never says "buy a standard tool for this instead" isn't a partner — it's a sales funnel with a calendar link.
How the call ends: three honest outcomes
One: it's not a fit. Wrong problem, wrong stage, wrong budget-to-ambition ratio. We say so directly, and where we can, we point you toward whoever is the right fit. A clear no in 30 minutes is worth more than a slow no over six weeks.
Two: it's clear and contained. Small scope, well-understood problem, obvious approach — that can go straight into a fixed proposal.
Three: it's real, but complex. Multiple tools, several teams, data in five places. Then the honest next step is structured discovery: our AI Operations Audit — fixed scope, fixed timeline, fully credited against the build if you proceed with us. Here's the uncomfortable truth behind that: any build price quoted after 30 minutes for a complex system is a guess. And you always pay for guesses — either upfront in padding, or later in change requests. A short paid discovery is how the number stops being a guess.
The 60-second prep checklist
Bottleneck in one sentence. Tool list, spreadsheets included. Rough numbers on time and errors. Names of the people who touch the process. Budget range and who decides. That's it — five items, and the 30 minutes will earn their slot in your calendar.
The bottom line
A discovery call rewards preparation asymmetrically: fifteen minutes of prep on your side turns a get-to-know-you chat into a working session that ends with a concrete, honest next step — even when that step is "no." Bring the sentence, the list, and the numbers.
Book the call — 30 minutes, no demo, no pitch deck.