Choose an AI implementation partner by asking how they would understand, build, test and hand over a specific piece of your work. Compare relevant evidence, the boundaries of their proposed scope and the responsibilities your people will retain. A convincing demonstration is useful, but you also need to know what happens when information is missing, an integration fails or the system needs changing.
The right conversation begins with what your business wants to become and what your team already does well. It should lead to a proportionate next step, with enough detail to assess the commitment before making it.
This guide sets out Build n Bloom's suggested interview method. We provide implementation services ourselves, so use the questions to assess us as well as other providers.
Bring one piece of work into the conversation
Describe a recent engagement or recurring job without supplying confidential files at the outset. Explain who uses the output, who checks it and what you want to improve. You can be unsure about the technology while still being clear about the ambition.
A useful partner should ask what happens around the visible task: where inputs come from, what decisions people make, what returns for correction and where accepted work goes next. They should also ask what you want to preserve.
Notice whether the provider can explain a plausible role for your people. A system may prepare evidence or draft work, while an experienced person continues to interpret the situation and make the customer commitment. Those responsibilities should become explicit in the proposed design.
If choosing the starting point is difficult, use the first-workflow worksheet to prepare a short brief.
Ask them to compare simpler options
Ask: “What would you try before building something custom?” A useful answer might include a clearer method, an existing software feature, a small integration or better use of a tool the team already has.
The provider should be able to explain which requirement justifies additional complexity. That discussion is consistent with Anthropic's guidance to start with the simplest adequate solution, but the decision still needs evidence from your work.
For example, if the proposed system assembles a client brief, ask why a template and an organised source folder would be insufficient. The answer may justify a build. It may also reveal that the business first needs a more consistent source or review method.
Make evidence specific to the claim
Ask what each example actually demonstrates. A fictional demonstration can show a possible workflow. A component test can establish that a particular behaviour worked under stated conditions. A client outcome requires evidence about that engagement and permission to share it.
You do not need a provider to disclose another client's protected material. They can describe the scope, use permitted or fictional examples, explain the testing method and be clear about what remains unproven. Ask how relevant their experience is to the part of your work they propose to handle.
If a provider presents a credential, membership or certification, ask what it means and how its current status can be verified with the issuer. A logo alone does not establish competence on your workflow. Equally, an absent logo is not evidence that an affiliation does not exist.
Use a buyer interview sheet
Give shortlisted providers the same bounded brief. Capture the answer and the evidence still needed. This makes differences in assumptions easier to see.
If columns don't fit, scroll sideways. Keyboard: focus the table and use the arrow keys.
| Ask the provider | A useful answer should make clear | Evidence to request |
|---|---|---|
| What part of this job would you improve first? | A specific task, intended benefit and important unknowns | Proposed work boundary and investigation questions |
| What simpler option would you compare? | Why current software or a process change may or may not fit | A reasoned route comparison |
| What will the system read and do? | Permitted sources, tools and actions | Source/access outline and approval points |
| What will our people still decide? | Named review responsibilities and exceptions | A normal case and a difficult case |
| How will we know it works? | Written acceptance criteria for the complete agreed job | Representative tests and who accepts them |
| What if something fails? | Stop, correction, recovery and communication responsibilities | Failure walkthrough and service terms |
| What must our team contribute? | Access, examples, decisions, review and practice | Dependency list with owners |
| How do we run it after handover? | Operating instructions, training and change ownership | Handover outline and support options |
| What exactly are we buying? | Deliverables, exclusions, fees and dates | A written quote with explicit assumptions |
An unanswered question is a reason to clarify the proposal, not automatically a reason to reject the provider. The important distinction is whether the uncertainty is visible and has a sensible way to resolve it.
Ask to see an exception handled
A useful demonstration includes more than a well-prepared happy path. Ask what the system would do if a required field were absent, two sources disagreed, a connection were unavailable or a request exceeded its allowed actions.
For an illustrative quote-preparation task, the system might identify an absent measurement and return a question to the estimator. It should not silently fill the gap and make the draft appear complete. Ask where the operator sees the unresolved issue and how the work resumes.
The demonstration can use fictional material. Its purpose is to make the proposed behaviour inspectable. Your eventual acceptance still requires agreed representative cases and the right reviewer for your scope.
Inspect the operating responsibilities
Ask who will keep instructions and sources current, grant or remove access, review vendor changes, monitor failures and maintain connections. Identify which responsibilities sit with your team, the implementation provider and the underlying software vendors.
“Secure” or “compliant” is too broad an answer to these practical questions. Ask which data will be processed, by which services, with which access and retention arrangements, and what needs checking for your circumstances. The NIST AI Risk Management Framework is a voluntary reference for considering trustworthiness across AI design, use and evaluation; referencing it does not itself certify a provider or installation.
Keep the conversation proportionate to the job. A contained internal task and a system taking consequential external actions do not have identical requirements.
Compare quotes on the complete commitment
Two quotes can differ because they describe different outcomes. One may cover a workshop and configuration; another may include integrations, tests, operator training and an ongoing service. Ask each provider to distinguish those elements.
Check the agreed capability, deliverables, exclusions, delivery date, dependencies, acceptance, professional fees, third-party costs and support arrangements. Resolve what happens to access, records and unfinished work at the end of the engagement. Ownership and use rights should be stated in the actual agreement, not inferred from a sales phrase.
The AI implementation cost guide provides a fuller comparison worksheet. A lower initial figure may fit a smaller scope well; it cannot be compared fairly with a larger commitment until the differences are visible.
A fictional comparison: the same request, different next steps
This example is invented. It is not a review of named providers or evidence of a client outcome. An advisory firm wants help preparing a recurring client briefing.
One proposal recommends a configured workspace and practical training using an approved source set. Another proposes a connected workflow that gathers permitted updates, prepares a draft and tracks reviewer questions.
The firm asks both providers to walk through a changed source and a missing input. It then asks whether the source-gathering effort is actually material and whether its current tools already handle it. If the main need is a consistent preparation method, the smaller proposal may fit. If a tested integration addresses an important unmet requirement, the larger scope may be worth commissioning.
The decision follows the work and evidence. It does not require treating every provider's preferred delivery model as the same service.
Decide what must be known before you commit
End the interview with a written list of the scope you understand, the remaining unknowns and the next step proposed. A finite check, a design engagement or a direct build can each be appropriate when its purpose and limits are clear.
Build n Bloom's AI Transformation service starts with a free 25-minute Fit Call and a short reviewed provisional Fit Note, with delivery timing agreed during the call. A directly scoped Build or Connected Build is available when the scope is clear. An optional Blueprint designs three connected opportunities across one important revenue path; installation is separately scoped.
Written acceptance and 30 calendar days of in-scope stabilisation are part of our installation approach. Continuing support is optional. Our published service guarantee defines the applicable terms; it does not promise revenue or other business outcomes. Use the measurement guide to plan how you will evaluate value after the agreed system works.