From Audit to Action: Why Every Audit We Deliver Becomes a Basecamp Task List

Effective November 3, 2026, every finding in our marketing audits becomes a task. Not a chapter in a PDF — a task in the client’s own Basecamp project. Each one has an owner, a due date, and a check that proves it got done.

This page gives the rule and the steps to copy. It builds on our full guides to how we audit and to Metrics, Analysis, Action — MAA for short: measure what happened, work out why, then act on it.

The failure: a great PDF, and then nothing happens

For years, our audits ended the way most audits end. We did the deep work — the evidence, the scoring, the 20-page report — and the report closed with a plan: a chapter of recommended actions, written in prose. Then we handed over the PDF.

Here is what happens to that chapter. The client reads it, means to act on it, and hands it to whoever is nearby — a team member, a freelancer, or their own AI tool. Whoever picks it up does a partial job. They do the easy items and skip the hard ones. Nothing is distributed across a team, nothing is documented as it goes, and nobody checks the work at the end. Worst of all, nobody re-measures. The audit was a snapshot that led to a shrug.

The report was not the problem. The report was good. The problem was that “the plan” existed only as words at the back of a document, and words in a document have no owner, no date, and no proof.

The principle: Action is not a chapter. Action is a task list.

We teach MAA — Metrics, Analysis, Action. Most teams quietly stop after the second letter. They measure, they analyze, and then the Action is a paragraph in a report or a line in a meeting. That is not action. That is a description of action.

So here is the rule, in the words I used when I set it for our team on November 3, 2026: “Why don’t we go ahead and assign those tasks inside a Basecamp project for that client? That way every Basecamp task has an owner (which would be the agent), a due date, and the specifics of that task. Of course that ties to one of the tasks in our task library, which defines exactly how that task is done, how we validate it, and so forth…”

That is now the standard. An audit is not done when it is sent. It is not done when it is filed. It is done when its plan is running as owned tasks, and a re-audit has measured what those tasks changed.

Audit to Action is the practice of converting every finding in an audit into an owned, dated, validated task in the client’s own project — plumbing first, decisions listed separately — and then re-auditing the result at 30, 60, and 90 days.

How one finding becomes one task

Our audit standard already required every audit to ship as a package, not a lone PDF — and one file in that package is the action register: every recommended action, owned and dated, with an acceptance test. The register existed. What was missing was the register living where the work happens.

Now each register item becomes one to-do in the client’s existing Basecamp project — never a new, parallel project — in a list named for the audit: Audit Execution — <audit name/date>, the same name every time. Every to-do carries the same six parts:

1. Task Library slug (its slug — the library’s short ID for that recipe). Our Task Library registry holds 288 tasks, keyed by slug. A slug names the standard way that task is done and the check that proves it, so any worker — human or agent — follows the same standard. The to-do carries its slug in its description. Where no slug matches, the to-do is marked NEW-SLUG-CANDIDATE, and writing that task’s definition is part of the job — so the library grows from real work, and a registry count is never dressed up as proof a recipe was run.
2. Owner. The owner is the agent or team member who will actually execute it. Basecamp assigns to-dos to people, so the assignee is the person or seat accountable for that lane, and the executing agent is named in the to-do itself. The trail then shows both: who answers for the task, and which agent did the work. Decisions that are mine alone are never disguised as tasks — they are listed separately, as decisions (you will see this in the real example below).
3. Due date. Tasks are sequenced, not dumped: plumbing and quick wins in week one, fixes in weeks one and two, build work in weeks three to six, and re-audit checkpoints at days 30, 60, and 90.
4. Specifics. The exact steps from the finding, the destination they apply to — the page, the listing, the account — and the audit finding they came from.
5. Validation. “Done” means evidence, read back where the work lives: the live page, the listing state, the tracking record. That evidence link goes in a comment on the to-do. A comment that says “done” is not proof.
6. Business metric. Every task names the business result it feeds, in this order: profit first, then revenue, then leads, then traffic, then rankings. Rankings and traffic are signs along the way. Revenue and profit are the destination. A task that cannot name its business metric gets re-scoped or cut.

