AI implementation
By Kevin Stout, founder of Revductive · Updated September 2026
Short answer
Pick the model your team will actually open, connect it to your company’s data, fix the process before you automate it, and give it read access before you give it write access. Claude and ChatGPT are both good enough for most internal work, and the results come from what you connect them to and how tightly you scope it rather than from which one you picked.
I run a fractional RevOps and AI enablement service and I run my own business on this setup, so what is on this page is what I have learned building these for myself and for clients rather than a comparison of two products I have read about.
Book a 30-min call →02 / What the last one looked like
Last month I deployed a new pipeline for a client in HubSpot. Forty-something properties, 15 workflows, new deal stages and routing, and it came out of one conversation with Claude.
That makes it sound like the AI did the project, and it did not. It did the typing. Before I opened Claude I had a requirements doc built from client calls, meeting transcripts and a couple of hours of rewriting, so by the time I pasted anything into a chat window every real decision was already made: what each stage means, who owns the deal at each one, what happens when a lead comes in from a partner instead of a form, and which of their existing workflows I was allowing the project to touch.
The build was maybe 20% of the hours on that project, and the rest of them went into that document.
03 / Picking one
I pay for both and use them for different things. Claude’s Max plan is where most of my actual work happens, and ChatGPT Plus at $20 a month covers image generation and some browser use. For a team the answer depends much less on the model than it does on three things.
01
Check what is already inside your Google Workspace or Microsoft contract before anybody buys a new seat, because a lot of teams are paying twice without knowing it.
02
A model that can read your CRM, your docs and your calendar will beat a smarter model that cannot see any of them, every time.
03
Adoption kills more of these projects than model quality does, and the tool people already have a tab open for wins arguments that benchmarks do not.
My bigger comment is not to worry so much about who is in the lead this month. Get used to one tool for a while, then experiment with a second once you have actually mastered the first, because the gap between a practised user and a new one is much wider than the gap between the two products. I break the tools into four buckets in how I pick which AI tool to use.
04 / Definitions
Most people use AI to ask a question, get an answer, and then go back to doing the work by hand. An internal workflow is when the AI does the work itself using your company’s information, and that takes three pieces.
01
Your voice, your policies, your products, and live data out of the systems you already run. Without it every answer is generic, and generic is what makes people stop using it.
02
MCP, which stands for Model Context Protocol, is the standard way Claude and ChatGPT plug into apps like HubSpot, Notion or Google Drive. You connect an app once and the model can use it in any conversation after that.
03
Something that starts the work. For one-off work that is a person typing, and for repeatable work it is an event, like a form fill, a closed deal or a new ticket.
05 / Model or builder
General-purpose models are best when the job is a little different every time, so research, drafting, analysis and cleaning up a messy spreadsheet all sit naturally in a chat window.
A no-code workflow builder like Gumloop, n8n or Make is better when you need a real trigger, or when the exact same thing has to happen the exact same way every time, because a model might take a different route to the answer on Tuesday than it took on Monday. Albato has a gut check I use on myself: if you can draw the whole process as a flowchart with every branch labelled ahead of time, you want workflow automation and not an agent.1
Most real builds use both. On a call in June a founder was stuck generating training data by hand, and what I suggested was a spreadsheet with the source data and a prompt as the first two columns, run through the same Gumloop workflow once per row. You can plug your own model tokens into it, and it does not need an engineer to keep running.
06 / Guardrails
01
AI is really good at reading your CRM and really bad at writing to it. Once it has write access to deals and tickets it skips required fields left and right, and nobody built these CRMs expecting AI to be the thing writing into them.
02
I have heard of a team that handed an AI a full-scope API key, watched it wipe their CRM, and spent six weeks cleaning it up afterwards. Give it only the objects it needs and nothing else.
03
For HubSpot I use Daeda AI, which lists exactly what it is about to create and which existing workflows it will touch. I read it, then I approve it, and that step is the only reason I am comfortable letting it run in the background while I do something else.
04
After you get an answer you like, ask it how it could be wrong. I put that step inside automations too, not just in chats, so the check still happens when there is no person reading the output.
The read-only half of this is where most of the value sits anyway. A model reading call transcripts can fill in fields a rep was never going to fill in by hand, which I wrote about in stop adding required fields.
07 / What not to do
On the HabitStack podcast I put it this way: You can add AI to those situations, but it’s just going to amplify a really messy and inefficient situation, and potentially even cause more problems than it solves.
Scope the human work first.3
When your most sophisticated people each build their own setup, you end up with fifty silos instead of five. More on that here.
Teams run roughly 100 to 1 apart in AI skill between the best and the worst person, so a workflow built for a team that does not use AI becomes one more tool nobody opens. Enablement vs implementation.
08 / The engagement
01
Measure what the team uses today and who uses it well. That is the AI Effectiveness Audit.
02
Half of what gets called AI implementation turns out to be RevOps work with a different name on it, and it has to happen first either way. What that costs.
03
Every real decision gets made before anything gets built, which is where most of the hours go and where all of the judgment lives.
04
AI does the implementation against that spec, and our team QAs what comes out of it.
05
The workflows go to the people who use them, with the training to change them when the process changes. How we operate.
We are stack-agnostic about all of it. It does not matter whether you run Claude, ChatGPT, Gemini or a mix of them, because what decides whether this works is the process and the data underneath it.
09 / What it costs
AI engagements start at $10,000 a month and typically run 3 to 12 months, covering enablement across the team and implementation into your systems. There is not a $2,500 version of that which does anything useful, because the work touches every person on the team and every system the AI reads from. All of our pricing is published.
If you are not ready for that, start with the audit. You get an inventory of what your team uses today, who uses it well, and a 6 month plan for what to automate.
Not ready for a monthly engagement
An inventory of what your team is currently using and how, who is using it effectively, and a 6 month plan for what to automate. The full $1,200 comes off month one if you continue.
$1,200
Flat
$0
If you continue
Teams looking for one tool to buy that fixes everything. This is a change in how people work, and the tool is the smallest part of it.
10 / FAQ
Revductive AI engagements start at $10,000 a month and typically run 3 to 12 months, covering enablement across the team and implementation into your systems. The smaller way in is the AI Effectiveness Audit at $1,200 flat for two weeks, credited in full against month one if you continue.
Both are good enough for most internal work, so pick on what each one connects to, what you already pay for, and what your team will open every day. Get good at one before you add the second, because running two badly is worse than running one well.
Not for most of them. Connecting Claude or ChatGPT to common apps over MCP, and building no-code workflows in something like Gumloop, does not need an engineer. Custom integrations, and anything writing to a production system at volume, usually does.
It is safe when the access is scoped. Start read-only, give it only the objects it needs rather than a full-scope API key, and require a written plan it shows you before it writes anything. AI is very good at reading a CRM and much worse at writing to one, because nobody designed those required-field rules expecting a model to be the one filling them in.
Enablement changes what your people can do with AI. Implementation changes what your systems do without a person. Most teams need both, and enablement first, because a workflow built for a team that does not use AI becomes one more tool nobody opens.
Use the model when the job is a little different every time, like research, drafting, analysis or cleaning up a messy spreadsheet. Use a workflow builder when you need a real trigger, or when the same thing has to happen the same way every time, because a model might take a different route to the answer on Tuesday than it took on Monday.
Who wrote this
Fifteen years in B2B SaaS operations and growth, and co-founder of a healthcare SaaS product. First operations hire at Pearl, a dental AI company, and stayed five years while it grew from the early days to a couple of hundred people. He has talked through this work on the HabitStack podcast and on Show Me Your Stack, and Supered and SaaSGrid have both published case studies on it. He runs Revductive, a fractional RevOps and AI enablement service.
Newsletter
Also, reply with any question and get a guaranteed personal answer! Enter your number as well if you’d prefer tips via text.