Hiring an AI automation partner: 20 questions

Ask the vendor for case studies in your trade, the names of the systems they will plug into, how they will measure the result, what references say about timelines, and what happens when it breaks. Those five questions do most of the work. The other fifteen cover the build, ownership, and life after go-live, with the answer you should hear.

What should I ask about their track record?

The first five questions are carried over word for word from the chapter we published on evaluating AI vendors. They come first because they are the fastest way to find out whether you are talking to an implementer or a reseller.

Question 1. Ask for specific case studies in your industry (not 'we work with all industries'). The answer you should hear is a named or clearly described business in your trade, what was broken, what was built, and what changed, with a date. A vendor who answers with a list of industries has not done the work in yours.

Question 2. Demand integration details — if they can't name your scheduling platform, they haven't done this before. The answer you should hear is the name of your platform, followed by what data moves in each direction and what the agent writes back. If they say "we integrate with everything," ask which field on which screen the booking lands in.

Question 3. Request ROI measurement methodology — how will they baseline and prove value? The answer you should hear is a metric, a baseline period before anything is built, and the same metric measured after go-live. If the method is "you will see the difference," there is no method.

Question 4. Check deployment timeline claims against references. The answer you should hear is a timeline in writing and references you can call who will tell you whether it held. A vendor with no references who will take the call has no track record you can check.

Question 5. Ask what happens when things go wrong (escalation, SLAs, fallback plans). The answer you should hear is a fallback that leaves you no worse off than before, a named path from the agent to a person, and who gets the call in the middle of the night when the system is down.

What should I ask about how they bill and commit?

The same chapter listed four things to avoid: vendors who won't commit to timelines, who bill hourly instead of fixed-price, who can't explain their approach in plain language, or who promise results without asking about your specific business first. Each of those is a question.

Question 6. Will you commit to a timeline in writing? The answer you should hear is yes, with the phases named and what marks the end of each. Hedging on the timeline before the contract is a preview of hedging after it.

Question 7. Do you bill hourly or fixed price? The answer you should hear is a fixed price for a defined scope, with what is out of scope written down. Hourly billing on an AI build means the risk of the unknown sits with you.

Question 8. Explain your approach in plain language. The answer you should hear is one you could repeat to your dispatcher. If the explanation needs the vendor's vocabulary to work, the work will need the vendor's people forever.

Question 9. Before you promise results, what do you need to know about my business? The answer you should hear is a list of questions back at you: call volume, the systems you run, who handles what today, where the money leaks. A promise made before those questions is a sales number.

What should I ask about the build?

Question 10. Who is on the team, where do they sit, and who do I talk to each week? The answer you should hear is names and roles, where each person works from, and one person who owns the relationship and answers the phone.

Question 11. What do you need from us, and when? The answer you should hear is a short list: system access, your current scripts or procedures, your pricing rules, and a fixed amount of your team's time, given before the build starts.

Question 12. What happens in the first week? The answer you should hear is discovery: they map how the work is done today, write down the rules your people carry in their heads, list the edge cases, and take a baseline of the metric they will be measured on, before anything is built.

Question 13. Who owns the code, the prompts, and the data when we are done? The answer you should hear is a clear statement in writing. If the answer is not "you," know what that means for switching vendors later, and price it in.

Question 14. How will you test it before it talks to a customer? The answer you should hear is a test set built from your real calls or messages, and a shadow period where the system runs beside your team on live traffic while a person keeps the decision.

Question 15. What does the handoff to a person look like? The answer you should hear is a description of the transfer: what the person receives (who called, what they wanted, what the agent already asked), and how long the caller waits.

What should I ask about after go-live?

Question 16. What happens in the first month after go-live? The answer you should hear is who watches it, how often you hear from them, and what is included in the price for that period versus what starts a retainer.

Question 17. How do we know it is working, and who reads the numbers? The answer you should hear is the same metric as the baseline, reported on a schedule you agree, by someone whose name you know.

Question 18. What does it cost to run each month, and who pays the model and phone bills? The answer you should hear is a line-item list. Whether usage is passed through or bundled matters less than whether every line is named before you sign.

Question 19. How do we turn it off, or move it? The answer you should hear is an exit path: your data exported in a usable format, your phone numbers and accounts in your name, and enough documentation that another engineer could take it over.

Question 20. What went wrong on your last deployment? The answer you should hear is a specific story, what they learned, and what they changed. A vendor with nothing to tell you has either never shipped or will not tell you when it goes wrong on yours.

What do I do with the answers?

Write them down next to the questions and compare vendors on the same sheet. The five track-record answers decide whether a vendor stays on the list. The rest decide which one you hire. Bring the sheet to a working session if you want ours filled in.