Start with this one-week capture list
Do not begin with a blank document titled “My Real Estate SOPs.” Begin with work that actually reaches you. For one working week, add an item to this list whenever you repeat a task, give the same instruction, look for the same information, or check the same status.
- Emails that make you perform the same set of actions
- Phone calls that require the same questions or follow-up
- Instructions you repeatedly give an assistant, vendor, or team member
- Client messages that follow a familiar pattern
- Documents you repeatedly rename, file, forward, or review
- Transaction updates you request from the same parties
- Decisions that depend on the same few pieces of information
- Tasks you postpone because the next step is not immediately clear
- Work that returns to you after an incomplete handoff
Tom Ferry’s operational planning guidance names the client journey, daily routines, transaction workflows, support roles, checklists, and review habits as parts of an operating plan. You can use those areas as prompts, but your own week should determine what you document first.
Sort each item into one of three systems
Not every repeated task needs a long procedure. Match the document to the work. A short preference may be enough for a writing choice, while a transaction involving several people and waiting periods needs a process that preserves context over time.
| System type | Use it for | What to write |
|---|---|---|
| Preference | A consistent choice about how work should be handled | The preferred result, important boundaries, and an example |
| Routine | Work that begins when a recognizable email or phone call arrives | The trigger, checks, actions, exceptions, and stopping point |
| Longer process | Work that moves through several stages over days or weeks | The start, ordered stages, owners, inputs, handoffs, decisions, records, and completion condition |
A useful test is to ask what makes the work repeatable. If the repeated element is a choice, write a preference. If it is an incoming event, write a routine. If it is a sequence that must remain visible across multiple stages, write a longer process.
Write preferences for the small decisions you keep remaking
Preferences record how you want a task completed. They are useful for details that live in your head: tone, naming conventions, who should be copied, how updates should be organized, and which situations should come back to you for a decision.
- Name the task narrowly.
- State the result you want.
- List any limits that must be observed.
- Give one acceptable example.
- Name the situation that requires your review.
| Part | What to write |
|---|---|
| Result | Prepare a short, direct email that identifies the transaction and asks for the missing update. |
| Include | The property address, the item being requested, the date of the previous request if known, and a clear question. |
| Avoid | Promising a deadline or speaking for another party. |
| Bring it back to me when | The message involves a dispute, a change to an agreement, or a decision only I should make. |
| Example closing | “Please let me know the current status and whether you need anything further from our side.” |
Reddy lets a user explain in chat how a task should be handled, saves those directions as a playbook, and follows the playbook when that work appears again. The user can read and change saved playbooks in the Workspace.
Write routines for work that arrives by email or phone
A routine connects an identifiable trigger to a confirmed set of actions. It should be specific enough to start reliably and narrow enough to avoid treating every incoming message the same way.
- Trigger: Describe the email or call that starts the routine.
- Match check: List the details that confirm this is the right routine.
- Inputs: Identify the names, dates, documents, or contact details needed.
- Actions: Write the steps in order.
- Exceptions: List conditions that stop the routine or require your decision.
- Record: State where the message, notes, draft, or status belongs.
- Done: Define the observable point at which the routine is complete.
| Part | What to write |
|---|---|
| Trigger | A vendor calls about an active transaction. |
| Match check | Confirm the caller’s name, company, property address, and the party they represent. |
| Actions | 1. Record the caller’s update in plain language. 2. Note any request made of our side. 3. Identify any date the caller mentioned, without interpreting or changing it. 4. Prepare a short summary for my review. |
| Stop and ask me | If the caller requests a decision, approval, representation, or change in direction. |
| Done | The call record and review summary are saved with the correct transaction. |
Reddy routines can start when a new email arrives or a call comes in on the user’s Reddy line and matches a check the user confirmed. A routine can follow confirmed steps, but email is prepared only as a draft; Reddy does not send it.
Write longer processes around stages and handoffs
A transaction process is not simply a longer checklist. Some steps happen immediately, others wait on people or documents, and new information can change what happens next. Write the process so a reader can tell what stage the transaction is in, who has the next action, and what information is still missing.
- Define the start: Name the event or document that opens the process.
- Copy the controlling information: Record relevant names, dates, instructions, and terms from the actual transaction documents. Check them before relying on them.
- Create the stages: Group related actions under meaningful transaction milestones.
- Assign an owner: Name who performs each action or makes each decision.
- Define each handoff: State what is passed, to whom, through which channel, and how receipt is confirmed.
- Mark the waiting states: Record what you are waiting for and who currently has the next action.
- Add decision points: State the question to answer and who is authorized to answer it.
- Name the record: Identify where documents, communication, and status notes are kept.
- Define completion: State what must be true before the process can be closed.
Pay special attention to handoffs. “Send the document” describes an action. A complete handoff also identifies the recipient, the approved version, the delivery method, the confirmation to retain, and who follows up if confirmation does not arrive.
Use one-page system cards
Keep the first version compact. A system card should help someone perform the next real instance of the task. You can add detail after the system encounters an exception.
| Field | What to answer |
|---|---|
| System name | A short name for the task |
| Type | Preference / Routine / Longer process |
| Purpose | What result should this system produce? |
| Start | What event begins the work? |
| Inputs | What information or documents are required? |
| Steps | The steps, in order |
| Owner | Who performs the work? |
| Handoffs | What moves to whom, and how is receipt confirmed? |
| Decisions | What requires the agent or another named person? |
| Exceptions | When should the normal steps stop? |
| Record | Where are the work and its status saved? |
| Done | What observable condition closes the work? |
| Last reviewed | The date you last checked it against real work |
Use verbs that can be observed: confirm, record, compare, draft, request, save, and notify. Replace instructions such as “handle inspection” or “stay on top of the lender” with the actions, information, and decisions those phrases contain.
Test the system on live work
The first written version is a draft. Use it the next time the task appears, and mark every place where you have to rely on memory or interrupt the work to ask a question.
- Could you identify the correct system from the trigger alone?
- Were all required inputs available?
- Did each step name a clear action?
- Was the owner of every decision clear?
- Could you see when the work was waiting on someone else?
- Did each handoff specify what had to be delivered and confirmed?
- Did the system say where to save the result?
- Was the completion condition observable?
- Did an exception appear that should be added?
Update the system immediately after the test while the missing context is still clear. If one card becomes difficult to scan, split it into a core process and smaller preferences or routines that support it.
Choose the next system from your captured week
Return to your one-week list and choose an item that repeats, creates unclear handoffs, or depends heavily on instructions you carry in your head. Document just that item using the matching format.
- Capture the real task and its trigger.
- Classify it as a preference, routine, or longer process.
- Complete a one-page system card.
- Use the card on the next live instance.
- Revise unclear steps, decisions, and handoffs.
- Choose the next item from the list.
That cycle turns “I need better systems” into concrete operating instructions: one repeated task, one written system, and one live test at a time.
How early Reddy users got their systems written down
Early users end their first day with Reddy with 2 playbooks on average. Nobody built them: Reddy noticed work they repeat and saved it as a playbook. Within their first week, early users have 5 repeatable workflows on average, also identified and saved by Reddy as playbooks.
Most of those playbooks were triggers: when this happens, do that. That is why routines exist, and those playbooks became routines when routines launched. For work that takes days or weeks, such as a transaction that waits on a lender and a title company, SOPs carry the deal from one stage to the next, with a checklist for each stage.
This thing knows me more than I know myself. It read my brain without me even thinking about it. This is exactly what I need for all of these things that I do.
