Pricing for AI setup work has no industry-wide standard, and that gap is exploited by people who have never built a working system. The category covers more ground than most proposals make clear: workflow automations, AI assistants trained on your business content, agents that can take actions on your behalf, and custom tools built around a specific process you run every day. The most useful way to think about what you should pay is to start with what you will own when the work is done. A working system that runs without your constant attention is a different product from a tool subscription someone configured while sitting in your office. The price should match the product, and the only way to know which one you are getting is to ask for specifics before any agreement is signed.
What am I actually buying?
AI setup work covers more ground than most proposals make clear. At one end, someone shows your team how to use a general AI tool, answers questions during a few sessions, and leaves. At the other end, someone maps a specific process in your business, builds a custom system connected to your tools and data, trains whoever runs it day to day, and hands over a written guide for when it breaks. In between are AI assistants configured to answer questions about your business, agents that can take actions in other systems on your behalf, and automated workflows that run the same process without anyone pressing a button. All of these can appear under the label AI implementation. Before you decide who to hire, train, or bring in, you need to know which of these the proposal in front of you is actually offering.
How do I tell someone who actually knows what they're doing from someone who just learned to prompt?
The clearest signal is what they ask you first. Someone who builds real systems asks what specific task takes the most time each week and what the output of that task looks like. Someone who learned to prompt asks what AI tools you have and what you want to achieve with AI. The second question sounds more strategic, but it is the wrong place to start for a small business with a concrete problem.
- A first meeting should produce a list of specific tasks you currently do manually. If it produces an AI strategy or a high-level roadmap, what is on the table is advice, not a built system.
- A real system builder can show something they built for a previous engagement: a workflow diagram, a screenshot of a running agent or automation, a handover document. Someone who only runs prompts cannot, because there is nothing to show.
- A built system lives in a platform your team can log into, inspect, and restart. A process that runs only when someone opens a chat window and starts a conversation is not a system your team can hand off or restart independently.
What questions protect me before I agree to anything?
- What exactly will I have when the engagement ends: a tool configured, a workflow built, an agent set up, or a team trained?
- Who will run and maintain this after you leave, and is there a written guide for that person?
- Can you show me something similar you built for another business?
- What does a failed project look like on your end, and what happens if that is what we get?
- Are all accounts and tools registered to my business, or do I need you to access them to keep things running?
What should the first project actually deliver?
A first project built well has a before measurement and an after measurement for the same task. Without both, you cannot evaluate whether the work paid off. The scope should name one manual task, describe what the automated or AI-assisted version produces, set an end date for the build phase, and include a period where your team runs it supervised before taking over independently. The same logic that applies to testing AI before committing serious money applies here: a defined scope with a measurable result tells you whether to continue, long before you have committed to a larger engagement.
Say your team copies three pieces of customer information from incoming emails into a booking platform every morning. That is a specific enough task for a first project: one input (the email), one output (the filled record), a clear pass/fail test anyone can run. After a build phase and a supervised handover period, you can time the task before and after and know whether the work was worth continuing.
Tool access versus a built system
Most proposals blur these two. Knowing the distinction lets you evaluate what you are reading.
| What you get | Someone who knows a tool shows your team how to use it and answers questions during a few sessions. | A working system built around your specific process, connected to your tools and data, with a written guide for when it breaks. |
| What you own afterward | A configured subscription your team may or may not keep using. | A running agent, workflow, or AI assistant your team can manage and restart independently. |
| When it fits | Your team needs to learn a specific tool and you need someone to accelerate that learning. | You have a repetitive task that runs the same way every time and currently requires manual effort. |
Frequently asked questions
Is there a difference between AI consulting and AI implementation?
Yes, and the difference matters when evaluating a proposal. Consulting is analysis and advice: what AI could do for your business, a roadmap, recommendations for where to start. Implementation is building: a working system connected to your actual tools and data, whether that is an automated workflow, an AI assistant trained on your content, an agent that can take actions on your behalf, or a custom tool built for a specific task. Most small businesses need implementation but are often sold consulting first. Ask which one the proposal covers before agreeing to it.
Can I hire someone just for the first project and decide about ongoing work later?
Yes, and this is usually the right structure. A well-scoped first project has a defined end date, after which you own and run what was built. Ongoing work should be a separate conversation based on whether the first project worked and what else you want to build. Any proposal that bundles an ongoing retainer into the initial scope before the first project is complete deserves a clear question about what you are actually committing to.
How do I evaluate whether what they built is actually good?
Run the system on a day you would normally have done the task manually, then check two things: whether the output is correct, and whether you could maintain it alone for the next few months if you had to. A well-built system, whether it is an agent, an automation, or an AI assistant, has clear instructions for when it errors, and you understand enough of how it works to reset it when something in your process changes.
Does the consultant need to know my specific industry?
They need to understand your specific process, which is different. A consultant who knows your industry but cannot map a clear workflow is less useful than one who knows less about your industry but can identify precisely what is slow, repetitive, and rule-based in your operations. Industry knowledge helps them ask better questions. It does not replace process knowledge.
What happens to the system if I stop working with them?
If the work was done properly, you own it completely. The accounts should be in your business name, the tool logins should belong to you, and you should have the maintenance guide to run and restart it. If any of those things remain with the consultant after the engagement ends, you have a service dependency, not a system. Clarify this before the work starts, not after.
Evaluating a proposal for AI setup right now? Tell us the one task you want to stop doing manually and we will tell you what an honest scope for that work looks like.