AI consultant for B2B owners and leadership teams

Where should a company start with AI, and how do you know it’s paying off?

Start with one job that repeats, takes real time, and produces something a person can check, and give it to the person who already does that job well. Shortlist a few candidates, pilot one, and keep the first group small. You’ll know it’s paying off when you can point to the result: hours a specific person got back, a deliverable that goes out sooner, or work that’s better than it was. Count the whole workflow, including the time spent reviewing and fixing what AI produced. If the finished work is faster and worse, it doesn’t count.

Most of the companies I talk to are already somewhere on this road. Somebody on the team uses ChatGPT, somebody else bought a tool, and leadership can’t tell whether any of it adds up to anything. That’s normal. The rest of this page covers what an AI consultant should do for you, how I run a pilot, who should build what, what tends to break, when to skip AI altogether, and the calls only the owner can make.

What I mean by AI enablement

AI enablement is the work of getting AI into the way a company actually runs. The people doing the work use it on jobs that matter, and someone is checking that the output is any good.

Buying licenses is the easy part, and it’s where a lot of companies stall. After that comes deciding which work AI should touch, giving it clear instructions, good examples and a way to check the result, and changing habits that have been in place for years. An AI consultant, the way I do it, helps leadership make those calls and stays with the agreed pilot through the evaluation and the decision on what comes next. A list of use cases and a tool comparison have their place, but the list is rarely what’s missing.

A word you’ll see on this page is “skill.” A skill is a reusable set of instructions, examples and tools for one particular task, like drafting a proposal in your format or reviewing a sales call.

How I run an AI pilot

The shape is usually the same, whatever the job.

1. Shortlist the candidates. We list the repeated jobs that take real time and look at each one: how often it happens, what it’s worth, whether the information it needs is reachable, and whether someone wants to own it.
2. Pick one pilot and set the baseline. How long the job takes today, who reviews it, and what good output looks like, written down by the person who does it best.
3. Build or configure the first version. Sometimes that’s an off-the-shelf tool set up properly. Sometimes it’s a skill your expert shapes and I or a developer put together.
4. Test it on real work. Run it against a batch of representative examples before anyone relies on it, and compare the results to the baseline, review time included.
5. Train the people using it. Show them how to use it, what to check, and where to report what goes wrong. The first few weeks of use are where most of the fixing happens.
6. Decide. Widen it, change it or stop it. A pilot that gets stopped has still told you something useful.

What you should come away with: a prioritized list of candidate jobs, a written scope for the pilot, the measures we agreed on, instructions for the people using it, and a recommendation on what happens next.

I build these systems now, and it changed my advice

I build prototypes and internal tools with Claude Code. I’m not a software engineer and I don’t pretend to be. What I bring is twenty years of knowing what the output should look like, and whether what came back is any good. That’s necessary, and it isn’t the same as knowing a tool is technically reliable. Anything that writes to your systems, handles your customers’ data or runs without a person reading it needs a qualified developer to review it and own it.

The tool that changed my thinking the most is small. I get off a sales call, drop the transcript in, and run a skill I built to evaluate the call. I consider myself pretty observant in the moment, and it has still flagged moments I missed. It’s an interpretation of the call, so I treat what it flags as questions to check against the transcript. I walk into the next call better prepared for the things I tend to miss.

That’s the shift I’d want every leadership team to make. At some point I stopped thinking about Claude as a way to automate things and started treating it like another thinking partner in the room. The question I ask now is how I can build a skill that helps me do something well, and I’ve mostly stopped asking how to make the work disappear.

Building these myself also taught me where they break, which turns out to be most of what I bring to a client.

Which work should AI take on first?

The best first job repeats, takes meaningful time, has inputs you can get at, produces output someone can check, and belongs to a person who wants the help. Boring is usually a good sign. Meeting notes are the classic example, which is why I argued that your first AI hire should be a meeting note-taker. After that: proposal first drafts, call reviews, the weekly report someone assembles by hand, research before a big meeting.

I built a meeting-prep skill for a client that researches who’ll be in the room and drafts a playbook of the objections they’re likely to raise. Nobody would call that glamorous. It gives the person preparing a research brief to work from, and they still decide what matters.

What I’d leave for later: anything customer-facing that runs without a person reading it, and anything that touches money or contracts before testing shows you can trust the output. Every business is more complicated than it looks from across the street, and the first few months are how you find out where the complications are.

A quick test for any candidate job: would you let a brand-new intern do it without checking every last bit? Nobody sends a $100,000 proposal to a new client on an intern’s first draft. Treat AI the same way. Reduce the checking only when testing supports it, and keep a person approving anything consequential.

When you shouldn’t use AI at all

Some jobs are better served by something simpler. If the steps are fixed and the rules never change, conventional automation or a good template will be cheaper and more predictable. If the job happens twice a year, the setup costs more than it saves. If a mistake would be expensive and there’s no practical way to check the output, leave it with a person. And if the real problem is that nobody agrees on how the job should be done, settle that first. AI will just do the disagreement faster.

Who should build it?

The people who know what good looks like should be shaping the tools. When companies hand AI to someone who doesn’t know the job, they tend to get tools that technically work and that nobody uses.

The systems that work show AI what good looks like: examples, standards, the judgment calls written down. The best of that is hand-curated by the people who are craftsmen at the job. Your senior estimator knows what a good estimate looks like. Your best account manager knows what a client update should say. They should define what the tool must do and test what comes back, even when someone else builds it.

