Companies do not usually regret hiring a consultant because the person lacked intelligence. They regret it because the engagement started with enthusiasm and almost no usable brief.
The kickoff deck looks sharp. Discovery interviews fill calendars. Recommendations arrive. Then implementation stalls — not because the ideas were wrong, but because nobody agreed up front on the problem, the owner, the data boundaries, or what “done” meant in business terms.
AI work makes this failure mode louder. The category is noisy, vendors overpromise, and internal sponsors feel pressure to “get something going.” A vague brief invites a vague project. A clear brief is how you buy outcomes instead of activity.
I have spent more than two decades helping organizations modernize systems and decide where AI and automation actually help. The engagements that ship share a pattern: the client briefed like an operator, not like a spectator of technology trends.
Here is how to brief an AI consultant so the work has a real chance of landing.
What a weak brief sounds like
If your starting document (or Slack message) resembles any of these, pause:
- “We want to explore AI opportunities across the business.”
- “Help us become more innovative / efficient / competitive with AI.
- “Look at our stack and tell us what we should buy.”
- “Build us a pilot” — with no problem statement, owner, or success metric.
Those prompts produce tours, not transformations. A good consultant can still be helpful inside them, but you will pay for orientation that a tighter brief would have skipped.
What a strong brief contains
You do not need a 40-page RFP. You need a short packet that a practitioner can act on. Aim for clarity over completeness.
1. The problem in one sentence
Write the operational pain, not the solution category.
Weak: “We need AI for customer support.”
Strong: “Our support team spends roughly four hours a day triaging repetitive ticket types that follow known patterns, which delays responses on complex cases.”
If leadership and the frontline team cannot both accept that sentence, discovery will become mediation. Better to surface disagreement before the contract clock starts.
2. Why now — with a business reason
Budget cycles, a hiring freeze, rising error rates, a system migration, customer complaints, or a capacity cliff are real triggers. “Board asked about AI” is a political trigger. Name it honestly either way. Consultants can work with politics; they cannot invent urgency you will not sustain after the first demo.
3. Current workflow, systems, and owners
List:
- The systems involved (CRM, help desk, ERP, shared drives, spreadsheets)
- Who touches the work today
- Where the process breaks
- Who believes they own the outcome (title is not enough — calendar time is)
A rough diagram beats a polished fantasy map. Consultants price risk. Ambiguous ownership is risk.
4. Data reality not data aspiration
Say what is true:
- Where the data lives
- How clean or conflicting it is
- What cannot leave the environment
- What a wrong output would cost (time, money, trust, compliance)
If the data is a mess, a good brief says so. That may shift the engagement toward hygiene, integration, or process design before model work — which is often the highest-ROI path.
5. Constraints that actually bind
Budget range, timeline, security review requirements, tools you will not rip out, vendors already under contract, and internal capacity for change. Fake “no constraints” language wastes everyone’s time. Real constraints sharpen design.
6. Definition of success — and definition of stop
Pick a small set of measurable outcomes before kickoff: hours returned, cycle time, error rate, cost per ticket, time-to-first-response, or a specific manual step retired.
Also define failure: what results, by what date, mean you pause or end the engagement. AI initiatives without a kill switch become permanent cost centers.
7. Decision rights
Who can approve scope changes? Who signs off on data access? Who accepts the pilot criteria? Who owns the system after the consultant leaves?
If those answers are “we’ll figure it out,” you have not finished the brief.
A one-page briefing template you can copy
Use this as a paste-ready outline:
Engagement title:
Problem (one sentence):
Who feels the pain (role/team):
Why now:
Systems in scope / out of scope:
Data sources and sensitivity notes:
Named internal owner (with time allocated):
Success metrics (2–3) and review date:
Stop criteria:
Constraints (budget band, timeline, security, tools we keep):
Decision rights (scope, access, go/no-go):
What we already tried:
What “value shipped” means in 60–90 days:
Fill it imperfectly. Imperfect and shared beats perfect and imaginary.
How to run the first meeting
Bring the one-pager. Walk through it out loud. Then ask the consultant to restate the problem and the proposed first deliverable in their own words.
Listen for whether they push a smaller first slice (vs. a wide “AI transformation”), ask about ownership and measurement early, will recommend not using AI when automation fits better, and address human review, access control, and exit paths. Strong practitioners narrow scope. Weak ones expand it to match a narrative.
Scope the engagement in slices that can ship
Prefer: (1) confirm problem, map workflow, assess data and ownership; (2) ship the smallest intervention — process fix, automation, or tightly scoped AI with review; (3) measure and decide keep / expand / stop; (4) only then broaden. Ask for deliverables operations can use — a documented workflow, a working pilot with owners, a measurement plan — not only a recommendation memo. Strategy arcs without intermediate ship points are how slide decks outlive outcomes.
What you owe the consultant (and yourself)
Even the best brief fails without client participation. Allocate a single point of contact with authority, access to the people who do the work (not only sponsors), time for data and security questions, and willingness to retire a manual step if the pilot works. If internal capacity is zero, fix that before you buy outside help — or brief the engagement as prioritization, not as a tool install.
Responsible use belongs in the brief
Put privacy, access, transparency, and human oversight in the starting packet. Ask how wrong outputs will be caught, who is accountable, and what data the approach must never see. You are also hiring for transfer of capability: if nothing can run without the consultant forever, you bought dependency, not leverage.
The payoff of briefing like an operator
A clear brief shortens discovery, improves pricing accuracy, reduces political thrash, and makes it obvious whether AI, automation, or process work is the right first move. It also makes success legible: you can point to a metric and an owner, not a vibe that “we’re doing AI now.”
Technology consultants are multipliers. They multiply whatever you hand them — clarity or confusion. Hand them clarity.
If you want the engagement to ship value, do not start with “show us what AI can do.” Start with “here is the pain, the owner, the data reality, the constraints, and how we will know it worked.” That is not bureaucracy. That is how professional work gets done.
About the author: Tzvi Boxer is a technology consultant and AI strategist based in Columbia. He helps organizations modernize systems, streamline operations, and decide where AI and automation actually add value — and where they don’t. Remotely, he collaborates with Optimal Targeting on practical AI and high-authority content strategy. Author of The Practical AI Playbook. More at https://www.tzviboxer.com/.
Top comments (0)