When you inherit work with no notes, the first thing to build is not a fix. It is a record of what you were handed. Without that record you cannot tell what you changed from what changed on its own, and you will redo work someone else already did.
I have taken over recurring work with no handover more than once. It never arrives as a tidy package. It arrives as a queue that is already moving, or a short screen recording and an old file. Both times, the useful first move was the same: slow down for one day and write down exactly what was there.
In one back office: the second first introduction
I stepped into several daily approval and exception queues at once. Each one had a list of open items. None of them came with a note of what had already been worked, and there was no list of who had already been contacted.
So I did the obvious thing. I worked the queues as I found them, and I wrote to the people on them. Some of those people had already heard from the team. They got a polite first-contact introduction for the second time, about an item they had already been asked about.
Nothing broke. But it looked careless, and it cost a little trust with people whose replies we needed. It also hid a real question: had their item been chased and ignored, or chased and fixed? Without a record, I could not say.
The fix was three small habits. A running contacted list, checked before any outreach. A saved copy of every queue, every day, exactly as the system showed it. And a rule that each new paste gets compared with the last saved copy before anything on it is called new.
That comparison sorts every row into one of four buckets. New: on today's list only. Carried: on both, unchanged. Updated: same item, changed detail. Resolved: gone since yesterday. Resolved is not the same as fixed. If I cannot find a row anymore, I record that it cleared, and then I check whether anyone actually fixed it.
On day one, save a copy of every queue you touch. On day two, compare. Everything you can explain later depends on that first copy.
On another team: a recording and an old file
Somewhere else, several weekly and monthly reports changed hands within a few weeks. Each one arrived the same way: a short screen recording of someone producing it, and the last file they sent.
The old files looked finished. They were not clean. One total pointed at a column that had since been deleted. One summary block had been copied from another account's report and never updated. A lookup returned an error on a few rows, and nobody had noticed because the error sat below the fold.
That left two bad options. Follow the old file exactly, and I would reproduce its errors with my name on them. Quietly fix what I found, and the owner would get a report that no longer matched last month's, with no explanation. Either way, the person who trusted the report would be surprised.
Two documents, not one
What worked was producing two documents for every inherited report, kept apart on purpose.
The first is the steps: the report as it was taught to me, written as literal actions with real file locations. Not "update the summary" but which file, which tab, which column, and where each number comes from. Every number the trainer typed by hand gets a note saying where it came from.
The second is the already-broken list: everything that was wrong before I touched it. Bad formulas, copied blocks, stale lookups, hand-typed figures with no source. I do not fix anything on that list yet. I write it down, and I show it to the owner.
Keeping them separate is the point. The steps describe the report I was handed. The broken list describes the gap between that report and a correct one. Mix them, and nobody can tell which changes were teaching and which were repairs.
How I run the takeover
The sequence is short, and I follow it in order:
- Collect every input: the recording, the last two finished outputs, the data source, the recipients, the due day.
- Watch the recording at slow speed and write each action as a step, with the real location.
- Run the report once on the newest data, following my steps exactly, even where I think they are wrong.
- Compare my run with the last finished output, line by line. For every difference, decide: did the data change, or was the old file wrong?
- Put every "old file was wrong" on the broken list. Fix none of it yet.
- Send the trainer three things: the finished run, the broken list, and a short set of questions.
The first run follows the old steps literally. Improvements come after, with approval. That feels slow, but it means the first report I send can be checked against the last one, and every difference has a reason next to it.
One more rule from that stretch: never invent a value to make a check pass. If a total does not tie out, the report says so. A file is not final while any lookup still shows an error.
Ask only the questions that change the output
When you inherit something, you will have dozens of questions. Most of them do not matter. The owner is busy, and a long list of questions reads as "I have not started yet".
So I sort them. A question goes to the owner only if its answer changes what the report says or who gets it. Cadence. Due day. Recipients. Whether a figure that looks wrong is actually wrong. Everything else becomes a labeled assumption written into the steps, such as: "Assumption: totals exclude test accounts, as in the last two reports."
The owner can read an assumption in two seconds and correct it if needed. That is much easier than answering a question cold.
What goes wrong
- Copying old errors forward. Caught by comparing your run with the old output line by line, not by eye.
- Silent fixes that surprise the owner. Caught by the separate broken list.
- Steps too vague to repeat. Caught by requiring a file, a tab and a column in every step.
- Comparing against the wrong day's copy. Check the date on the saved copy before you compare.
- A filtered view mistaken for the full queue. Always note which view you saved.
- Matching on a display name that varies. Match on an ID and a date wherever the system gives you one.
Last, create the recurring task for the next run on the day the source data actually arrives, not the day the report is due. Then after the second run, update the steps with anything that changed. The second run is where vague steps show themselves.
For the daily comparison, I built a free queue diff: paste yesterday's list and today's, and it sorts every row into new, carried, updated and resolved before you work anything. The full method, with checklists for both the queue snapshot and the report takeover, is in The Takeover Playbook (PDF).
The takeaway
When work lands on you with no handover, your first job is a record, not a fix. Save a copy of every queue on day one and compare on day two. For every inherited report, write two documents: the steps, and what was already broken.
Then ask only the questions whose answers change the output. Everything you can explain to the owner later depends on what you wrote down in the first two days.
Write down what you were handed before you change it. The steps and the broken list are two documents, and they stay two.