Who builds depends on what the work demands. A skill that drafts a document from your examples can be built by a capable person with help. Anything that connects to other systems, handles sensitive data or faces customers needs a developer involved from the start, along with whoever maintains the systems it touches. I’ll help you choose that person and judge what they deliver.

It takes patience, too. I treat skill-building as something you work on every time you use the skill. My first one was bad. The second was a little less bad, and it still took me a long time. It compounds, though. The skill I use to draft pages like this one now gets me most of the way there almost every time.

What happens after the first version works

This is where a lot of pilots quietly die, so we settle it before building. Someone owns the instructions and examples, usually the person whose work it is. Someone owns the technical side: access, changes, fixing it when it breaks, usually your IT team or the developer who built it. The skill gets written down well enough that someone else could pick it up. And the tool you choose this quarter may be replaced next quarter, so keep the valuable part, your examples and standards, in a form you own and can move.

If I build the first version, we agree up front who takes it over and when.

What usually breaks

I’m a heavy proponent of using AI everywhere it helps, and I don’t promote using it as a way to be lazy. The failure I see most is volume. A team gets faster, output triples, and quality slides without anybody quite noticing, because every piece looks finished. I wrote about this in AI formatting is not a proxy for quality. Clean headings and confident sentences make weak work look done.

AI can buy you speed through automation and shorter research. If the goal is better work, that time has to be reinvested in specificity and quality.

A few other things break often enough to plan for:

• Seats nobody opens. Wanting people to use it doesn’t mean they will. I recently advised a leadership team at an industrial services company to start with the smallest group that had a specific job for it and widen from there, because licenses are an easy way to waste a lot of money.
• Inputs and outputs. Poor inputs make reliable results harder, and good inputs still need testing, because these tools can be confidently wrong. AI data quality goes deeper on the input side.
• Drafts that are correct and still wrong. My own team ran into this. A month of AI-assisted drafts came back technically correct, and I didn’t approve any of them, because none of them sounded like something I’d say. Producing more drafts wasn’t helping, so we’re feeding the system better examples of how I actually talk.

What leadership has to decide

A lot of this can be delegated. A few calls can’t.

• What the time is for. Some companies use AI to do the same work with fewer people. Others use it to do better work with the people they have. Both are choices an owner can make, and they lead to different rollouts, hiring plans and conversations with your team. Make the call on purpose and say it out loud, because your team is guessing either way. Then judge the project against the goal you picked.
• What information goes where. Decide which information each approved tool may handle, under what conditions, and who approves access, with your IT and security people in the room. Set it before somebody pastes in something they shouldn’t. What your client contracts allow is a question for whoever handles your legal review.
• Who owns it. One person accountable for adoption in each area, with time set aside for it. When it’s everyone’s side project it becomes nobody’s.
• How you’ll judge it. Pick the measures before you start.

AI in your marketing and brand

If you came here looking for an AI marketing consultant, or for help with AI and your brand, this part is for you. Marketing is usually where AI shows up first in a company, because content is the easiest thing to make more of. It’s also where the mediocre-work problem shows up fastest: blog posts, ads and emails that are plausible and say nothing specific. Buyers notice.

Where I’d put AI to work in marketing: research and competitive analysis, mining sales-call transcripts for the language customers actually use, first drafts that a person rewrites with specifics, and campaign reporting nobody should be assembling by hand. Where I’d be careful: anything that speaks in your brand’s voice without someone who knows the brand reading it first. The pilot method above works the same way here. Pick one job, set the standard with whoever owns the brand, test it, then widen it.

Showing up when buyers ask ChatGPT, Gemini or Google’s AI answers who to talk to is a separate job with its own page: answer engine optimization.

I’m based in Houston, Texas, and I work with companies across the U.S., mostly remotely.

How long does it take?

If you pick a narrow job, a usable first version often shows up in the first month. A skill your team relies on takes a few rounds of use and correction. Getting AI into habits across a whole company takes longer, and much of that is people work: examples, training, and leaders using it in front of their teams. Some workflows need very little development. Others need an engineer from the first week, and that changes the timeline.

After the first pilot, the work settles into a standing review: what’s being used, what isn’t, what got better. The tools that stick get widened to more people. The ones that don’t get cut, and that’s a fine outcome too.

How do you know it’s paying off?

Pick the measures before you start, and keep four kinds of payoff apart, because they get blurred constantly.

• Capacity back. A specific person has hours a week for other work. Real, but it only saves money if something changes because of it.
• Cash saved. An actual expense goes down or is avoided, like a contractor you no longer need or seats you stop paying for.
• Better work. The proposal is sharper, the report catches more, the sales call review teaches you something.
• Faster delivery. Less time between the request and the finished thing. A proposal that goes out two days sooner is faster delivery. It doesn’t mean two days of labor were saved.

Then count the work AI creates: setup, review, corrections, training, upkeep and the licenses themselves. A draft that needs heavy rewriting may save nothing. Whether the sales team uses the proposal drafts or quietly rewrites them from scratch tells you a lot.

Add a judgment check from whoever owns quality: is the finished work as good as it was before, or better? If the answer is faster and worse, that’s a useful finding. It might mean the examples and standards need work. It might also mean the tool, the information it can reach, or the job itself is the wrong fit. I’d much rather find that in month two than in a client’s inbox.

None of this is magic. It takes someone deciding what AI is for in your company, and then checking every month whether it’s doing that job.

If your company is earlier in that process than you’d like, the business advisor page covers how I help owners with operating decisions like this one.