AI Workflow Consulting: What It Costs and What You Actually Get

You end up with a working system running in your own accounts, documentation you can hand to somebody else, and one fewer job on your desk every week. Not a report. Not a strategy deck. That is what you should be buying when you buy this, and it is the only thing worth paying for.

The price list is at the top of this page rather than buried at the bottom, because a consultant who will not name a number until the third call is managing you.

I am Jacob King. I run King Intelligence out of Akron, Ohio, on my own, and I sell one thing: an AI operating system that lives inside the email, calendar, payments and notes you already use. Before this I was an employee benefits advisor, which is where I learned how much of a normal working week is just moving information from one place to another.

What It Costs

The Setup is $697. That is a paid two-hour session where we build the first piece on your real business while you watch, so you see the thing working on your own work. It comes with every plan, built into your first payment.

Memberships are $97 a month with no one-to-one hours, $397 a month with an hour of my time, or $897 a month with three. Annual is roughly ten times monthly. If you would rather not commit to anything, one-off working sessions are $497 an hour.

Current rates hold through December 31. On January 1 every plan goes up.

What that buys is the design, the build, the testing, the documentation, and then the part everyone forgets: keeping it alive as software underneath it changes. Price should track the complexity of the work and how much of my time you want, not how much money your company makes. Pricing this off your revenue is a tell that you are being charged what you can bear rather than what the work is worth.

What the Work Looks Like

It starts with an audit of how you actually spend the week. Not a survey, a conversation, with me rather than someone junior. We are looking for what takes the most time, what causes the most mistakes, and what has the clearest rules. Usually those are the same task.

Then one workflow gets built. One. Tested against your real inputs, adjusted, and handed over with documentation. Only then do we look at the next one.

A proper engagement includes:

• An honest audit of where your week goes
• A numbers-first call on which process is worth doing, and which is not
• The build, using tools that will still exist in three years
• Connection to the software you already run
• Testing on your real work, not a demo
• Documentation written for a person, not a developer
• Someone to call when it breaks

The most valuable thing I do on most of these calls is talk somebody out of a second project. If a process takes two hours a week, automating it is not worth what it costs to look after.

The Tools I Build On

Four or five tools cover almost everything. Anyone telling you that you need custom software written from scratch should have to explain exactly why.

Claude does the reading and writing. Pulling the details out of an emailed document, drafting a reply in your voice, summarising a call. It follows instructions closely, which matters more than raw cleverness when the output is going to a client.

n8n is my default for connecting things together. It is open source, I run my own instance, and it does not charge per run, which matters as soon as volume goes up.

Make is better than n8n for some visual work and has cleaner connections to certain software. I use it when a client already lives there.

Zapier is the easiest for a non-technical team to change later without calling anyone. It costs more per task and it is often the right answer anyway.

Custom connections handle the software that was never designed to talk to anything else. This is where experience earns its money.

What I do not use: bespoke AI models, anything blockchain-adjacent, and anything that launched last quarter. Your system should still work in three years, not break when a startup turns off its interface.

When You Should Not Hire Anyone

A good share of the people who contact me are not ready, and I would rather say so.

Your process is not written down. If you cannot explain exactly how something works today, automating it multiplies the confusion. Someone once asked me to automate their client onboarding. When I asked how it currently worked, the answer was "it's different every time." Fix that first, and you may not need me afterwards.

You are changing software soon. Do not build on a CRM you plan to replace in six months. Move first, settle, then automate.

The task takes under two hours a week. Automation carries overhead: monitoring, occasional fixes, the odd surprise. Below a couple of hours a week the upkeep can cost more than the task did.

Your team is not on board. A perfectly good system nobody uses is worth nothing. If the people who touch the process do not want it, that is a conversation to have before anyone builds anything.

The business is still moving. If you are still working out the core offer, or you have a handful of customers, put the effort into growth. Automation comes after you have something repeatable worth repeating.

You want everything at once. This fails every time. One process, proven, then the next.

How This Differs From Regular Business Consulting

A traditional consultant analyses the problem and hands you recommendations. Nothing changes unless you find the time to implement them, and you will not, because the reason you hired them was that you have no time.

This is different only in that the deliverable is the thing itself. You are not buying advice you might act on. You are buying something that is running on Monday.

The trade-off is that you are now depending on someone's technical judgment as well as their business judgment. A sharp business consultant can give terrible technical advice, and a sharp engineer can build the wrong thing beautifully. Ask for both, and be suspicious of anyone who only demonstrates one.

Questions Worth Asking Before You Hire

"Which tools do you actually use?" If the answer is a proprietary platform or a custom model, ask why the standard tools will not do. Sometimes there is a good reason. Usually there is not.

"What happens when it breaks?" It will. The question is whether anyone finds out before you do. Ask what monitoring exists and who gets the alert.

"How do you price?" A ballpark on the first call is a reasonable expectation. Anyone who cannot give one has not done this often enough.

"What would you refuse to automate?" This is the one that separates people. If they will automate anything you ask for, they are optimising for invoice size.

"Can my team change it themselves?" You should not need to call anyone to update an email template.

"Do I own it?" The system should run in your accounts, on your logins, with documentation you keep. If leaving means losing the work, you did not buy anything.

After It Goes Live

This is where a lot of these projects quietly fail. The build works for a month, something changes underneath it, and nobody knows how to fix it.

Most of the trouble shows up in the first two weeks, while people adjust. After that you have three options. Keep it in-house if someone on your team is comfortable with the tools. Stay on a membership from $97 to $897 a month and let me watch it. Or call me when something breaks and pay $497 an hour.

Whichever you choose, insist on documentation. Every workflow should come with a plain-English explanation of what it does, what each part is for, and how to make the changes you are most likely to want. If you cannot follow how your own system works, you have bought a dependency rather than a tool.

Where to Start

If you are spending more than five hours a week on data entry, follow-up email, or moving information between systems, there is something here worth doing. If you want to use AI because it seems like you should, wait. That reason produces expensive systems nobody uses.

Book a time and we will go through your week and find the one process worth fixing first.