How We Actually Run an AI Engagement

How We Actually Run an AI Engagement

There's a version of AI consulting that looks like this: a vendor shows up, runs a discovery workshop, produces a slide deck with a maturity model, and recommends a six-figure platform purchase. The client buys it. Six months later, 30% of the team is using it, and nobody can explain what changed.

We built Revival Group because we've lived on the client side of that story, and we knew there was a better way to do it — especially for SMBs who don't have the tolerance for a 12-month implementation before they see any value.

Here's how we actually run an engagement.

Solve the problem before you build anything

McKinsey's value — whatever you think of them — has never really been the slide deck. It's the structured clarity they bring before any execution starts. They've already seen the problem in 40 variations across 20 industries, so the answer is often already known. The client just needs someone to see through the noise of their specific situation and name it.

We try to operate the same way. When we start a new engagement, we don't open a laptop and start building on day one. We spend time understanding what's actually broken — not what the client thinks is broken, which is usually a symptom rather than the cause. And one thing we've learned: the requirements-gathering conversation, recorded, transcribed, and fed to Claude, is often worth more than a month of independent research.

That distinction matters especially in AI, because clients often arrive having self-diagnosed. "We need a chatbot." "We need an automation for this workflow." "We need a dashboard that pulls from all our tools." Those are answers, not problems. Our job is to back up and ask the real questions: what decision are you trying to make faster? What process is actually costing you the most time? What would need to be true for this year to look meaningfully different from last year?

How an engagement runs

It starts with training. Before we scope anything, we run a short session with the client team — not to sell them on AI, since they're already interested, but to recalibrate what's genuinely possible now versus 18 months ago, so we stop designing solutions around legacy assumptions.

From there we assess and prioritize. We run 30-minute sessions with three to five internal stakeholders, capturing their existing workflows, current pain points, and what they actually want. Then we reconcile that with what we'd recommend building from the ground up. The gap between those two is where the real design work happens.

Next, we build a roadmap — or the equivalent sprint — scoped to a concrete deliverable within two to four weeks. Not a "phase one" that quietly runs until Q3, but something they can see, use, and react to. Nothing builds trust faster than a working thing.

Finally, we iterate and hand off. We build for ownership, not dependency. The goal is always to reach a point where the client's own team can maintain and extend what we built, with us available for the next layer rather than required for day-to-day operation.

The artifact standard

One thing we've made non-negotiable internally: every update, every handoff, every status check comes with something digestible — a two-minute summary video, three slides, or a structured brief you can absorb in 90 seconds.

This came from a realization about how AI changes the work. Claude generates the project plan, the documentation, the summary. That's not the differentiating work anymore. The differentiating work is collecting the right context, asking the right questions, and knowing what good looks like. The artifacts are almost free to produce now. The judgment about what to capture is not.

A real example

A nonprofit came to us having already evaluated an off-the-shelf ERP. We ran our intake process, reviewed their existing proposals, and within a week could show them a better architecture: purpose-built modules with AI-native workflows, instead of a Salesforce-style CRM bolted onto a nonprofit. Faster to build, cheaper to maintain, and actually designed for how their teams work. The training session at the start is what made that conversation possible.

What "4–5x faster outcomes" actually means

We use this framing in our positioning, so it's worth being specific. It doesn't mean we cut corners. It means AI handles the parts that used to require weeks of analyst time — document synthesis, requirements extraction, draft generation, options comparison — while we spend our hours on the judgment calls, the stakeholder alignment, and the implementation that still needs a human in the room.

A traditional consulting engagement on a project like ours typically runs three to six months before the client sees a working system. We aim for first working output in two to three weeks. Not because we rush, but because the tools now let us compress the parts that used to be slow without compressing the parts that matter.

Who this works for

This model works best for SMBs and mid-market organizations that already know AI matters to them, have a clear operational problem to solve, and need someone to get them from interested to operational without building an internal AI team first.

It doesn't work well for organizations still in the "show me why I should care" stage — that's a different, and usually shorter, conversation. And it doesn't work for clients who want a vendor to own everything indefinitely. We're building toward your independence, not managing your dependency.

If that sounds like the kind of engagement you've been looking for, the first conversation is free.