15 Questions an AI Business Interview Should Ask

A useful AI business interview asks how work operates, what goes wrong, and what evidence would justify a change. It should not begin by asking which AI tool the participant wants. Use the fifteen questions below to uncover objectives, steps, volumes, effort, systems, exceptions, handoffs, rules, data, ownership, risks, and success measures. IntakeOS can conduct the guided discovery conversation and structure the answers so analysts can focus on validation and decisions.^[1]

The answer pairs below are invented examples of specificity, not customer statements or a script that every IntakeOS session follows. “Actionable” means the answer supports a next investigation. It does not mean the statement has already been verified. Keep estimates, disagreements, and unknowns visible throughout the interview.

1. What business outcome is being harmed?

Ask who experiences the problem and why it matters. Follow up with: “What happens if nothing changes?” This establishes purpose without assuming automation is the answer. It also distinguishes an inconvenience from a problem with a measurable operational consequence.

Vague: “Reporting is inefficient.” Actionable: “Branch managers cannot see unresolved orders before the daily dispatch meeting, so they decide which customers to call using yesterday's list.” Verify the downstream consequence with the people using the report rather than accepting the author's frustration as the whole business case.

2. What starts the work, and what counts as finished?

Boundaries keep the interview usable. Ask about the event that triggers a case, the output, and the stopping condition. Follow up on cases that reopen. Without a finish, one participant may report data-entry effort while another reports the entire customer-resolution cycle.

Vague: “We handle onboarding.” Actionable: “Work begins when an approved hire reaches our queue and ends when required accounts are confirmed active.” Ask whether contractors, transfers, and privileged accounts follow separate paths before treating the description as one process.

3. Can you walk through a recent ordinary case?

A concrete case reveals actual sequence better than an idealized policy description. Ask what arrives, what the participant checks, and where each output goes. Follow up whenever the explanation skips a decision: “What tells you which route to take?”

Vague: “We review it and send it on.” Actionable: “I check the supplier reference, compare the amount with the purchase order, then route mismatches to the buyer.” Use a synthetic or safely redacted example. A useful process explanation does not require exposing a live customer's record.

4. How many cases occur, and when does demand change?

Ask for volume with a unit and period. Follow up on seasonality, batch work, cancellations, and repeat submissions. A weekly estimate should not be silently treated as a stable annual average, especially when the process has a significant peak.

Vague: “Hundreds.” Actionable: “The approved queue report shows 320 completed requests last month; quarter-end is usually busier, but we need a comparable report.” The next action is clear: retrieve the peak-period aggregate and check whether completion counts exclude rework.

5. How much active effort does a case require?

Separate touch time from elapsed waiting. Ask which steps consume attention and whether estimates cover ordinary or exceptional cases. Follow up with: “Could someone time a representative sample?” Avoid turning a remembered difficult case into the baseline for the whole process.

Vague: “It takes two days.” Actionable: “The coordinator spends about twelve active minutes, then waits for an approver. We have not timed the work.” Mark the effort as reported, identify the approver wait separately, and agree how each will be measured.

6. Which systems, documents, and channels are involved?

Ask where information starts, where it is copied, and which record is authoritative. Follow up on spreadsheets, inboxes, shared drives, and tools outside the documented workflow. System names alone do not explain the dependency; the interview needs the purpose and direction of each transfer.

Vague: “Mostly the ERP.” Actionable: “The request arrives by email, I check supplier status in the ERP, then maintain the missing-information list in a spreadsheet.” Ask the system owner to verify available access later. Do not infer an integration exists because both applications are widely used.

Use IntakeOS to collect these early process explanations consistently instead of manually merging each participant's notes about steps, effort, and systems. Review the structured context with the owner before moving to exceptions and solution choices. The benefit is a common discovery foundation for maps, qualification, and economics, not independent verification of a participant's estimates or technical access.

7. What makes a case an exception?

Ask participants to describe a difficult recent case and the exact condition that changed the path. Follow up on frequency, consequences, and recovery. Exceptions may be legitimate safeguards rather than defects to eliminate.

Vague: “Sometimes it gets complicated.” Actionable: “If the supplier reference is absent, we cannot identify the account and must ask the requester.” Record what staff do when the requester does not reply. The recovery path often matters more to delivery than the first escalation.

