1. Start with the problem, not a product name
You do not need to arrive knowing which model, agent, or automation platform to use. Start with the work that feels repetitive or unreliable. Explain who does it, what starts it, and what a useful result would look like. We spend time sorting incoming requests is a starting point; we need each request organized for a person to review is a clearer outcome.
Choose one process for the first conversation. Note its usual frequency, the people involved, and the point where work waits or gets repeated. Use what you know, and mark estimates as estimates. Discovery is the place to clarify the problem and determine a workable scope, not to pretend all the answers are already available.
2. Prepare examples of ordinary and difficult cases
Bring a typical input and the output you would want from it. For a document process, that might be a sample form and the fields you currently enter into a spreadsheet. For support, it might be a common question and an approved answer. Include an incomplete or confusing example too; it helps identify where a person must step in.
Use material you are permitted to share and remove unnecessary personal or confidential details. Clearly label invented samples so they are not mistaken for business records. Avoid sending entire customer databases when a small example explains the task. Do not put passwords, API keys, or account recovery information in the inquiry form. Access arrangements come later through an agreed process.
3. Map the tools and who controls them
List the inbox, calendar, phone provider, CRM, spreadsheets, or document storage involved. Note which system contains the original record and where the new output should go. Tell our team whether the accounts belong to your business, who administers them, and who can approve a connection. A workflow cannot be scoped accurately from a tool name alone.
For example, a scheduling idea depends on more than reading availability. The discussion should cover appointment duration, time zones, cancellation rules, confirmation, and what happens when a calendar write fails. Existing provider features, permitted access, and paid usage all affect feasibility. Bring those questions to discovery; do not purchase new subscriptions or grant broad access just to prepare for the conversation.
4. Bring a short sample process brief
An illustrative office workflow could start with a submitted document and end with a draft spreadsheet row. The agreed fields might be document reference, sender, date, and requested service. A person checks the extracted fields against the source before using them. Unreadable documents and missing fields go to a review queue; the workflow does not invent the missing values.
Describe the same six points for your process: trigger, input, transformation, destination, reviewer, and exception path. Add what should never happen. For the office example, that could mean no deletion of original files, no final approval of a payment, and no sharing outside approved recipients. This brief gives the conversation a concrete starting point without turning it into a technical specification.
5. Define permission and approval separately
Be explicit about whether the workflow should draft, recommend, or act. Drafting a response for review is different from sending it. Collecting an appointment preference is different from confirming a booking. Preparing a report is different from approving a business decision. Naming those differences helps keep the first project useful and its responsibilities clear.
If customer messages are involved, explain the existing permission rules, how opt-outs are handled, and who approves templates and timing. A phone number or email address by itself does not answer whether a particular message is permitted. Also identify the person who handles exceptions and the fallback when a provider is unavailable. These are practical operating requirements to agree, not details to leave until launch.
6. Know what to settle in the written scope
Use discovery to ask what is feasible and what needs further investigation. Before work starts, the written scope should make the deliverables, integrations, allowed actions, price, and acceptance tests understandable. Ask which access you supply, which provider costs are separate, what support is included, and how changes to the agreed work are handled.
Custom AI work has no fixed published price, and buying a website is not a prerequisite. The right first project may be a draft-only workflow with a review queue rather than a fully automatic customer interaction. Agree how the handoff will be demonstrated and what evidence will show that it works. Ongoing monitoring, updates, and support should be discussed explicitly rather than assumed.
Before you send your inquiry
A concise inquiry can say: We receive documents, manually copy four fields, and want a draft for review. Our files are in an existing storage account, and our office manager owns the process. We need help defining the scope. Then use this checklist to identify anything worth discussing next.
- One process, its owner, and the current pain point.
- A permitted or clearly labeled sample input and desired output.
- Current tools, account ownership, and access questions.
- Drafting versus acting, with named human approvals.
- Difficult cases, message permissions, and the failure fallback.
- Questions about deliverables, acceptance, price, provider usage, and support.