An AI consultant needs four things from you: access to the tools involved through their own login or delegation (never your password), a few dozen real examples of the work with personal details removed, time from the person who does the job today, and one decision-maker who answers questions quickly. Missing any one stalls the project.
The delays you can prevent all sit on your side: an admin approval nobody knew was needed, sample data sent as photos of paper, the one person who understands the process being on holiday in testing week. A consultant can't fix those from outside, so this checklist is about having them ready before work starts. It applies whoever you hire.
Access: give each tool its own door, not your keys
The rule behind every item here: the consultant should be able to do the work without knowing any password you use, and you should be able to remove them in one step without changing anything else.
- A named login for the consultant in each tool, at the lowest role that does the job. Why: their actions are logged under their name, and removal is one click. How to verify: you can see their name and role in each tool's user list.
- Read-only roles for the discovery stage. Why: looking at settings shouldn't carry the power to change them. How to verify: in Microsoft 365, the Global Reader role can read everything a Global Administrator can but not update anything; in Google Workspace, a super administrator can create a custom admin role with only the privileges needed, and a user with a custom role can never change other administrators' accounts.
- Delegated mailbox access instead of shared passwords. Why: a delegate can read, send and delete mail for you but can't change your password. How to verify: on a work account, check delegation is switched on for your organisation before day one; if it isn't, you won't be able to add the delegate until whoever holds admin rights turns it on.
- Connections you authorise yourself. Why: when an automation needs your Gmail or CRM, you should sign in and approve the connection, not hand over credentials. How to verify: in Make, official partners and Enterprise customers can send a credential request, where you enter your credentials directly in Make and the requester never sees them; you can revoke it later.
- Automation and AI accounts in the business's name, on the business's card. Why: if the consultant owns the account, they own the off switch. How to verify: the account's owner email is a business address you control, and billing shows your card.
- A plan that allows a second user, or a decision to keep building in one place. Why: Zapier's Free and Professional plans allow one user, so adding a consultant means sharing a login or moving to the Team plan (25 users, shared app connections, folder permissions). On Make's lower plans you get one team and can't assign roles within it. How to verify: check the plan before kick-off, not when the consultant asks for access.
- A password manager for anything that can't be delegated. Why: messages and emails keep passwords forever. How to verify: shared items sit in a vault you can revoke; the method is in sharing AI tool logins safely with a password manager.
- An end date for every access grant. Why: forgotten access is an easy leftover to miss at the end of a project. How to verify: a calendar reminder on the day the engagement ends, and a quick look at which apps can access your business accounts.
Access to hold back, even if you're asked
Some requests deserve a polite no, or at least a conversation about alternatives. None of these signals bad faith on its own; they're usually shortcuts. But shortcuts with access tend to outlive the project.
- Your own password or multi-factor codes. There's almost always a delegated or named-user alternative, and some vendors forbid sharing outright: Anthropic's consumer terms prohibit sharing login details or API keys. If a tool genuinely offers none, create a separate business login for the project and delete it at the end.
- Top-level admin rights "to have a look around". Discovery needs reading, not changing. Offer a read-only role first and raise it for a specific task if needed.
- Banking, payroll and payment-processor logins. An AI project rarely needs them. If a workflow must read payment data, export the few fields required instead.
- Whole-drive sharing. Share one project folder, not everything "so I can find what I need".
- Your data in a personal AI account. If the consultant will test prompts on your examples, ask which account they'll use. A business plan, or a consumer account with its model-training switch turned off, is the minimum.
Data: real examples, stripped of what the consultant doesn't need
AI workflows are judged on real, messy inputs. Tidy invented samples make a demo look good and a live system look bad. Aim for enough examples that the awkward ones show up.
- 30 to 50 recent examples of each input. Emails, order notes, enquiry forms, tickets. Why: patterns and exceptions only appear at volume. How to verify: count them, and check they cover a busy week and a quiet one.
- Five to ten cases that went wrong. The complaint, the misread order, the message staff argued about. Why: these become the test cases that decide whether the build is good enough. How to verify: each has a note on what the right outcome was.
- The documents the AI must follow. Price list, policies, templates, tone notes. Why: many bad AI drafts trace back to rules that were never written down. How to verify: each is the current version, dated, with old versions archived.
- Exports in a usable format. CSV or spreadsheet files, not screenshots or PDFs of tables. Why: a consultant can test against 50 rows in minutes; retyping 50 photos takes an afternoon. How to verify: open the file and check the columns make sense to someone outside your business.
- Personal details removed unless the build genuinely needs them. Why: the less you share, the less can leak. How to verify: use the field-by-field check below.
- A confidentiality agreement before real data moves. Why: it sets out what the consultant may do with your data and when they must delete it. Whether you need an NDA before sharing data covers the options.
Here is the field-by-field check a dry cleaner might apply to a ticket export before sending it for a project on collection reminders (illustrative):
| Field | Send? | Why |
|---|---|---|
| Ticket number | Yes | Links records without identifying anyone |
| Customer name | Replace with Customer A, B, C | The consultant needs to see repeat customers, not who they are |
| Mobile number and email | No | Not needed to design the reminder logic |
| Item type and service | Yes | Drives which message is sent |
| Stain and damage notes | Yes | The AI drafting step needs them, and they're where errors happen |
| Promised and collected dates | Yes | The whole reminder schedule depends on them |
| Price paid | Yes | Needed for the uncollected-items rule |
| Card details | No | Never needed |
| Delivery address | No, unless van routes are in scope | Only relevant to delivery planning |
If your records need tidying before any of this is possible, the business data clean-up checklist is the place to start. A consultant can work around messy data, but you pay for the hours it takes.
How the consultant uses the examples you send
It helps to see why a few dozen real examples matter. A common first step is to run them through a draft prompt and compare the output with what your staff would have decided. For the dry cleaner, a classification prompt might read:
Sort each dry-cleaning ticket note into one category:
READY, DELAYED, DAMAGE, QUERY, COMPLAINT.
Rules:
- Any mention of a mark, tear, shrinkage or colour change = DAMAGE.
- If unsure, answer QUERY and give a one-line reason.
Reply as: ticket number | category | reason
Tickets:
[paste 50 anonymised ticket notes]An illustrative slice of the output, with the counter supervisor's verdicts:
| Ticket | AI category | Note on the ticket | Supervisor's verdict |
|---|---|---|---|
| T-1041 | READY | Two shirts, pressed | Correct |
| T-1047 | DELAYED | Awaiting replacement button from supplier | Correct |
| T-1052 | READY | Suit; customer mentioned slight shine on lapel | Wrong: a customer-reported shine is a damage conversation |
| T-1060 | QUERY | Customer asked if we clean leather | Correct |
| T-1063 | COMPLAINT | Coat returned, still smells of smoke | Correct |
The miss on T-1052 is exactly the kind of case a tidy invented sample never contains. The supervisor's correction becomes a new rule ("any customer-reported change in finish counts as damage") and the ticket joins the test set. Repeat that across fifty examples and you can see why real data, and the supervisor's half-hour a week, decide how good the finished workflow is.
Time: who needs to be available, and roughly how much
The person who does the work every day knows the exceptions no document mentions: the customer who always pays in cash, the item type that's always late, the phrase that means "this is a complaint". Their time is easy to squeeze, and it shapes the result more than anything else you contribute. For the dry cleaner's project, an illustrative time budget:
| Person | What they do for the project | Time needed |
|---|---|---|
| Owner (decision-maker) | Kick-off, answers questions, approves rules, signs off | 1-hour kick-off, about 20 minutes a week, 1-hour sign-off |
| Counter supervisor (process owner) | Walks through ticketing and collection chasing; tests drafts on real tickets | 2-hour walkthrough, 30-45 minutes a week of testing |
| Van driver | Explains delivery exceptions and failed collections | 30 minutes, once |
| Bookkeeper | Confirms how uncollected-item charges are recorded | 30 minutes, once |
Over a six-week project that's about 4 hours of the owner's time, about 6 of the supervisor's and an hour from the other two: roughly 11 hours in total. At $19-$40 an hour, that's around $300 of internal time. It's small next to the consultant's fee, and it's the part owners easily forget to budget. Put the sessions in calendars at the start. "When it's quiet" never arrives in a shop that has a counter.
If the process owner isn't keen, time will slip no matter what the calendar says. It's worth a conversation before kick-off about what the project changes for them, and what it doesn't.
In a one-person business the table collapses to a single row. A personal trainer automating client check-in messages is the decision-maker, the process owner and the tester, which makes decisions quick but testing easy to skip. Budget the time anyway, perhaps three or four hours across the project, and block it in the diary like a client session. Otherwise the consultant waits for replies typed at 11pm between bookings.
Decisions and rules only you can supply
A consultant can suggest rules; only you can set them. Write them down before the build starts, because every one left open becomes a question that pauses work. The dry cleaner's rules sheet might read:
| Rule | Decision |
|---|---|
| Messages that can go out without a person checking | Ready-for-collection texts; reminders at 14 and 28 days |
| Messages a person must approve | Anything about damage, lost items, refunds or complaints |
| Discounts or refunds the AI may offer | None, ever |
| Tone | Short, polite, no exclamation marks, signed with the shop name |
| Escalate straight to the owner | Damage claims, and any message mentioning insurance or a solicitor |
| Uncollected items | Final notice at 60 days, wording approved by the owner |
| Monthly running-cost ceiling | $60 before anyone asks the owner |
The last line matters more than it looks. Automation tools often bill per task or per credit, so a ceiling lets the consultant choose a design that fits it, instead of discovering the cost after launch.
Here's what a missing rule looks like in practice. Before the discounts line was written down, an early test draft replied to a customer whose coat was late with "we'd like to offer 10% off your next clean as an apology". It sounded reasonable, but nobody had agreed it, and the same wording would have gone out on every late order. One line in the rules sheet removed the problem for good.
A readiness pack you can send in one email
Once the checklist is done, send it in one go. Consultants can tell from this email alone how smoothly the project will run.
Subject: Kick-off pack for the collection-reminder project
Access (all set up under your own name, ending on [date]):
- Zapier: added you to our Team account as a member
- Gmail: delegated access to counter@[domain] (delegation now on)
- Booking and till system: staff login, "reports" role
Data (in the shared folder, personal details removed):
- tickets_last_60_days.csv (412 rows)
- 8 problem tickets with notes on the right outcome
- Current price list, collection policy, message templates
Time:
- Walkthrough with [supervisor's first name]: Tuesday 2-4pm
- Weekly testing slot: Thursdays 9-9.45am
- Owner check-in: Fridays, 20 minutes
Rules: attached (rules_sheet_v1.pdf). Running-cost ceiling: $60 a month.
Decision-maker: me. I'll reply to questions within one working day.Notice the last line. A promised reply time from the decision-maker removes one of the usual reasons a two-week task takes five.
Where projects stall on the client side
These are the realistic ways it goes wrong, how each shows up, and the fix:
- An app connection blocked by an admin setting. The consultant tries to connect Zapier to your Google account and gets an error, because your Workspace restricts third-party apps. The one person with admin rights is away for nine days. Fix: find out who holds admin rights, and check app-access settings before kick-off.
- Delegation switched off for the organisation. Gmail refuses to add the delegate, and Google's own help page tells the user to ask their admin. Fix: switch it on in advance, or choose a different access method.
- Sample data arrives as photos of paper tickets. The consultant spends a billable afternoon retyping. Fix: export from the till or booking system, or type 30 rows yourself if nothing digital exists, which is also a hint the project may need to start with record-keeping.
- The process owner is pulled onto the counter in testing week. Testing slips a week, then the busy season starts. Fix: schedule testing outside your peak, and name a backup tester.
- Decisions by committee. Three partners each reply with different wording preferences, and the consultant rewrites the templates three times. Fix: one decision-maker, who gathers views and answers once.
When the engagement ends, take the access back
Everything you granted should come back on the last day: remove the consultant's logins, end delegation, revoke credential requests, and change anything shared through the password manager. Before that, make sure you've received everything that should stay with you: exported workflows, prompts, a runbook and the account ownership. The AI consultant handover checklist lists it item by item. If you're still at the stage of deciding whether to hire anyone, preparing for an AI consultation is the earlier step, and much of the same preparation carries over.
Further reads
- Who Should Own AI in a Small Business? Roles and Responsibilities — Pick the internal owner who will answer the consultant's questions.
- What an AI Consultant Can't Do for You, and What You Must Own — The parts of the job that stay with you whoever you hire.
- Staff Offboarding Checklist for AI Tools and Shared Accounts — Remove access cleanly when the engagement ends.
- How to Get Staff Buy-In When You Introduce AI — Get the process owner on side before you book their time.
- What a Typical AI Consulting Engagement Looks Like, Week by Week — When each item on this checklist is needed during a project.
- Who Owns the AI Workflows a Consultant Builds for You? — Why accounts in your name matter once the build is finished.
- What Does an AI Implementation Consultant Actually Do? — The six stages of an AI implementation consultant's work, the evidence each stage should leave behind, and how the role differs from strategy or IT help.
- AI Consultant or DIY: Which Suits a Small Professional Firm? — When a small professional firm can set up AI itself, when outside help earns its fee, and the split approach many firms settle on.
- When Should a Trades Business Bring In an AI Consultant? — The signals that a trades firm needs outside AI help, a ten-minute scoring sheet, what to gather first and what a good engagement leaves behind.
- What to Prepare Before You Set Up AI Marketing — An eight-part preparation checklist, filled in for a farm shop, with a fact-sheet prompt and a one-page brief you can copy.
- Should You Hire an Automation Consultant or Build It Yourself? — A five-question test, what DIY really costs in hours, one build that worked and one that didn't, and the hybrid route most small firms should take.
- What Happens in a 1:1 AI Implementation Consultation? — What to send beforehand, how a consultant maps your work and scores AI jobs, the tool check, and the one-page plan you should leave with.
- How to Run a Paid Discovery Phase Before a Full AI Project — A stage-by-stage plan for a paid AI discovery phase, with a filled-in brief, a feasibility test on real emails and a go or no-go decision rule.
- How to Hire a HubSpot or CRM Consultant to Set Up AI Features — A garage's brief, three quotes and a go-live test script: how to find, question and pay a HubSpot or CRM consultant to switch on AI features properly.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: Zapier pricing page (users and shared connections per plan); Make's help pages on team roles and credential requests; Google Workspace Admin Help on custom admin roles; Gmail Help on delegation; Microsoft Entra built-in roles reference (Global Reader); Anthropic's consumer terms.