Where to Use AI, Where to Start, and How to Get More Value

The Seven Step Framework

Start with one workflow. Break it into its individual steps, then run each one through the seven steps below.

1. 1Sort the work into Explicit vs Implicit.
2. 2Size the risk and impact of getting it wrong.
3. 3Decide how closely a person needs to be involved.
4. 4Know when the system should stop or start.
5. 5Build a governance model with a name on it.
6. 6Deploy it as a pilot with phases, not a full rollout.
7. 7Train or re skill the people.

Sort the Work into Explicit vs Implicit

Every job mixes two kinds of knowledge. Explicit knowledge can be written down as a rule: do this, check that, if X then Y. Pulling a contact list against a defined profile, filling a template, applying a fixed pricing rule: all explicit, because anyone following the rule reaches the same answer.

Implicit knowledge resists being written down. It depends on judgment built over time, and the person doing it well usually can’t explain how. Reading the tone in a reply, deciding a customer is ready to buy: judgment nobody wrote down. A simple test: try writing complete instructions for the task. The moment the only honest one left is “use your judgment,” that’s the implicit part. Ask AI to do implicit work anyway and it will still answer with confidence, but confidence is not judgment. It is often the same wrong answer, delivered smoothly.

Take outbound sales prospecting, one workflow we’ve mapped down to the hour. Researching contacts and sending scheduled follow ups are explicit. Writing the message that earns a reply, and judging whether a prospect is ready to talk to a salesperson, are implicit. Hand the explicit half to AI and the math isn’t subtle: that workflow dropped from 429 hours per campaign to 15, a 28x reduction, without changing who owns the sales conversation.

The practical rule: fully explicit work can go to AI outright. Work that mixes fixed facts with a little discretion needs a person checking the output. Implicit work stays with a person.

Size the Risk and Impact of Getting It Wrong

Once you know what a task is, ask what happens when the system gets it wrong. Three levels matter.

Low risk: the error stays inside the company, gets caught before anyone outside sees it, and costs minutes to fix. A screening system misclassifies a few contacts; a routine check catches it.

Medium risk: the error reaches someone outside the company but stays contained to one interaction, a factual slip in a personalized message. Bad, but recoverable.

High risk: the error reaches many people, creates legal exposure, or damages trust in a way a quick fix can’t undo. A flawed template goes to an entire mailing list before anyone catches it, or a system fails to honor a legally required stop contact request.

The kind of harm matters as much as the level: financial, legal, and reputational come up most often. An airline chatbot found this out when it told a grieving customer the wrong bereavement discount policy. A tribunal held the airline responsible, not the chatbot, not the vendor, all three kinds of harm in one failure. Naming the kind of impact you’re managing keeps the oversight decision honest, instead of defaulting to whatever feels comfortable.

Decide How Closely a Person Needs to Be Involved

Three levels of human oversight cover almost every situation.

Human in the loop means a person reviews and approves a specific output before it takes effect. Nothing moves without sign off. It’s slow on purpose, for when a wrong output is expensive or can’t be undone.

Human over the loop means a person samples a defined portion of output on a regular schedule and steps in when something looks off. The system runs mostly on its own.

Human out of the loop means the system runs with no routine review, because the task is fully explicit, an individual mistake is cheap, and errors get caught some other way.

Match the level to the risk and the kind of impact, not to how much you trust the vendor. Low risk work can run out of the loop, or over it with light sampling. Medium risk needs human over the loop, a documented schedule, and a clear escalation path. High risk, anything customer facing at volume, anything with legal exposure, anything hard to reverse, needs human in the loop: a named person approves before the action executes.

A dealership chatbot learned this the hard way: it ran human out of the loop on customer facing pricing, high risk work that needed a person approving before launch. A customer talked it into agreeing to sell a $58,000 SUV for $1, and the exchange went viral. Nobody had defined what commitments it was authorized to make, and nobody was watching to catch it.

Know When the System Should Stop or Start

A system doesn’t announce when it’s failing. You need numbers that do it for you, decided before launch, not after something goes wrong.

