S5 · Maintaining Inherited Workbooks

(paid-course opener: orient → stakes → in) Okay, this video is about the tables you didn't build and can't delete. Here's the situation, and if it hasn't happened to you yet, it will. A vendor offboards, or a colleague leaves, or you simply take over a workspace. And their tables don't stop. They keep running, keep enriching, keep writing into your CRM every single day, built by someone who no longer answers messages. Most teams handle this with hope. They just don't touch anything and hope it keeps working. Hope is not a maintenance plan. This video gives you the actual one: what to demand in any handover, who owns what, the checks that catch decay early, and how to change a live table without breaking it.

The best maintenance starts before the builder leaves. Whenever anyone hands you a workspace, a vendor at contract end, a teammate changing roles, you are owed four things, and you should refuse to call the handover complete without them:

  THE HANDOVER — four things you are owed
  1 · A TABLE INVENTORY   every live table: what it does, in one sentence each
  2 · THE FLOW MAP        what feeds what: sources → tables → CRM fields
  3 · THE CREDIT PROFILE  what each table spends per month, roughly
  4 · THE FAILURE NOTES   what breaks, how often, and what they did about it

One, a table inventory, every live table with one sentence of purpose. Two, the flow map, what feeds what, from sources through tables into CRM fields. Three, the credit profile, what each table roughly spends per month, because you're inheriting a bill, not just a build. And four, the failure notes, what breaks and what the fix was, because everything breaks eventually and the builder already knows how.

If you're inheriting without a handover, no vendor, no notes, the person's just gone, then you build these four yourself, and the fifteen-minute review from the last video is exactly how: one table at a time.

Next, the rule that prevents the whole problem from recurring: every live table has a named owner. Not a team. A name.

  THE OWNERSHIP MAP · one row per live table
  TABLE                        OWNER    PURPOSE            FEEDS        CADENCE
  Companies · TAM · LIVE       Sarah    account universe   CRM fields   weekly
  People · inbound · LIVE      Marcus   speed-to-lead      CRM + Slack  continuous
  Companies · signals · LIVE   Sarah    funding triggers   sequencer    daily

One row per live table: owner, purpose, what it feeds, how often it runs. This map is thirty minutes of work and it's the single document that turns an inherited mystery into a managed system. An unowned table is an unwatched table, and you know from the governance video what unwatched tables do. When someone leaves, their rows get reassigned the same week. That's the whole policy.

Then the rhythm. Two checks, and they're short.

Weekly, five minutes: did every live table run on schedule, and does spend match its budget? You already do the Friday credit check from the governance video; this rides along with it. You're looking for the two failure smells: a table that stopped running, and a table that suddenly ran a lot.

Monthly, thirty minutes: data quality drift. Sample ten recent rows per critical table and read them like a human. Providers change, source pages change, prompts rot. A waterfall that filled ninety percent of emails in March can quietly drop to sixty by June, and no dashboard tells you. Reading ten rows does.

And finally, the scariest moment: you need to change a table that's live, feeding the CRM, built by somebody else. The procedure is four steps, and the first one is the rule:

  SAFE CHANGE · never edit live
  1 · DUPLICATE the table · work on the copy
  2 · TEST on 10 rows · verify outputs by hand
  3 · SWAP during quiet hours · pause the original, point the copy
  4 · WATCH the first full run · then archive the original (never delete it)

Duplicate first, always. The copy is where you work. Test on ten rows and verify the outputs by hand, exactly like the audit taught you. Swap during quiet hours, pause the original, promote the copy. And watch the first full run before you walk away. The original gets archived, never deleted, because it's your rollback and your reference. This procedure feels slow the first time. It's a lot faster than explaining to RevOps why the CRM filled with garbage overnight.

Here's a quick recap of what we learned in this video.

One: hope is not a maintenance plan. Inherited tables keep writing into your CRM whether or not anyone understands them, so somebody has to.

Two: the four handover demands, inventory, flow map, credit profile, failure notes. No handover? Build them yourself with the fifteen-minute review.

Three: every live table gets a named owner, one map, one row per table, reassigned the same week anyone leaves. And the cadence: five minutes weekly on runs and spend, thirty minutes monthly reading real rows for drift.

Four: never edit live. Duplicate, test on ten, swap quiet, watch the first run.

The Maintenance Protocol is under this video: the handover demands, both checklists, and the safe-change card.

Your exercise is under this video, and it's not scored. Two parts. Write the ownership map for your own workspace, every live table, one row each. Then run one maintenance pass: the five-minute weekly check plus ten sampled rows on your most important table. An hour total, and you'll know whether you're managing your workspace or just hoping at it.

Next up: the right feature for the right problem. Why most Clay waste is the expensive tool doing a free tool's job, and the decision tree that stops it.