A price for “AI consulting” tells you very little until you know what the engagement includes. For a Minnesota agency or service business comparing help, the useful starting point is a defined piece of work, its acceptance conditions, and the responsibilities that continue after delivery.
I do not publish a universal price or timeline for these projects. A readiness review, a team workshop, and a connected workflow require different work. Here is how I would make a proposal easier to understand before discussing fees.
Name the thing you are buying
A readiness engagement should leave you with decisions: current use, candidate tasks, requirements, priorities, and an owner for the next step. A training engagement should specify what staff will practice and which examples, instructions, and review guide they take away.
An implementation proposal should describe a working output and its boundaries. “Prepare an account-update draft from approved sources for the account lead to review” is specific enough to discuss. “Transform agency operations with AI” leaves the buyer guessing.
Support needs its own description. Ask which questions, changes, and reviews it covers, who can request them, and when the scope will be revisited. Buying an initial build does not explain who maintains it afterward.
Follow one task from input to accepted result
Walk through a recent example with the person who does the work. Record where the information lives, how it is prepared, who checks it, and what happens next. Include the steps that a polished demonstration might skip.
For a report draft, gathering approved updates and resolving conflicting dates may require more attention than writing the paragraphs. A connected source can introduce access setup, field mapping, and exception handling. Those requirements belong in the scope before anyone estimates the build.
Agree on the first boundary: which team, which output, which sources, and which actions. State what is excluded. Expanding from preparing a draft to sending a client message changes the work and the approval requirements.
Separate setup from ongoing cost
Ask for a clear distinction between the engagement fee, third-party charges, and your team's effort. Initial work can include discovery, source preparation, configuration or development, testing, training, and documentation.
Ongoing costs can include the selected software plan, usage charges, hosting where needed, support, and maintenance. These depend on the actual design and supplier terms. Confirm which charges are included, which you pay directly, and which remain estimates.
Include preparation, review, and correction time in the operating picture. A draft arriving quickly is only useful if the complete task improves. Have someone own the recurring-cost review and know where to check usage and invoices.
Put assumptions beside the estimate
A proposal should say what the provider has already checked and what still needs investigation. Available integrations, access approval, source quality, expected use, and staff availability can affect the work.
Ask what happens if an assumption proves wrong. Does the engagement begin with a contained investigation? Is there a decision before further implementation? Who approves a revised scope? An unknown can be managed when it is visible.
For training, describe the audience's starting point, tool access, sample preparation, and practice needed. Those details explain the work more clearly than attendance numbers alone.
Define how you will accept the work
Specify representative examples and the review criteria before approving implementation. Include an ordinary task, an incomplete input, and a conflict the workflow should surface. Name the person who can accept the result.
Check facts, required fields, source references where relevant, action boundaries, and the effort needed to correct the output. A proposal should explain how test findings are addressed and what remains outside the delivered version.
Agree on the decision after the pilot: continue, revise, or stop. Keep estimated benefits separate from observed results. A forecast of hours saved is an assumption to test, not a completed business outcome.
Compare the same scope and discuss changes
Read proposals against the same task and acceptance conditions. Compare deliverables, exclusions, dependencies, third-party charges, your responsibilities, and the handoff. A lower headline fee may describe a smaller engagement; make that difference explicit.
Discuss how new requirements are approved and charged. Clarify the distinction between correcting an agreed deliverable and adding a source, output, or user group. Ask what happens when a connected service changes or access stops working.
Write down what the team receives: instructions, configuration details, agreed code or materials, test examples, account responsibilities, and support contacts. Confirm ownership and permitted use in the agreement rather than assuming them.
The scope checklist below helps put these questions in one place. You can use it with any provider. Bring the task and open questions to a free 30-minute AI consultation with me; any paid work has separately agreed deliverables, timing, and fees.