What does a legitimate AI consultant engagement look like?

A legitimate engagement has four phases: discovery (seeing your actual workflows and producing a written assessment before any money changes hands), scoping (a specific document describing exactly what's being built), build (2–6 weeks with progress updates and natural checkpoints), and post-launch support (with error alerting built in and a defined support window of at least 30 days).

What questions should I ask before hiring an AI consultant?

Ask: Can you show me something you've built for a business similar to mine? Who actually builds the automation — you or a contractor? What does the scope document look like before I sign? What happens if it breaks six months from now? What do you need from me for this to work? Good answers are specific and verifiable; vague answers are a red flag.

What are red flags when hiring an AI consultant?

Red flags include: can't describe what they'll build in specific functional terms and uses words like 'leverage' or 'transform' without explaining the mechanism; proposes an enterprise platform for a small business; normalizes scope creep with 'we'll figure out the details as we go'; provides no written deliverables in the discovery phase; or guarantees specific outcomes rather than estimates.

What to expect when you hire an AI consultant: a plain-English guide

Most business owners hiring an AI consultant for the first time don’t know what good looks like. They don’t know what questions to ask, what to expect in the scope document, or how to evaluate whether the result is working. This guide fixes that.

What a legitimate engagement looks like

Phase 1: Discovery (before any money changes hands)

A good consultant asks to see your actual workflows — not a high-level description, but the thing itself. They want to watch someone execute the process, see the tools in use, and understand where the friction is.

Red flag: A consultant who proposes a solution before seeing your workflows in detail is proposing something generic. Generic automation doesn’t solve specific problems.

The discovery phase for a real engagement should produce a written assessment that includes:

Which specific workflows have the highest ROI for automation
What the automation would actually do (not “streamline your intake” — but “read emails from your contact form, extract name/service/urgency, create a record in your CRM, send an acknowledgment, and flag incomplete submissions for manual review”)
Realistic time and cost estimates
What success looks like in measurable terms

You should receive this document regardless of whether you proceed. If a consultant won’t produce a written assessment without a signed contract, that’s a red flag.

Phase 2: Scoping (before work starts)

The scope document should tell you exactly what’s being built, what tools it will use, how it will connect to your existing systems, what the testing process looks like, and what happens after launch. It should be specific enough that you could hand it to a different developer and they could build it.

Vague scope documents are a red flag. “AI-powered intake automation” is not a scope. “A Make.com workflow that monitors your Gmail for new form submissions, parses the email body to extract contact info and service type using Claude, creates a contact in HubSpot, sends a templated acknowledgment email, and posts a Slack notification with a summary” is a scope.

Fixed-price vs. hourly: Fixed-price engagements are better for both parties on clearly-defined builds. Hourly billing is appropriate for exploratory work where scope isn’t determined yet. If a consultant insists on hourly for a clearly-defined build, ask why.

Phase 3: Build (2–6 weeks for most automations)

You should see progress updates, not just a delivery at the end. Most builds have natural checkpoints: the core automation logic working in a test environment, integration with your actual tools, user acceptance testing with your team, and launch.

Your team’s role during this phase: test with real data and give specific feedback. “It doesn’t seem right” is not useful feedback. “When the email includes both a phone number and a web form submission, it creates two records instead of one” is useful feedback.

Phase 4: Launch and post-launch

A good consultant builds error alerting into every automation — you should be notified of failures automatically, not discover them when something slips through. The post-launch support window should be defined in the contract (30 days is standard) and should cover issues arising from real-world use.

Questions to ask before hiring

“Can you show me something you’ve built for a business similar to mine?” Not necessarily the same industry, but similar in size and workflow type. What you’re evaluating: are the examples specific and functional, or vague and generic?

“Who actually builds the automation — you or a contractor?” There’s nothing inherently wrong with contractors, but you should know who you’re dealing with and whether you have direct access to them when something needs fixing.

“What does the scope document look like before I sign?” Ask to see an example scope from a previous engagement (with identifying details removed). A detailed, specific scope document is a strong signal of professionalism. A one-paragraph summary is a red flag.

“What happens if it breaks six months from now?” The answer should include both the post-launch support window details and what ongoing support looks like after that period. If the answer is “you’re on your own after 30 days,” you need to either build in-house capability to maintain it or negotiate a maintenance retainer.

“What do you need from me for this to work?” Good answer: access to your tools, time from one person who knows the workflow well for an hour or two during build, and a testing window before launch. Bad answer: an extensive internal IT project or significant changes to your existing systems before work can begin.

Red flags

Can’t describe what they’ll build in specific, functional terms — they use words like “leverage,” “unlock,” and “transform” without explaining the mechanism
Proposes an enterprise platform (Salesforce, ServiceNow, Microsoft Copilot enterprise tier) for a 10-person business — this is almost always overbuilt and the consultant is earning implementation fees
Scope creep normalized — “we’ll figure out the details as we go” is not acceptable for a fixed-price engagement
No written deliverables in the discovery phase — if they won’t put anything in writing before you sign, they won’t be accountable during the build
Guarantees specific outcomes — “this will save you 20 hours per week” stated as a guarantee rather than an estimate based on your specific workflow is a red flag; outcomes depend on how the automation is adopted and maintained

What good results actually look like

Six months after a successful engagement, the automation should be running without your attention. You should be notified of failures before they become business problems. The time your team was spending on the replaced workflow should be measurably redeployed to higher-value work.

If you’re still thinking about the automation six months later — debugging it, explaining it to new hires, wondering if it’s working — the engagement didn’t succeed.

Good automation is invisible infrastructure. You only notice it when it’s missing.

Book a 30-minute audit to see what a real discovery conversation looks like before you commit to anything.