How to Run a Technical Discovery Call for an AI Project

The first technical call with a customer decides whether your pilot ships or sits in a ticket queue waiting for a database login. A technical discovery call is where you find the data, security, legacy and ownership problems while they are still cheap to fix. By the end of this guide you will have a run of show, a question sheet, a blocker log and a follow-up note you can reuse on every engagement.

1. Invite the right people to your technical discovery call

The call fails quietly when the budget owner shows up and the person who can approve database access does not. Ask for four people:

• Process owner: owns the problem and the number you will be judged on.
• Data or system owner: knows where the data lives and can approve access.
• Security or IT contact: knows the review process for a new AI tool, even if there isn't one yet.
• An end user: does the work by hand today.

Send this two days ahead:

Subject: Thursday's technical discovery call, who to invite

Hi <name>,

To make the 60 minutes useful, could you bring:
1. Whoever owns the process we want to improve
2. Someone who knows where the data lives and how access is granted
3. Someone from security or IT who knows the review process
4. One person who does this work by hand today

Agenda: goal and success measure, data, systems, security, ownership, next steps.
No slides needed. A screen share of the current workflow is ideal.

Watching someone work a real case beats any description of it.

2. Open with the outcome and bring a question sheet

Spend the first two minutes saying what the call must produce: one number that says the pilot worked, a list of things that could block it, and a name next to each blocker. Then run to a clock: 10 minutes on the workflow, 10 on the success measure, 15 on data, 10 on security and legacy, 10 on ownership, 5 to read back.

Fill this sheet in live; it doubles as a set of AI project discovery questions you can copy for every customer:

# discovery-questions.yaml, copy per customer and fill in live
workflow:
  - Walk me through one real case from start to finish. Can you share your screen?
  - How many cases a week, and which ones hurt the most?
success:
  - What would you see on Monday morning that tells you this worked?
  - What is that number today, who measures it, and in which system?
  - What would make you switch it off?
data:
  - Where does the data live (system, version, region)?
  - Who can grant read access, and how long did the last request take?
  - Does it contain personal, regulated or confidential fields?
  - Can we use a masked sample outside production?
  - When did someone last notice the data was wrong?
security:
  - Which review applies to a new AI tool, and who runs it?
  - Which model providers and regions are approved? Can data leave your network?
  - How are service accounts and secrets issued?
  - Will prompts and outputs be logged, and who may read the logs?
legacy:
  - Does the system expose an API, a database, file drops, or only a screen?
  - Who really understands how it works, and are they staying?
  - When is the next change freeze?
ownership:
  - Who owns this in production after we leave?
  - Who is on call, and who approves a release?
  - Who signs off on the pilot result?

The sheet is a prompt, not a script. Follow the answers that surprise you.

3. Write down the success measure in the customer's words

Ask what they would see on Monday morning that tells them it worked, then get today's number, who measures it and from which system. If nobody can give a baseline, that is your first blocker.

This is AI pilot scoping at its smallest: one workflow, one metric, one baseline.

4. Ask the customer data access questions early

Most pilots stall on data, so ask for specifics. "We have the data" is not an answer. You want the system, the access method, who approves it and how long the last access request took, which predicts how long yours will take.

Ask for a schema or synthetic sample before anyone sends real records.

5. Probe security review and legacy systems

Ask which review a new AI tool must pass, whether data may leave their network, and whether the system offers an API, a database, file drops or only a screen. Ask who really understands it. "Only the person who built it, and they're retiring" is a finding. Write it down.

6. Pin down ownership before anyone leaves the call

Ask who owns the system in production, who is on call, who approves a release and who signs off on the pilot result. Any answer like "we'll figure it out" goes into the blocker log.

7. Read back the blockers with an owner and a date

In the last five minutes, read the success measure and every blocker aloud. A correction in the room costs seconds; by email it costs a week. Log each one like this:

blockers:
  - id: B1
    what: Read-only account on the claims database replica
    owner: <customer data owner>
    needed_by: <date>
    status: not requested
    blocks: pilot cannot start without it

One entry per blocker, one owner each. If an entry has no owner, the call is not finished.

8. Send the follow-up note within 24 hours

The note is the real output of the call. Keep it to one screen and ask for corrections by a date, so silence becomes agreement on the record:

Subject: <Customer> AI pilot, what we agreed on <date>

Hi all, thanks for the time. Here is what I wrote down.
Reply by <date> if anything is wrong.

**Goal:** <one sentence>
**Success measure:** <metric>, today <baseline>, target <target>,
measured by <who> from <system>

**Systems and data in scope**
- <system>: <access method>, owner <name>

**Open blockers**
| # | Blocker | Owner | Needed by |
|---|---------|-------|-----------|
| 1 | <e.g. read-only database account> | <name> | <date> |

**Assumptions I'm making** (tell me if any are wrong)
- <assumption>

**Next steps**
- <me>: <action>, <date>
- <customer contact>: <action>, <date>

Next call: <date>

The assumptions list is the part people skip and the part that saves you later.

Gotchas

• "I think so" is an assumption. If the person answering is not the owner, record it under assumptions and verify it.
• Don't promise quality yet. You haven't seen the data. Promise a measurement plan, not a number.
• Keep sensitive data off the screen share. Ask for a masked view before anyone opens a live record.

A discovery call that ends with a measurable goal, a blocker list and named owners gives your AI pilot a path to production before you write any code.