Blog
What to send before a discovery call, and what you can skip
· 4 min read · Websyi
A short, useful brief before a discovery call helps everyone focus on the real workflow rather than spending the meeting finding basic context.
A discovery call should not begin with ten minutes of trying to work out what the business does, who the customer is, or why the team booked the call. That is not a useful conversation for either side.
You do not need a polished requirements document before speaking with an AI or automation partner. In fact, waiting until you can write one often delays a project that could have started with a simple conversation. But a small amount of context changes the quality of that conversation immediately.
The useful goal is not to explain everything. It is to make the first call specific enough that you can spend the time on the work that matters: the repetitive task, the bottleneck, the people involved, and the result you need.
Start with the problem, in plain language
A good first note can be one or two sentences. Describe what keeps happening and why it is frustrating.
For example: enquiries arrive through the website and WhatsApp, but someone has to copy each one into a spreadsheet before anybody follows up. Or: the team answers the same booking questions every day, while more complex requests wait too long for a reply.
Do not try to name the solution yet. Saying "we need a chatbot" can be useful, but it can also hide the real issue. Perhaps the bottleneck is not the conversation. It may be the missing handoff after the conversation, the lack of a clear booking process, or the manual checking of information in three places.
The problem is more valuable than the tool name because it gives the call a place to start.
Send the current journey, not an ideal version
The best context shows what happens now. It does not need to be beautiful. A short list, a voice note turned into text, screenshots of a form, or a rough diagram are all enough.
Include the point where the work begins, the steps in the middle, and what counts as finished. For a lead workflow, that may be an enquiry, a qualification question, an internal notification, a follow-up, and a booked meeting. For a reporting workflow, it may be data arriving from several places, someone checking it, a summary being prepared, and a report being sent.
This matters because automation follows the real process, including its exceptions. An idealised description can make a system sound easier than it is. The detail that someone checks a message before it goes out, or that a particular type of enquiry must go to a named person, is exactly the detail worth knowing early.
Five things that help before the call
You can keep the preparation short. These five points are enough for most first conversations:
- The problem you want to remove or reduce.
- The people who do the work today and the people affected by it.
- The tools already involved, such as email, forms, WhatsApp, a CRM, spreadsheets, calendars, or documents.
- A few examples of the input and the desired outcome, with private information removed where needed.
- Any action that must stay with a person, such as approving a message, price, booking, or customer record.
If you have a website, form, process document, FAQ, or message template that relates to the problem, send the link or attach it. Existing material is usually more useful than a long new explanation because it shows how the business already communicates and operates.
What you can leave out
You do not need to decide the exact technology, create a full list of requirements, or choose between every possible tool before the call. Those are design decisions, and they become clearer once the workflow is mapped.
You also do not need to share information that the project does not need. Remove customer details, passwords, access codes, financial information, and other sensitive data from examples. A representative sample is usually enough for a first discussion.
A budget range can be helpful if you have one, because it lets the conversation focus on a realistic first phase. If you do not, say so. The first call can still identify a useful starting point and the likely scope of the work.
Use the call to choose the first win
The strongest discovery calls end with a clear next step, not a vague promise to "explore AI". Often that next step is choosing one workflow to improve first, defining what it should do, and deciding where a human needs to approve the output.
That is a better foundation than trying to automate every part of the business at once. A focused first system gives the team something practical to use, and it reveals what should be improved or connected next.
If you want to discuss a workflow, send the project context: the problem, the current steps, and any examples you can share safely. Websyi will use that to make the discovery call useful from the first minute.