One real to-do, filled in. From the Sean Kelly register (below), task 1 of 31: “Build guest-revenue attribution plumbing.” The finding behind it: guest revenue could not be traced to any guest or episode, because no enquiry or checkout path carried source tagging. Slug: digital-plumbing-attribution — a NEW-SLUG-CANDIDATE; writing its recipe is part of the job. Owner: Happy, the Muse agent running this program — assigned in Basecamp to the seat accountable for that lane, with Happy named in the to-do. Due date: November 12, 2026. Specifics: add UTM and source tagging — episode number, guest, and cohort — across the episode pages on seankelly.io, the /apply page on digitalsocialhour.com, and every package and micro-package checkout and enquiry path, so a sale traces back to the guest and episode that caused it. Validation: a test enquiry and a test transaction, read back with the right guest and episode showing in the analytics and the CRM; the screenshot and event log are filed to the program folder. Business metric: revenue — and until this task passes, no revenue claim for this program is allowed at all.

Task Group Zero: tracking and attribution go first

Before any content or ranking task counts, the first group of tasks is always the digital plumbing: call and form tracking, conversion events on the site and in ads, lead sources captured in the CRM (the system that holds the lead and customer records), and a path that ties a lead to a sale, so revenue can be attributed instead of guessed.

Plumbing week also files a dated baseline: the numbers as they stand on day one, saved inside the task list. That baseline is what the re-audit compares against. Without it, a later claim like “traffic is up” floats in the air. With it, the claim has a before, an after, and a source.

The rule is short: no plumbing, no performance claim. If the tracking is not in place, we report rankings and traffic as what they are — diagnostics — and never dress them up as results.

Who does the work: deep analysis once, agent execution at volume

This structure is what lets AI do the bulk of the work without the work going soft. The deep thinking — the audit itself, the analysis, the ranking of what matters, and the final quality check — is done as one deep, senior pass. The execution is then broken into to-dos that are each a complete work order: a recipe slug, the specifics, and the check that proves it. Work written that clearly can be executed at volume by our Muse agent fleet, and — this is the point — it can be audited by other agents, because every claim of “done” points at evidence at the destination. In the Sean Kelly register the split is literal: the census and the register were reasoned once, and the 31 to-dos are divided across the Muse fleet, a publisher agent, and one human reviewer — with the same agent who built the register QA-ing the evidence as it lands.

That paper trail is what a PDF handed to a chatbot can never give you. The work is distributed, documented, and seen all the way through, in the client’s own project, where the client can watch it happen.

A real register: Sean Kelly and Digital Social Hour

The first full register converted under this rule did not come from a fresh audit. It came from a program already running: the guest entity program for Sean Kelly, host of the Digital Social Hour podcast. An entity layer is the set of records search engines and AI systems use to know who a guest is — and it is the asset the show sells to future guests. The program’s census of the show’s guest entity records covered 2,272 episode rows and 1,784 distinct guests. It found 1,131 of those guests — 63% — had no entity layer at all — no Wikidata item, no Wikipedia article, no verified Grokipedia page, no documented Knowledge Graph ID: nothing for a search engine or an AI to hold onto. Along the way, 135 Wikidata statements and 5 label repairs were already executed and verified through the API, two items were created, and one duplicate was merged — before this register was even written.

On November 3, 2026, that program’s remaining work was converted into a register: 31 execution tasks, in six groups — 3 plumbing tasks, 7 for Sean’s own site and entity, 7 to close out the guest entity fixes, 6 for the guest revenue engine, 5 for the episode and transcript loop, and 3 for the re-audits and documentation. Every task has an owner, a due date, a validation check, and a business metric. Nine of the 31 had no matching recipe in the library yet. Those were marked NEW-SLUG-CANDIDATE, and defining them is part of the work — the library grows from real jobs, not from a planning exercise. And 7 decisions were kept out of the task list entirely, listed separately as mine to make — because an agent executing a decision nobody made is how programs go wrong.

