Bring the workflow. We can work out the technology.

Bring one job your team actually does

“We want to use AI” opens a conversation. “Our coordinator copies an email request into three systems, then chases the missing information” gives that conversation a useful starting point. Describe the trigger, the person doing the work, the steps, and what counts as finished. Include what happens when the usual path breaks.

You do not need a finished process map. A short walkthrough is enough to reveal where information arrives, where it changes, and where someone makes a judgment. Pick one workflow for the first discussion. Keep other ideas on a separate list so the meeting does not become a tour of every tool in the company.

Prepare three examples, including one that goes wrong

Bring a typical input and its accepted output, an incomplete or ambiguous request, and a case that required an exception. For each, explain what a capable employee would do and why. These examples help separate extracting information from applying a business rule or making a decision.

For a hypothetical quote-intake project, the normal case might contain clear quantities and dimensions. The difficult case might omit the units or contradict an attachment. The exception might require an approved discount. That makes it possible to discuss a draft-and-review workflow without assuming the system should set prices or send quotes on its own.

Use synthetic or appropriately sanitized examples in an introductory discussion. Replace identifiers consistently so relationships still make sense, and remove secrets and information that is not needed to explain the task. Do not assume covering a name in a screenshot removes it from the underlying file. Agree a suitable access and sharing process before supplying real records or production credentials.

Know which facts you have and which you are estimating

Invite the people who know the exceptions

The person sponsoring the project and the person doing the work often know different parts of the problem. Include the operator’s perspective, even if it comes through a short recorded walkthrough or notes. Identify who owns the source data and who can answer technical access questions. Not everyone needs to attend the first call, but their questions should have an owner.

State the constraints early: tools that must stay, information that cannot be shared, customer permissions, required reviews, and the staff time available for testing. Note accessibility or usability needs that affect how the team will work with the output. An integration that technically runs can still be a poor fit for daily operations.

Use the call to choose what needs investigation

An introductory call can establish fit, clarify the workflow, and identify the next evidence needed. It should not be treated as proof that an integration works or that a production estimate is final. A separate discovery scope may be needed to inspect data, validate access, test assumptions, and define a pilot.

The GOV.UK Service Manual frames discovery around understanding a problem, its users, and its constraints before committing to a build. That principle is useful here. Its public-service delivery process is a reference, not a claim about DBAI’s engagement length or a required timeline for your project.

DBAI’s published services describe mapping the workflow, the systems it touches, and where judgment lives. Bring enough context to make that mapping productive. You can discuss whether the next step is configuration of an existing tool, a small integration test, data cleanup, or a custom pilot. A useful next step can also be to defer the build until an unresolved dependency is understood.

Copy this one-page discovery brief

# AI project discovery — one workflow
Business task and why it matters:
Person doing the work / business owner:
Trigger and definition of done:
Current steps and handoffs:
Most costly delay, correction, or exception:

## Examples
Normal input and accepted output:
Incomplete or conflicting input:
Exception and how staff resolve it:
Sanitization performed / sharing restrictions:

## Evidence and systems
Volume and time spent, with measurement period:
Which figures are estimates:
Tools, records, and source-data owners:
Known integrations / access questions:
Manual rules and approvals:

## Boundaries
Draft-only versus permitted committed actions:
Actions explicitly excluded:
Data, account, and customer-access restrictions:
Tools that must remain:
Reviewer availability and usability needs:
Budget decision process and timing constraints:

## Decision after the call
Main assumption to investigate:
Evidence needed and who will provide it:
Proposed next step and deliverable:
What would make us pause or stop:
Owner and date for follow-up:

Leave with a decision record

Write down the workflow discussed, the assumptions still open, and who will provide each missing input. If discovery is proposed, define its deliverable and decision point: for example, whether a supported connection can read the required fields, or whether the sample cases can produce acceptable drafts.

Keep an exploratory demo distinct from an accepted production system. Before a build, agree the scope, tests, permissions, and operating responsibility in the appropriate next step. Your first conversation has done its job when everyone knows what is being evaluated and what evidence will decide it.