The stages aren't a sales funnel. They're a map of the work a business needs to do to become digitally capable. Most of our engagements enter at Stage 02, 03, or 04. A handful enter at Stage 01 because the client is genuinely at the beginning and wants to get it right before spending money on execution. Almost none do all six sequentially — the stages are more often parallel or overlapping, deployed in the combination the business actually needs right now.
But understanding what each stage delivers makes it easier to identify where you are, what you're missing, and what a realistic engagement looks like. This is the practitioner's breakdown: not the marketing version, but the one we'd give a founder on a fit call when we have 30 minutes and want to be useful.
Stage 01 — Plan
The work that turns an idea into something executable. Vision workshops, business plans, OKR/KPI trees, incorporation support, operational roadmaps. Stage 01 is often the most skipped stage in the entire framework — founders move straight to building without a plan, or to a website without a strategy. The urgency to make something usually wins over the discipline to know what you're making.
When Stage 01 is done well, its deliverable becomes the north star for everything that follows. The goals articulated here are the same goals that Stage 04 dashboards will eventually measure. The structure mapped here is what Stage 03 systems will be built to support. Skipping it doesn't save time; it means every downstream stage operates without a reference point, and you end up building things that don't connect to each other.
Common shapes: vision workshop, business plan, KPI/OKR framework, incorporation and registration support, operational roadmap.
One thing worth saying plainly: the deliverable is the plan, not the slide deck. We've seen too many engagements where the "business plan" was a 60-slide PowerPoint nobody read after day one. A working plan is a short document with clear objectives, defined metrics, and an owner for each. If it can't be summarized on one page, it's usually not finished yet.
Stage 02 — Brand
First impressions are digital. Before a potential client meets you, they've Googled you. The website they land on, the logo, the email address, whether you have a domain that isn't @gmail.com — these form an opinion in seconds. Stage 02 is the work of building the credibility layer: the site you'd confidently point a customer to, not the one you apologize for while handing over a card.
This isn't aesthetics for its own sake. It's the external face of everything else you build. A company with solid systems, a real product, and a credible team loses deals because their website makes them look like a weekend project. Stage 02 closes that gap.
Common shapes: custom website design and build, logo and brand system, print collateral, professional email and domain setup, post-launch support.
We build in HTML/CSS/JS rather than WordPress or Webflow by default — not because those are wrong tools, but because a custom build gives clients full ownership of the code, no plugin dependency chain, and a site that doesn't break when a theme auto-updates at 2 a.m. That said, we'll recommend the right tool for each situation. If a client needs a CMS-driven blog with a non-technical editor and a tight budget, WordPress with a locked-down theme may be the right call. We're not religious about this.
Stage 03 — Systems
Past the spreadsheet, before the SaaS sprawl. Stage 03 is the work of building the operational infrastructure a business actually runs on: CRM, ERP, bookkeeping, workflow automation, cloud architecture, custom applications when nothing off the shelf fits the use case.
Common shapes: CRM implementation (Dynamics 365, HubSpot, Zoho), ERP setup, custom Power Apps or React/Node applications, workflow automation (Power Automate, AI agents), cloud database architecture (Azure SQL, Firebase), bookkeeping systems.
The key tension in Stage 03: most businesses underinvest here until something breaks. The spreadsheet that runs the business — the one only one person knows how to use, the one with the formulas that haven't been touched since 2019 — is usually one person's resignation away from a crisis. Stage 03 replaces the single point of failure with a system that survives personnel changes. It's not glamorous work, but it's the foundation everything else depends on.
When a small business needs bookkeeping and CRM at one fixed price and doesn't want to manage two separate tools, we often recommend Ledger247 — our own product, built exactly for that gap — rather than stitching together QuickBooks and HubSpot and paying for both. We'll say so on the fit call. If a third-party tool is a better fit, we'll say that too.
Stage 04 — Intelligence
This is the work that turns data into decisions. Not a pretty dashboard built on top of an Excel export — a properly governed semantic model with one definition per KPI, row-level security, automated refresh, and a report that leadership can trust on Monday morning without someone spending Friday afternoon manually compiling it.
Stage 04 is our flagship. It's where most of our longest engagements live, and it's where the stakes are highest. A bad semantic model produces confident-looking wrong numbers. The damage is often invisible until someone notices that two reports say different things about the same metric, and by then decisions have been made on the wrong one.
Common shapes: Power BI environments (semantic model + reports + governance), executive scorecards, KPI hierarchies and OKR tracking, SQL-backed reporting, Python/R analytics, data lineage and quality work, multi-site reporting unification.
We don't write a single DAX measure that the team can't read six months later.
That's not a style preference — it's a practical requirement. A semantic model that only the consultant understands is a lock-in risk, not an asset. We design every Intelligence engagement to be extensible by the client's team. Which brings up the direct dependency: Stage 04 without Stage 05 is incomplete. The best semantic model in the world fails if nobody on the client side knows how to maintain it. We plan for handoff from the first design session.
Stage 05 — Enablement
Knowledge transfer is the deliverable. Every system we build comes with the training to run it. Stage 05 is often treated as an afterthought in consulting engagements — a 30-minute walkthrough at the end of the project, scheduled because someone put it on the agenda, not because anyone believed it mattered. We treat it as a core deliverable on the same level as the system itself.
Common shapes: structured handoff sessions, admin and power-user training, Loom video walkthroughs, custom documentation, digital literacy workshops for community partners.
The measure of Stage 05 success isn't "they know how to use it." It's that the client's team can extend what we built without calling us. They can add a new KPI to the semantic model. They can modify a workflow automation when the business logic changes. They can onboard a new team member without relying on the original consultant to explain the system. That's the bar we build to.
There's a reason we run a 32-module digital literacy program for Canadian community organizations separately from our commercial work. It's not charity-adjacent marketing — it's the same teaching framework, applied to audiences who have even less room for error when systems fail them. The principle is the same in both contexts: technology only matters when people can use it independently.
Stage 06 — Operate
After handoff, engagements don't really end — they evolve. Stage 06 is what happens next: ongoing fractional retainers, quarterly system health checks, post-launch optimization, the occasional "something broke and I need you today" call. It's the optional but common layer that keeps everything running as the business changes.
Common shapes: 30-day post-handoff support window, quarterly health checks, fractional CIO/CTO/CDO retainers, annual KPI review and refresh, post-launch optimization sprints, vendor decision support, hiring help when the client is ready to bring a function in-house.
Stage 06 exists because systems need maintenance, business requirements change, and having a team that understands the existing environment is vastly more efficient than bringing someone new in every time. The typical alternative — calling a new consultant when something breaks — means spending the first few weeks on context that we already have. That's expensive for the client and slow for everyone.
The goal is still independence. Stage 06 is about keeping systems healthy and making deliberate decisions about when to extend them, not about creating a dependency. When a client is ready to bring a function fully in-house and we're the right team to help them hire and transition, we do that. The engagement ending on good terms is a better outcome than the engagement continuing past its useful life.
How most engagements actually work
Most clients enter at Stage 03 or 04. They have a functioning business, some version of a brand presence, and operational chaos underneath. The presenting problem is usually something specific: "our reporting is a disaster," or "we're running three CRMs and none of them are right," or "we don't have anything Power BI can connect to that's actually clean." We start there.
Some clients come in at Stage 01 because they're genuinely at the beginning and want to do it properly before spending money on execution. That's the right call when the business model itself hasn't been validated, or when the founder and co-founders are still working out what they're actually building. Starting at Stage 01 saves a lot of rework downstream.
Almost no engagement does all six stages sequentially. The more common pattern is a cluster: Stage 03 and 04 together, with Stage 05 built into both. Or Stage 02 and 03 in parallel, with a Stage 06 retainer afterwards. The stages are a vocabulary, not a prescribed sequence.
The real value of the framework is diagnostic. When a client says "we need better reporting," the six-stage map helps distinguish whether the real problem is in Stage 03 (no clean data source for the reports to connect to), Stage 04 (a data source exists but there's no governed semantic model — the measures are inconsistent or wrong), or Stage 05 (a semantic model exists and is correct, but nobody on the team knows how to build reports against it or maintain it). The treatment is completely different in each case, and the first conversation goes faster when both sides have words for the distinction.
That's what the framework is for.