A knowledge base people use
In 2020 our processes lived in people's heads and scattered documents. I moved the company onto a single knowledge base, wrote the standard for how guides are written, and authored most of what's in it, then, six years later, audited it and changed how it stays current.
The problem
New hires learned by asking. Every process change meant tracking down whoever knew it, and the answer depended on who you asked.
Constraints
No dedicated writer
Documentation had to happen alongside the work.
Constant change
Processes changed often, so docs went stale fast.
Public too
Some guides had to be published for tenants and owners.
Key decisions
Write the standard first.
I wrote a house guide on how to write guides, so anyone could contribute in the same shape.
Link, don't repeat.
A glossary-linking convention means a term is defined once and linked everywhere.
Audit, don't rewrite.
In 2026 an audit showed 90% of guides were unverified. Rather than a rewrite, I proposed a review owner for each guide.
How it works
Sample guides
Two examples written for this portfolio, not copied from the company. The first is the house standard every guide follows. The second is an SOP written with it, so you can see the standard and the result side by side.
How to write a guide
Purpose
So anyone can write a guide that the next person can follow without having to ask.
Steps
- Name it as a task. Start the title with "How to…" so search finds it and the reader knows what they'll be able to do.
- Fill in the header: owner, last verified date, review cycle and who it applies to.Why: a guide without an owner is the one that goes stale first.
- Write one sentence of purpose that explains why the process exists.
- Write the steps as numbered actions, one action per step, each starting with a verb. Add a screenshot or a short video where a step is hard to describe in words.
- Link terms instead of defining them again. The first time a term like move-out inspection appears, link it to the glossary.Why: when a definition changes, it changes in one place.
- Add a "Why" note under any step that looks optional. That's the step people skip.
- Test it. Ask someone who hasn't done the task to follow the guide, fix wherever they got stuck, and then set the verified date.
Done when: someone new can complete the task using only this guide.
How to handle an after-hours maintenance call
Purpose
So every after-hours call is handled the same way: emergencies get help quickly, and everything else is logged for the morning team.
Steps
- Get the basics: the resident's name, address and unit, a callback number, what's happening and when it started.
- Decide whether it's an emergency: a risk to people or serious damage to the property, such as no heat in freezing weather, an active water leak or no power to the unit.Why: the definition lives in the glossary, so everyone on call uses the same one.
- If there's a gas smell or immediate danger, tell the resident to leave and call 911 or the gas company first.
- For an emergency, dispatch the on-call vendor for that trade from the vendor list, and confirm an arrival time with the resident.
- For anything else, tell the resident what happens next and when, for example "We'll schedule this first thing tomorrow morning."
- Log the call as a maintenance request before the end of your shift: what was reported, what you decided and who you called.Why: the morning team picks up from the log, not from memory.
- If no vendor can come, call the on-call manager.
Done when: the resident knows what happens next, and the request is logged with the decision.
Outcome
- Grew to 545 guides across maintenance, technology, leasing, accounting, utilities and onboarding; I authored 350.
- Public owner and tenant guides were published to the website.
- The 2026 audit turned "the AI is inaccurate" into a fixable documentation problem.
What I'd do differently
- Build ownership and review dates in from day one. Docs need a maintenance plan, not just authors.