Investors hear the phrase and picture a binder nobody opens. That version is real and it is not what this is for.
A standard operating procedure is the answer to a question someone would otherwise have to ask you. Written once, it stops being a question forever, and that is the entire value.
Why This Comes Before Hiring
Documentation is the unglamorous prerequisite for everything in scaling a real estate investing business.
The order investors get wrong: hire someone, then attempt to explain the work.
What happens is that you explain it three times, slightly differently each time, correct the output twice, and conclude the person is not working out. Frequently they were fine and there were no instructions.
Documentation converts a hire from a gamble into an onboarding. It also does something less obvious: writing a process down forces you to notice that you do it inconsistently, which is usually true and is worth knowing before someone else inherits the inconsistency.
The practical rule: if a task is going to be handed over, the procedure exists before the person does, per hiring a virtual assistant.
What Deserves One
Not everything. The test is whether the task is repetitive, whether being wrong costs something, and whether more than one person will ever do it.
Lead intake. What happens in the first hour after a lead arrives, who does it, and what gets recorded.
Skip tracing and list preparation. Highly rule-based and highly error-prone.
Mail campaigns. What goes out, to whom, on what schedule, and how responses get logged.
The first call. Not a script exactly, but what gets asked and what gets recorded, worked through in pre-qualifying before the appointment.
Contract to closing. The sequence: title ordered, deposit sent, inspection period dates, who is notified when. This is where deals die from omission rather than from anything dramatic.
Disposition. How a property gets packaged and who it goes to first, detailed in the guide to disposition.
Buyer onboarding. What a new buyer receives and what gets captured.
What Does Not Deserve One
Judgment work resists documentation and attempting it produces something misleading.
You cannot write a procedure for deciding whether a seller is telling you everything, or for how far to push on a number. Those are calibrated by experience and by feedback rather than by rules.
What you can document about judgment work is the inputs and the guardrails. Not how to decide the offer, but what information must be gathered before deciding, and what the limits are that require a conversation with you.
The distinction matters because investors either document nothing, or attempt to write rules for everything and produce a document that is wrong in every unusual case, which is most cases.
The Format That Gets Used
Short, specific, and stored where the work happens.
One task per document. A procedure covering seven things gets read by nobody.
Numbered steps in the order they occur, written as instructions rather than as description. Open this, click that, record it here.
Screenshots or a screen recording for anything involving software. A two-minute recording replaces a page of text and is faster to make.
A line at the top saying what this produces and roughly how long it takes, so the person knows what finished looks like.
And an explicit note about what to do when something does not match the procedure, which is the step that separates a usable document from one that produces silent errors.
The Fastest Way to Write Them
Not by sitting down to write documentation, which never happens.
Record your screen while you do the task and narrate what you are doing and why. Fifteen minutes of that is a complete procedure and it costs you only the narration, since you were doing the task anyway.
Then have whoever learns it write the text version from your recording. Their version is better, because they are recording the steps as encountered rather than as recalled, and writing it down is how the learning happens.
That approach produces documentation as a side effect of work rather than as a project, and that is the only version that gets done.
Keeping Them Current
The failure mode: a procedure written eighteen months ago describing software you no longer use.
Out-of-date documentation is worse than none, because someone follows it and produces a wrong result confidently.
Two habits prevent it. Whoever finds a procedure wrong fixes it in the moment rather than reporting it, which requires giving people edit access and telling them explicitly that this is expected. And a review of the handful of critical procedures once or twice a year, meaning the ones where being wrong costs a deal.
Put a last-reviewed date at the top. It is a small thing and it tells the reader how much to trust what follows.
Where to Keep Them
Somewhere a person can find the right one in under a minute, from a phone.
The specific tool matters far less than that everyone uses the same one and that it is searchable. A shared document folder works. So does a simple internal wiki.
What does not work is procedures living in someone's email, in a chat history, or in a document on your laptop. The test is whether a new person could find the intake procedure without asking anyone, and if they cannot, the storage has failed regardless of how good the writing is.
Link the relevant procedure from where the work happens where you can, so the person doing lead intake sees the intake procedure rather than having to go looking for it.
Who Should Write Them
Not you, past the first few.
The investor writing every procedure is a bottleneck, and the documents are worse than they would be otherwise, because you have done the task so many times that you skip the parts you no longer notice.
The person learning the task writes the best version. They hit every ambiguity in real time and they write down the answer, including the small things an experienced person omits without realizing.
Your job is to review it once and correct anything wrong, which takes ten minutes rather than an hour of writing.
This also has a management benefit. Asking someone to document what they learned confirms they understood it, and the gaps in their document are exactly the gaps in their understanding, which is a better training signal than asking whether they have questions.
What This Actually Buys
Three things, and only the first is obvious.
Faster onboarding. The next person learns from documents rather than from your time.
Consistency. Work happens the same way whether you are watching or on vacation, the difference between a business and a job.
Improvement becomes possible. A process that exists only in several heads cannot be improved deliberately, because there is nothing to change. Written down, you can change one step and see what happens.
That third one is underrated, which is why documentation matters even for a solo investor with no team. Writing down how you handle lead intake is what lets you notice that intake takes four hours and should take one.
The Checklist Version
For anything sequential with a deadline, a checklist beats a procedure and investors reach for the wrong one.
A procedure explains how to do something. A checklist confirms that steps happened. Contract to closing is a checklist problem, because the steps are known and the failure is omission rather than incompetence.
What belongs on it: title ordered, deposit sent and confirmed received, inspection period end date recorded, seller notified of the schedule, buyer under contract, closing date confirmed with all parties, and a final check the week before.
Each item with a date and an owner. The value is entirely in the dates, because the deals that die quietly die from something that was supposed to happen on a Tuesday and did not, per title problems that kill wholesale deals.
Keep it in the same place as the deal record rather than in a separate system, since a checklist nobody opens is worse than none.
Starting Without Making It a Project
The realistic path for someone with none of this.
Pick the single task you most want to stop doing. Record yourself doing it once. That is procedure number one, and it took no additional time.
Add one a week. In three months you have a dozen, covering most of what is repetitive in the business.
Resist the urge to design a system first. Investors spend a weekend choosing a tool and structuring a hierarchy, and write nothing. Twelve rough documents in a shared folder beat a well-organized empty wiki, and the structure can come later once there is something to organize.