8. Where does work change hands?

Identify the sending role, receiving role, required information, and evidence of acceptance. Follow up with: “How do you know the other team received a complete case?” This exposes clarification loops that disappear inside broad statements about collaboration.

Vague: “Sales sorts it out.” Actionable: “Operations emails the account manager, but no shared status shows whether the request is accepted.” Ask both sides what a complete handoff means. A reminder may help, but the root cause could be missing ownership or incompatible definitions.

9. Which decisions follow rules, and which require judgment?

Ask for the rule source and examples at the boundary. Follow up on conflicting guidance and who can authorize an exception. This helps distinguish conventional automation from work that may need interpretation, specialist review, or redesigned policy.

Vague: “Experienced people just know.” Actionable: “Amounts above the delegated limit need a second approval; unusual supplier terms go to Procurement for interpretation.” Capture the policy reference without copying restricted content. Ask the policy owner to confirm the rule and its current version.

10. What information is missing or unreliable?

Ask which fields staff correct, infer, or repeatedly request. Follow up on ownership of the source data and whether a representative sample can be inspected safely. An AI proposal may be addressing the symptom of poor data rather than the cause.

Vague: “The data is bad.” Actionable: “Supplier names differ between email requests and the master record, and requesters rarely include the identifier.” Investigate guidance and master-data fixes alongside interpretation tools. Do not assume a language model can make uncertain identity matching safe.

11. Who owns the process and its decisions?

Name accountable roles, not just contributors. Ask who can approve a change, resolve conflicting requirements, and accept the outcome. Follow up when ownership crosses departments. A process with enthusiastic participants but no accountable owner is not ready for an investment commitment.

Vague: “IT owns it.” Actionable: “Procurement owns the policy, Operations performs the checks, and IT owns purchasing-system access.” The opportunity needs all three perspectives. Record which decision each role can make instead of treating technical ownership as business approval.

12. What could go wrong if the work changed?

Ask about confidentiality, financial loss, customer harm, regulatory obligations, and irreversible actions. Follow up on existing safeguards and escalation routes. The interview captures risks for specialist review; it does not certify that a future solution controls them.

Vague: “Security will review it.” Actionable: “A wrong supplier match could disclose payment information, so uncertain matches must remain with an authorized reviewer.” Record that constraint and involve the security and process owners before proposing unattended handling.

13. Which changes have already been tried?

Ask what happened, what was learned, and whether the surrounding conditions have changed. Follow up on adoption problems and hidden work transferred elsewhere. A previously rejected option may now be feasible, but repeating it without understanding the earlier failure wastes discovery effort.

Vague: “Forms never work here.” Actionable: “The last form omitted the urgent-order path, so teams returned to email.” The useful lesson is about scope and participation, not a universal verdict on forms. Test whether repairing that gap is simpler than introducing AI.

14. What would success look like, and how would we measure it?

Ask for a baseline, target direction, measurement owner, and observation period. Follow up on quality and downstream effects so a faster local step does not create more rework. Avoid setting arbitrary numerical targets before the baseline is understood.

Vague: “Save time.” Actionable: “Reduce repeated clarification while keeping supplier-match accuracy acceptable to Procurement; the queue owner will measure both.” If capacity is released, ask what it will be used for. Estimated hours do not become cash savings without an actual operational or budget change.

15. What must we verify before investing?

End by asking which parts of the story are uncertain and who can check them. Follow up on representative samples, access, costs, dependencies, disagreements, and missing stakeholders. This question prevents a plausible conversation from becoming an unjustifiably confident project proposal.

Vague: “We are ready.” Actionable: “We still need peak-period volume, confirmation of supplier-lookup access, and review of disputed cases.” Assign each gap an owner and next action. A justified pause is a useful discovery outcome, not a failed interview.

Use the questions inside a repeatable workflow

Use IntakeOS to interview participants automatically rather than scheduling an analyst for every first conversation and manually organizing every answer. VARA is the AI Business Analyst within IntakeOS; the wider workflow connects the captured context with qualification, process maps, economics, and reviewable outputs. Reviewers still challenge facts and decide what to do.

Open the IntakeOS demo and compare a discovery record with these fifteen areas. Choose one missing detail to investigate with the process owner. Continue with the step-by-step workflow and the evidence validation checklist before committing delivery effort.