The Agency Tech Stack Audit: Killing Duplicate Workflows

A practical agency tech stack audit framework: find workflows duplicated across your CRM, spreadsheets and PM tools, and consolidate without a risky migration.

The friction most agencies feel every week comes from the same workflow (pipeline, tasks, client status) being rebuilt in the CRM, a spreadsheet, and a project management tool at the same time, with no agreement on which copy is real. The fix is a tech stack audit that inventories workflows instead of tools, assigns one system of record per workflow, and retires the copies incrementally — no big-bang migration required.

Here’s the framework we use, step by step.

Why counting tools misses the point

We’ve made the full argument elsewhere that the tool usually isn’t the problem — the process around it is — in Switching CRMs Won’t Fix Your Pipeline — Here’s What Will, so we won’t re-argue it here. The short version that matters for this audit: sprawl is measured in duplicated workflows, not in subscription count.

A typical version we see with clients: the sales pipeline lives in the CRM. Then a partner builds a “deals” spreadsheet because they want a view the CRM doesn’t give them. Then someone mirrors active deals into the PM tool so the delivery team can see what’s coming. Now every deal update has to happen three times — and it never does. Within a month, all three copies disagree, and the team’s real behavior is to trust none of them and ask in Slack instead.

That’s the actual cost of duplication: not the subscription fees, but the reconciliation work, the stale answers given to clients, and the slow erosion of trust in your own systems. Once people stop trusting the data, they stop updating it, which makes it worse. It’s a spiral, and canceling a tool doesn’t stop it.

The audit: five steps

Block out half a day with whoever touches ops, sales, and delivery. For a team under ~25 people, that’s usually enough to complete the whole exercise.

Step 1: List workflows, not tools

Start from the work, not the software. Write down the recurring workflows that keep the agency running. For most agencies the list is short:

  • Sales pipeline (leads → proposals → closed)
  • Project/task delivery
  • Client status reporting (“where is my project?”)
  • Contacts and relationship history
  • Invoicing and payment tracking
  • Internal capacity and resourcing

If your list has more than ten items, you’re listing tasks, not workflows. Zoom out.

Step 2: Map every place each workflow lives

For each workflow, ask the team: “Where do you actually go to see or update this?” Not where it’s supposed to live — where people actually look. Be honest and include the shadow systems: the spreadsheet only one account manager maintains, the Notion page from last year, the whiteboard, the group chat thread that functions as a status board.

This is the step people skip, and it’s the whole audit. Most agencies we work with find two to four homes per workflow, and the team is usually genuinely surprised by at least one of them.

Step 3: Grade each duplicate — and find out why it exists

For every duplicate, answer two questions:

  1. Is it a copy or a view? A copy holds data that must be manually kept in sync (a spreadsheet re-typed from the CRM). A view reads live data from the source (a dashboard, an embedded report, an integration). Copies are the problem. Views are fine.
  2. Why was it created? Every duplicate exists because the primary tool failed someone. The deals spreadsheet exists because the CRM couldn’t produce the report a partner wanted. The mirrored task board exists because the client couldn’t be given access to the PM tool. Write the reason down — if you kill the duplicate without solving the underlying need, it tends to grow back, often within a few months.

Step 4: Declare one system of record per workflow

Now make the calls. For each workflow, pick exactly one tool as the system of record — the place where the data is created, updated, and trusted. Everything else becomes either a read-only view or a candidate for shutdown.

A few principles that make these decisions easier:

  • Put the workflow where the daily work happens. If your delivery team lives in the PM tool, tasks belong there — don’t force task tracking into the CRM just because the CRM “can” do it.
  • Anything client-shaped should resolve to one CRM. Contacts, deal history, communication logs, and client status belong in a single system. If a client emails asking where things stand, whoever answers should need exactly one tab open. Platforms that combine CRM, pipeline, and client-facing views in one place — OpenAva is built around this idea — remove the most common duplication we see, which is the CRM-to-spreadsheet-to-status-doc chain.
  • Spreadsheets are for analysis, never for record-keeping. A spreadsheet that gets written to on a schedule is a system of record wearing a disguise, and it’s the one that will silently drift.

Expect one or two contested calls. That’s normal — someone built each duplicate for a reason, and Step 3 told you what that reason is. Solve the need (a better report, a client portal, a shared view) as part of the decision, not after it.

Step 5: Retire the copies, one workflow at a time

Do not consolidate everything at once. Take one workflow per cycle, so the business keeps running while you work:

  1. Pick the workflow with the worst duplication pain — usually the pipeline or client status.
  2. Bring the system of record up to standard first: import what’s missing, build the view that the shadow spreadsheet was providing, grant access to everyone who needs it.
  3. Run both in parallel for two to four weeks, but make the system of record the only place updates happen. The old copy becomes read-only.
  4. Then archive the copy. Don’t delete it — archive it, and remove it from bookmarks, sidebars, and onboarding docs so nobody drifts back.
  5. Move to the next workflow.

Each cycle takes a few weeks and carries almost no risk, because at any point exactly one system is live and the fallback still exists. A full consolidation across five or six workflows typically lands in a quarter, and most teams notice the difference well before it’s finished.

The mistakes that undo the whole exercise

We’ve watched agencies run a solid audit and still end up back where they started. It’s almost always one of these:

  • Killing the duplicate without solving its reason. The spreadsheet comes back with a new name within weeks.
  • Choosing the system of record by license cost instead of by where the team works. Adoption beats features; an unused system of record is just another duplicate.
  • Skipping the parallel-run period. Cutting over in a day feels decisive, but the first missing field sends everyone scrambling back to the old copy — and now you have three systems again.
  • Not assigning an owner per workflow. Every system of record needs one named person who’s accountable for it staying accurate. “Everyone owns it” is how the drift started in the first place.
  • Auditing once and never again. Duplication is entropy; it re-accumulates. Put a one-hour version of this audit on the calendar every six months.

Where to start this week

You don’t need the half-day session to get moving. Pick the one question your team asks most often in chat — usually “what’s the status of [client]?” or “where is [deal] in the pipeline?” — and trace every place that answer currently lives. That single workflow is your first audit, and consolidating it will teach you more about your stack than any tool comparison ever will. If the answer turns out to be scattered across three systems, you’ve just found your first candidate for a single system of record.