After a container scan, there are two useful questions. "What's worst?" tells you where the risk lives. "What do I do first?" tells you where to start working. Those questions have different answers because severity and effort are independent axes. A critical consent misconfiguration might take ten minutes to fix (switching one tag's consent type from analytics_storage to ad_storage). A different critical consent finding might require rebuilding consent architecture across 30 advertising tags, coordinating with a vCISO on compliance requirements, and looping in the web development team to update CMP integration. Same severity. Completely different scope.
TagManifest organizes its work plan by effort because that's the axis that produces action. Severity still matters for scoring functional health, and every finding carries a severity classification. But when you're sitting down to actually fix things, effort is what determines the order. The ten-minute fix happens today. The multi-team project goes on next quarter's roadmap. Sorting everything by severity alone puts both in the same "critical" bucket and doesn't help you figure out which one to pick up first.
Why severity and effort are different things
Severity measures consequence. How much does this finding cost you if you leave it alone? A consent violation that exposes you to regulatory risk is high severity. An orphaned trigger that clutters the container is low severity. That hierarchy is real and the functional health score reflects it.
Effort measures scope. How much work does the fix require, and who needs to be involved? Some high-severity findings are ten-minute fixes: delete a dead UA tag, switch a consent type, remove PII from a parameter. Others are projects that require coordination across teams. Rebuilding consent architecture might involve your CMP vendor, a privacy consultant or vCISO, and the web development team that manages tag deployment. Restructuring a data layer that four contributors built over three years requires developer time, QA in staging, and a phased rollout.
The Eisenhower Matrix separates importance from urgency for the same reason. MoSCoW accounts for feasibility alongside importance. A list sorted by one dimension (how bad is this?) isn't a plan. Adding the second dimension (how much work is this, and who needs to be in the room?) turns it into one.
Eight critical findings and fourteen warnings all labeled "high priority" doesn't help anyone figure out where to start. Research on decision-making confirms this: too many urgent items creates decision fatigue, and the typical response is inaction. People start with whatever feels most approachable, or they close the report entirely.
Four effort tiers for GTM cleanup
The work plan is organized by effort because that's how cleanup actually gets scoped. Not in theory. In practice, sitting across from someone who needs to fix their container and has a limited number of hours to do it.
Quick wins (under an hour). Findings you can resolve in a single sitting without touching anything structural. Delete dead tags firing into decommissioned properties. Remove orphaned triggers and variables left behind from previous implementations. Fix tag names that still say "Copy of GA4 Event" or "test_final_v2." None of these are glamorous. All of them reduce noise and make the next round of work easier to scope. Quick wins also build momentum. Shipping six fixes in an hour changes the psychology from "this is a mess" to "this is getting cleaner."
Focused remediation (a working session). These are findings that take a few hours of concentrated work. Reconfiguring consent types across a batch of advertising tags that are all gated behind the wrong consent signal. Standardizing event naming so your GA4 reports aren't splitting the same user action across three differently-named events. Reviewing Custom HTML tags to determine which are still necessary and which are leftover tracking scripts from a vendor relationship that ended two years ago. Each of these is a single work session, not a project, but they require enough context-switching and testing that they can't be knocked out in ten minutes between meetings.
Structural work (a project). These findings require planning, possibly coordination with other teams, and a dedicated block of time. Rebuilding trigger architecture so that related tags share common trigger groups instead of each having bespoke firing conditions. Implementing a consistent naming convention across a container with 80+ tags from four different contributor patterns. Cleaning up a data layer that has grown organically to include redundant variables, inconsistent key names, and values that nothing in GTM actually references anymore. Structural work usually can't be done in isolation because it touches enough of the container that changes cascade.
Strategic improvements (roadmap). These aren't findings that indicate something is wrong. They're opportunities that require organizational buy-in and planning beyond the container itself. Assessing readiness for server-side tagging migration, which involves infrastructure decisions, cost modeling, and stakeholder alignment. Redesigning consent architecture to move from a reactive CMP-bolted-on-later approach to a consent-first implementation where tag firing logic is built around consent states from the beginning. These items belong on a quarterly roadmap, not a Tuesday afternoon task list.
Combining severity and effort in the work plan
Every finding carries both a severity classification and an effort tier. Severity feeds the functional health score. Effort determines where the finding lands in the work plan. The combination is what makes the work plan useful:
- High severity, low effort: Fix today. Switch a consent type, delete a dead tag, remove PII from a parameter. These are the quick wins that improve your functional health score immediately.
- High severity, high effort: Plan and coordinate. Consent architecture redesign might need input from a vCISO or privacy consultant. Data layer restructuring requires developer time and staged QA. These go on the roadmap with clear ownership and timelines.
- Low severity, low effort: Clean up when convenient. Rename a tag, delete an orphaned variable, add a folder. Hygiene work that reduces noise.
- Low severity, high effort: Evaluate whether the payoff justifies the work. A full naming convention overhaul across 120 tags is a real project. It makes the container more maintainable, but it doesn't fix anything that's functionally wrong.
Severity tells you what matters. Effort tells you when to do it and who needs to be in the room.
Turning GTM audit findings into a work plan
"This tag has no consent configuration" is an observation. "Delete this tag, it fires into a decommissioned UA property and isn't sending data anywhere" is an action. The difference matters for what happens after the report gets read.
Each finding includes what was detected, why it matters, and what to do about it, grouped by how long the fix takes. The goal is a document you can hand to someone (or yourself, next Tuesday) and have them start working without re-diagnosing the problem. Gartner's IT operational frameworks draw a similar distinction: "run" (keep things working), "grow" (improve what exists), "transform" (change the approach). Quick wins and focused remediation keep the container running. Structural work improves it. Strategic improvements transform the approach.
First section of the work plan: what you can fix this afternoon. Last section: what goes on the roadmap for next quarter. Everything in between is scheduling and team coordination, not diagnosis.
The container is probably messy. The question after scanning it isn't just what's wrong, but what you're going to do about it, who needs to be involved, and in what order. Scan your container and the work plan breaks that down by effort tier so the answer is already scoped.