Pick a few measures specific to the task, each with a hard number attached, and act automatically when a number is crossed. A task where an error stays internal can tolerate a wider margin than one that reaches a customer, and a regulated industry sets a tighter bar. One workable starting point: an error rate, such as accuracy of a match, that stays under 5%; cross it and the system gets restricted or paused until someone finds the cause. Treat that 5% as an illustration, not a rule to copy. What matters is landing on an actual number for your workflow, not a feeling.

Some triggers shouldn’t wait for a percentage. A single confirmed miss on a legally required action should pause the system immediately. Watch the override rate too, and whether people are still checking the system’s work or have quietly stopped.

Restarting after a pause takes more than a clean check. Fix the root cause, then confirm it holds across more than one review cycle before returning to normal.

Build A Governance Model With A Name On It

Every AI system needs one named executive accountable for what it does, not a committee. Spread accountability across a group and it thins out until nobody actually holds it. That person doesn’t personally review every output; they own what happens when the system produces a bad outcome. They also need to actually know the workflow: which parts are explicit, which carry legal or reputational exposure, and where the stop and restart thresholds kick in. A name that can’t answer those questions is a name on an org chart, not the person you go to when the system breaks.

Below that person, a functional owner handles the day to day work: running the sampling schedule, tracking the numbers, and deciding when something needs to move up the chain. Accountability never transfers to the AI system, the vendor who built it, or the employee who happened to be using it that day. The organization deployed the system, so the organization owns what it does.

Define a failover process too, in writing, before it’s needed. Three pieces make it real: a way to notice quickly, which metric or channel sees the problem first; a manual fallback, who picks up the task while the system is paused; and a documented decision path, corrected, restricted, paused, or escalated, and who makes that call. If you can’t answer those three questions today, the system isn’t ready to run unwatched.

Deploy It as a Pilot, Not a Full Rollout

Launch this on one bounded piece, not the whole workflow, alongside the existing manual process so there’s something to compare against. Give whoever owns the task a sampled portion of the output to check, and track the error rate against your threshold. Expand only once that evidence holds. The first thing to automate is never the whole job, it’s the narrow piece where a mistake costs a few minutes to fix.

Phased rollout does something for the people doing the work too. Watching one piece run safely builds real confidence no accuracy report can substitute for. Each stage gives them a way to contribute: flag what the output got wrong, shape what changes before the next piece launches. Because the role shifts one piece at a time, they watch their own job change in stages, not wake up to a role that’s unrecognizable overnight.

Train or Re Skill the People

Bring AI into a workflow and the work changes shape rather than disappearing: someone now reviews what the system produced, decides when to escalate, and knows what to do the moment it stops working. A manual fallback that people can run on their own, without waiting on IT, turns a failure into a pause instead of a full stop.

Training has to build three specific skills, not general comfort with the tool: recognizing a plausible but wrong answer, since a confident output and a correct one look identical until checked; giving feedback that actually improves the system instead of quietly working around its mistakes; and running the manual fallback cold, so the first time isn’t during a real outage.

There’s a less obvious risk worth training for on purpose: relying on a system can quietly erode the skill it replaces. Skip the sampling and the practice, and the person who used to catch a bad match by instinct loses it right when the system needs a second pair of eyes most. The lesson isn’t to avoid the tool, it’s to keep practicing the judgment on a schedule.

Hiring changes too. As explicit, repetitive work moves to AI, the people hired for it need less tolerance for administrative volume and more judgment, communication, and comfort reviewing machine output, a different job description than the role had before. Treat it like the old one, and the hiring and training plan quietly falls out of step with the actual work.

See It Applied

Everything above is the framework. See it applied in two real engagements: our Demand Generation case study, where sorting explicit from implicit work cut manual hours from 429 to 15 per campaign and moved the team from 30% to 80% customer facing time, and our Market Validation case study, where the same distinction turned outreach and enrichment into an owned prospect database of 3,000 buyers with a 20% plus real engagement rate, evidence a traditional research report never delivers.