What we actually talk about in a discovery call — and what you should prepare

Photo by Brett Sayles

I've run a lot of discovery calls. Enough to see the patterns clearly. The ones that result in a solid proposal within a week look different from the ones that stall — and not because of the size of the company or the complexity of the process. It's usually about preparation and specificity.

This is a guide to what actually happens in these calls and what you can do to make yours useful.

What a discovery call is (and isn't)

A discovery call is not a sales pitch. I'm not going to spend 45 minutes telling you how good SynthetixBiz is. I'm going to spend 45 minutes trying to understand your business well enough to tell you whether an AI agent is the right solution for your problem — and if so, what building it would actually involve.

Sometimes the answer is: yes, this is a strong candidate for automation, here's roughly what it would look like and cost. Sometimes it's: this process isn't ready for automation yet, here's what needs to happen first. Occasionally it's: the effort wouldn't be worth the return at your current scale, here's why.

All of those outcomes are fine. The call is for getting clarity, not for closing a deal.

The first 10 minutes: context

I start by asking about the company. Not for a full company overview — just the things that bear on automation decisions. How many people? What industry? What does the team structure look like for the process we're discussing? What tools are you running on?

The tool question matters more than people expect. I need to know what systems exist and whether they're connectable. A company running on Google Workspace and HubSpot has a very different technical starting point than one running a 15-year-old on-premise ERP.

The core of the call: walking through the process

This is where I spend the most time, and it's also where the most value is generated. I ask you to walk me through the process step by step. Not at a high level — at the level of: what happens first? What data does that generate? Who sees it? What decision gets made? What happens next?

The questions I ask here might feel granular. They are. I want to know:

• What triggers the process? (Email arrives? Form submitted? Calendar event? Manual decision?)
• What does the input look like, and does it vary?
• What decisions get made, and are they rule-based or do they require judgement?
• Where do exceptions happen, and what does "exception" mean in this context?
• Where does the process end? What's the final output or action?
• What happens when something goes wrong?

The answers to these questions tell me most of what I need to know about whether and how to build an agent.

What makes calls go poorly

The most common problem: the person on the call doesn't actually work in the process they're asking about. They have a general sense of it but haven't done it themselves recently, or it's handled by someone who isn't on the call. This isn't a failure — it happens — but it usually means we need a follow-up session with the right person before we can write a proper scope.

The second most common problem: the process hasn't actually been mapped. It exists, people do it, but there's no agreed description of how it's supposed to work. In those cases, the first step isn't building an agent — it's documenting the process. Again, not a dealbreaker, just a prerequisite.

What you should prepare before the call

You don't need to prepare a lot. These three things are enough:

1. Know which process you want to discuss. One process, with a clear scope. Not "we want to automate our whole operations" — "we want to automate how we process incoming supplier invoices."
2. Be able to walk through it step by step. If you've never done the process yourself, bring someone who has, or talk to them before the call.
3. Know your tools. The main software systems involved in the process. Ideally, whether those systems have APIs — but I can help investigate that during the call if you don't know.

After the call

If the process looks like a good automation candidate, I write a technical scope document. This typically takes 3–5 business days. It includes: what the agent does, what it connects to, how it handles edge cases, what the delivery timeline looks like, and a fixed price.

You review it, ask questions, and decide whether to move forward. There's no pressure on the timing — I've had clients come back to a proposal months after receiving it, and that's fine. The work doesn't start until you say go.