Where it stands today: posted and verified. Sean’s register is live in his Basecamp project — 25 execution tasks read back on the list, with the 7 decisions on their own list beside it. The first audit registers lead the rollout: Funds2Orgs, Wayne Elsey’s shoe-drive fundraising company, is live with 44 tasks, and Rowan Appliance with 40 — completed audits for paying clients, converted under the same rule. From there the system runs across every active client and every past audit in our library — paying clients first. A register for a prospect who is not yet a client gets prepared, and its posting waits until they are one.

The loop closes: measure again at 30, 60, and 90 days

A task list that never gets re-measured is just a tidier PDF. So each register ends with re-audits at 30, 60, and 90 days. The re-audit re-scores the original audit, compares the new numbers against the dated baseline from plumbing week, and reports in the only order that matters: profit, revenue, leads, traffic, rankings. What the re-audit finds becomes the next list of tasks. Metrics to Analysis to Action, and back to Metrics. The loop, not the PDF, is the product.

The recipe, so your team can run it too

Trigger: an audit is delivered and its action register is final. Who runs it: the audit’s lead agent, in the same working session — conversion is part of delivering the audit, not a later favor.

Inputs: the audit package (report, evidence ledger, action register), the Task Library registry, and access to the client’s existing Basecamp project. If the client has no project yet, creating it is step zero — the tasks still never live in a parallel project of ours. If the subject is a prospect, not a client, the register is prepared and its posting waits (see the Sean Kelly section).

Steps, in order:

1. Write the plumbing tasks and the dated baseline first.
2. Convert each register item into one to-do with the six parts above.
3. Move anything that needs the owner’s judgment into a separate decisions list.
4. Execute group by group, in the order above, attaching destination evidence to each to-do as it completes.
5. Read the list state in the weekly MAA — the list is the status report.
6. Re-audit at 30, 60, and 90 days and spawn the next list from the findings.

Decisions inside the steps: a task that cannot name its business metric is re-scoped or cut (step 2). A task with no matching slug becomes a NEW-SLUG-CANDIDATE and its definition is written as part of the job (step 2). Anything that needs the owner’s judgment leaves the list at step 3 — it is never assigned to an agent as if it were execution.

The template we use — copy it:

Pass: every register item exists as a to-do with all six parts; every completed to-do carries evidence read back at the destination; the re-audit is filed against the baseline. Fail: a plan that lives only in the PDF, a “done” with no evidence link, or a performance claim made before the plumbing was verified.

Handoff: the completed list and its re-audits stay in the client’s project, and the lessons feed back into the Task Library recipes and into how we audit, so the next audit starts from a better standard than the last one.

Where it belongs: this recipe’s Task Library registration is a new-slug candidate (audit-to-basecamp-register-instantiation); its parents are How We Audit and MAA, linked at the top of this page.

Two doors

Door one: we run it for you. Audits, task execution, and re-audits are the work our team and agent fleet do for clients every week. Start with an audit at Local Service Spotlight.

Door two: run it yourself. Everything on this page is a recipe you can copy: build the register, give every item the six parts, do the plumbing first, and re-audit on the loop. The two guides this page sits under — How We Audit and MAA — give you the audit standard and the weekly loop that keeps the list honest.

Run record: execution AUDIT-TO-ACTION-20261103, run November 3, 2026 by the agent fleet under Dennis Yu. Sources: the Audit → Basecamp Execution System memo (November 3, 2026) and the Sean Kelly / Digital Social Hour action register (November 3, 2026). Status: published November 3, 2026; updated November 3, 2026. Run cost, time, and token figures for this run were not metered — UNKNOWN, not zero. This page was written to our article guidelines. No business results are claimed in this article, because none have been measured yet under this system — the first re-audits will supply them, and this page will be updated when they do.