There is a question that information technology (IT) teams ask to stress-test their own continuity, and it is blunt on purpose: if this person were hit by a bus tomorrow, could the work carry on? The number of people a team could lose before the work stalls is called the bus factor, and in small-organization web management the most common finding is a bus factor of one. One person knows where the domain is registered, which card pays for hosting, and how to get into the email platform. Everyone else knows that person's extension.
The question sounds morbid and almost never plays out that way. The ordinary versions happen constantly: people change jobs, take leave, and go on vacations where they would rather not answer texts about DNS. The purpose of this post is to make the case for the single page that raises the bus factor above one, to say what belongs on it, and to be clear about the one thing that must never be written on it.
Why the inventory alone is not enough
Yesterday's post covered the full web account inventory, the register of everything the organization owns, rents, or depends on online. That workbook protects the organization from forgotten accounts. It does not, by itself, protect the organization from losing you, because a successor who has never seen the workbook does not know it exists, where it lives, or how to open the vault it points to.
The inventory is the map. The one-pager is the note that says where the map is kept. A successor holding that note can reconstruct everything else in an afternoon; a successor without it starts the discovery hunt from zero, during whatever crisis prompted the handoff.
What goes on the page
The minimum viable version fits on one page, and I recommend writing that version this week rather than planning a fuller one for someday. It names six things.
The location of the inventory workbook. The location of the password vault. The two people, besides you, who hold emergency access to that vault. The five most critical renewal dates, usually the primary domain, the hosting, the email platform, and whatever two services the mission would miss first. The key vendors, with one contact name and address for each. And the organization's primary domain with its registrar.
That is all. Date the page at the top, add a next-review date beside it, and stop. The gold standard grows from the same page into a small operations folder: the workbook, vendor contracts, a running decisions log, and short screen-recorded walkthroughs of anything you had to learn the hard way. Build toward that without waiting for it. The one-pager this week beats the operations manual next year.
What must never go on it
The page points to the vault. It never duplicates what the vault holds.
A succession document with passwords written into it becomes the least protected copy of your most sensitive information, sitting in a shared drive precisely so that it is easy to find. The same rule covers two-factor backup codes and payment card numbers. If the separation feels indirect, that is the design working: the file can be widely findable because it contains directions, and the vault can be tightly controlled because it contains keys. A page anyone in the building could read should be safe for anyone in the building to read.
The sealed-envelope problem
Documentation has a classic failure, and estate lawyers have a name for it. A document nobody knows exists, or nobody can reach, protects no one. A beautifully written hit-by-a-bus file on your personal laptop is a diary.
Three recommendations close that gap. The file lives in organizational storage, not a personal drive or a personal account. Two named people beyond you know exactly where it is, and have confirmed they can open it. And its location is recorded somewhere leadership already looks, such as the board minutes or the employee handbook, so that the knowledge of the file survives even the people who know about the file.
Then put a quarterly review on the calendar and update the version date each time. A successor should be able to see at a glance how fresh the map is, and a page dated eighteen months ago tells its own story.
The honest objection
Some readers will feel that writing this page is planning for their own irrelevance, and the feeling deserves a straight answer rather than reassurance. Continuity is one third of the actual job. Risk reduction and improvement are the other two, and neither of those survives a handoff without this page. The organizations that treat a departure as a farewell lunch and a forwarding address are the ones that later discover a former employee still holding administrator access two years on, or a domain registered to a personal address that stopped being read.
Writing the page is one of the most professional acts a web manager performs, precisely because nobody will applaud until the day it is needed. It also pays off sooner than the bad day. The first time you take a real vacation and nobody texts you about the website, the page did that.
Do this week
Open the template, fill in the six items from memory and from the inventory, and date it. Save it to organizational storage. Tell two people where it is, and watch them open it. Add a quarterly reminder. That is under an hour, and it is the single largest improvement in continuity most small organizations can make this month.
Get the template. The M2.2 "Hit by a Bus" One-Pager is a fill-in page covering the six items above, with a version date and a next-review date at the top. It comes with the Web Account Inventory Workbook, free with a free account, along with the weekly Web Managers letter. The full argument is Chapter 2 of Strategic Web Management.