Every operator has a Dana.
Dana knows that unit 14's lockbox sticks, that the Hendersons want a call and not an email, that the pool guy comes Tuesdays but bills monthly, and that you never, ever put a big group in the duplex during soccer season.
None of that is written down. All of it is load-bearing.
Dana isn't the problem. Dana is excellent. The problem is that your operation has a single point of failure with a personality, a vacation balance, and a LinkedIn profile.
The tell isn't the crisis, it's the quiet stuff
You don't discover key-person risk when someone quits. You discover it in small moments that everyone has learned to work around.
Someone asks a simple question and the answer is "ask Dana."
A new hire is three weeks in and still can't complete a normal task without a check-in.
Dana takes a week off, and the week gets rescheduled around it, or Dana answers texts from the beach because it's easier than explaining.
An owner calls with a question about a two-year-old repair, and the only record is in an email thread on one person's account.
Every one of those is the same disease: the operation runs on memory instead of on a record.
Three kinds of knowledge, three different fixes
Lumping all tribal knowledge together is why documentation projects die. Split it up.
Property facts. The lockbox that sticks, the water shutoff behind the dryer, the trash pickup day, the neighbor who calls the city about parking. This is data, and it belongs attached to the property, not in a binder or a person. If someone can't find it while standing in the driveway on their phone, it doesn't exist.
Process. How a same-day turn gets sequenced, what happens when a guest reports no hot water, who approves a refund over $200, how an owner statement gets built. This is workflow, and the best documentation for a process is the process itself, enforced by the system that runs it. A checklist someone has to remember to open is a wish. A required step in the workflow is a standard.
Relationships and judgment. Which owner wants a phone call, which one reads every line, which guest is a repeat that deserves the benefit of the doubt. This is the part people think can't be captured. Most of it can, as notes on the owner or guest record, written in plain language. Not all of it, and that's fine. The goal is to shrink the irreplaceable part, not eliminate it.
The mistake is treating all three as a writing project. Property facts are a data entry project. Process is a system configuration project. Only relationships and judgment are actually a writing project, and it's the smallest of the three.
Ramp time is your real measure
Forget documentation coverage. It's unmeasurable and everyone lies about it.
Measure ramp: how long from a new coordinator's first day until they can handle an ordinary day without asking a teammate a question they could have looked up.
Most operations are at six to twelve weeks and think that's normal. It isn't. It's the interest payment on undocumented knowledge, and you pay it every time anyone leaves, gets promoted, or goes on leave.
Two things drive ramp more than anything else: how many separate tools someone has to learn, and how much of the answer lives in a person versus a screen. Six tools with four logins means six mental models, six sets of permissions, and six places to look before asking Dana. That's why consolidating tools shortens ramp even when nothing else changes.
The two-week extraction
You don't need a documentation initiative. You need two weeks of disciplined capture, done while the work happens.
- Log every question for one week. Every time anyone asks anyone else something they could not look up, write it down. One line, no analysis. By Friday you'll have your curriculum, and it will be shorter and dumber than you expected. It's rarely strategy. It's gate codes and approval thresholds.
- Sort the log into the three buckets. Property facts, process, relationships. Count them. The mix tells you where to spend the second week.
- Put property facts where the work happens. Not a shared drive. On the property record, in the system your team already has open, so it surfaces in the context of a task. If it lives in a document, budget for the version where two documents disagree.
- Turn the top five recurring processes into enforced steps. Pick the five most-asked process questions and make the system carry them: required fields, assigned owners, approval steps, templates for the guest and owner messages people currently write from scratch. A process that's enforced doesn't need to be remembered.
- Have Dana narrate, not write. Nobody documents their own expertise well, because the obvious parts are invisible to them. Sit a newer teammate next to Dana for four hours, have them ask why after every step, and have the newer person write it. You'll capture the reasoning instead of the summary, and you'll find the two or three places where Dana's method should become everyone's.
- Then test it. Have the newest person on the team run a real day using only the record. Every time they get stuck, that's a gap, and it's a specific gap you can fix in ten minutes. Documentation that hasn't been tested by someone who doesn't know the answer is fiction.
Two weeks of that beats a year of intending to write a manual.
Redundancy is a design choice, not a headcount problem
Small teams assume redundancy requires hiring. It usually requires rotation.
Rotate who handles owner statements. Rotate who runs the Saturday turn board. Rotate who's on guest escalations. Nobody has to be great at everything, but two people should be adequate at each thing, and adequate is achievable in a week when the record is good.
The side effect is better process. Nothing exposes a broken workflow faster than making a second person run it.
And keep the record honest by keeping it in one place. A property record, an owner record, a guest record, a work order history. When the facts live with the object they describe, documentation stops being a project and becomes a byproduct of doing the work.
What it feels like when it's fixed
Dana takes a real vacation. Not a phone-in-the-bag vacation.
A new coordinator handles a normal Tuesday in week two, and their questions are good ones about judgment instead of gate codes.
An owner asks about a repair from eighteen months ago and gets an answer in a minute, with photos, because the history lives on the unit and not in an inbox.
You stop being nervous when someone gives notice. That's the actual deliverable. Not a manual nobody reads, but an operation where the knowledge is in the operation.
Your best people should be irreplaceable because of their judgment, not because of what they remember.
Want your operational knowledge to live in your system instead of someone's head?
Take a look at Direct.
