BrokerOS guide · 15 min read

The Boutique CRE Broker's Deal Operating System

A practical framework for seeing every active deal, next action, risk, and client commitment, from first contact through close.

Northgate Labs HQ Lease
Landlord rep · nine questions, one view
30-second test
Stage
Tenant outreach
What changed
Tenant asked for revised tour options
Next action
Confirm tour with Northgate Labs team
Owner
You
Due
Oct 8On track
Waiting on
Landlord rep floor plans
Risk
No reply from landlord rep19d stale
Client expects
Tour shortlist by Thursday
Latest document
Northgate tour book v3.pdf

Example deal with fictional data

On this page

A client asks, “Where does this deal stand?”

If answering requires searching your inbox, opening a spreadsheet, checking a shared drive, and texting someone on your team, the problem is not that you need another pipeline report.

The problem is that the deal does not have a complete operating record.

Most boutique commercial real estate brokers already have a system. It just happens to be distributed across five places:

  1. The pipeline spreadsheet shows the opportunity.
  2. Email contains the conversation and most changes.
  3. The calendar holds tours, deadlines, and follow-ups.
  4. Shared drives hold flyers, LOIs, financials, and other documents.
  5. The broker’s memory connects everything.

Each tool can work perfectly on its own while the deal still becomes difficult to run. The spreadsheet may be current, but it rarely shows the latest requirement change. The inbox has the update, but not the full timeline. The folder has the documents, but not the next action. Memory fills the gaps, until the week gets busy.

A deal operating system is not one more place to enter data. It is the discipline of keeping the current state of a deal visible and actionable.

This guide explains what that system should contain, how information should move through it, and what to automate without giving up control.


The quick test: can you understand a deal in 30 seconds?

Open one active deal and ask:

  • What stage is it in?
  • What changed most recently?
  • What needs to happen next?
  • Who owns that action?
  • When is it due?
  • What is waiting on someone else?
  • What could put the deal at risk?
  • What does the client expect next?
  • Where is the latest relevant document?

If those answers are not available in one current view, you have pipeline visibility, not deal visibility.

That distinction matters.

A pipeline answers, “What opportunities do we have?” A deal operating system answers, “What work will move each opportunity forward?“


1. Why the spreadsheet is not the whole system

Spreadsheets are useful. They are flexible, familiar, and easy to scan. For a boutique brokerage, they may be the fastest way to summarize a pipeline.

But a summary is not an operating record.

A spreadsheet usually captures structured facts: deal name, client, value, stage, probability, and expected close. The work required to keep those facts current happens somewhere else.

A requirement changes in an email.

A tour follow-up is promised during a call.

A deadline moves in a document.

A client asks for a revised flyer.

A counterparty goes quiet.

None of those events becomes operationally useful until it changes the shared understanding of the deal: its status, next action, owner, deadline, risk, or client commitment.

The spreadsheet is not the enemy. Manual reconstruction is.

A practical operating system can still use a spreadsheet, inbox, calendar, and drive. The goal is to connect the work already happening so the broker does not have to rebuild the deal’s current state from fragments.

The five places where deal truth usually lives

LocationWhat it containsWhat it usually cannot show alone
Pipeline spreadsheetStage, value, probability, expected closeConversation history, current blockers, next actions
InboxRequests, decisions, changes, commitmentsA clean shared view of the entire deal
CalendarTours, calls, deadlines, remindersWhy the event matters and what follows it
Shared driveFlyers, LOIs, financials, images, agreementsWhich file is current and what action it requires
MemoryContext, relationships, judgment, exceptionsA durable record that others can reliably use

The operating-system question is simple:

How does activity in one place update the shared state of the deal?


2. The minimum information every active deal needs

Do not begin by tracking everything. Begin with the smallest record that can support a confident next decision.

Every active deal should have six layers of information.

1. Identity

  • Deal or opportunity name
  • Client and primary contacts
  • Property, requirement, or assignment
  • Deal type: investment sales, landlord representation, tenant representation, or another clearly defined category
  • Internal owner

2. Current state

  • Current stage
  • Plain-language status
  • Last meaningful activity
  • Date of that activity
  • Open dependencies or blockers

“Active” is not a useful status by itself. A stronger status describes the actual operating condition: awaiting financials, tour scheduled, LOI under review, client decision pending, diligence item outstanding.

3. Next action

  • The next concrete action
  • Its owner
  • Its due date
  • Who or what it is waiting on

A deal without a next action is not being managed. It is being remembered.

4. Commitments and decisions

  • What the client requested
  • What the team promised
  • Material changes to requirements, pricing, timing, or terms
  • Decisions made and by whom
  • Items that still require confirmation

This is where email activity becomes more than correspondence. It becomes part of the operating record.

5. Documents and outputs

  • Current relevant documents
  • Version or date
  • Intended recipient
  • Status: draft, under review, approved, sent, signed, or superseded
  • Related next action

The goal is not to duplicate the file system. It is to make the current document, and its role in the deal, obvious.

6. Risk

  • Upcoming deadlines
  • Overdue actions
  • Unanswered material requests
  • Stalled stages
  • Missing information
  • Unconfirmed assumptions
  • Client commitments that may slip

Risk should be visible before it becomes an unpleasant surprise.


3. A stage-by-stage lifecycle map

Stage names vary by brokerage, assignment, and deal type. The useful discipline is not choosing the perfect labels. It is defining what must be true before a deal moves forward.

Use this lifecycle as a starting point and adapt it for leasing or investment sales.

  1. First signal

    Exit condition

    Someone has reviewed the signal and decided whether it is an opportunity, an existing-deal update, or something to close out.

  2. Qualification

    Exit condition

    The opportunity has a clear disposition and a defined next step.

  3. Active pursuit or assignment

    Exit condition

    The workstream, responsibilities, and next milestone are understood.

  4. Market activity

    Exit condition

    The deal has a qualified path into negotiation, or a clear decision about what must change.

  5. Negotiation and diligence

    Exit condition

    Material terms and outstanding conditions are understood well enough to proceed, pause, or exit.

  6. Closing and handoff

    Exit condition

    The transaction is complete, required handoffs are made, and remaining relationship actions are owned.

Each stage ends when its exit condition is true, not when a label changes.

Stage 1: First signal

A new inquiry, referral, client email, property lead, or other potential opportunity enters the workflow.

The system should capture:

  • Source and received date
  • Person and company
  • Property or requirement, if known
  • Deal type, if known
  • Initial request
  • Owner of the response
  • Response deadline or follow-up date

Exit condition: Someone has reviewed the signal and decided whether it is an opportunity, an existing-deal update, or something to close out.

The common failure here is not losing the email. It is failing to convert the email into owned work.

Stage 2: Qualification

The broker determines whether the opportunity is real, relevant, and worth pursuing.

The system should capture:

  • Client need or objective
  • Timing
  • Geography or asset criteria
  • Known stakeholders
  • Key unknowns
  • Next qualification action
  • Reason to advance, hold, or close

Exit condition: The opportunity has a clear disposition and a defined next step.

A vague “follow up later” state creates invisible inventory. Use an actual date and reason.

Stage 3: Active pursuit or assignment

The work becomes a real engagement, active requirement, or defined pursuit.

The system should capture:

  • Confirmed scope
  • Internal owner and collaborators
  • Client expectations
  • Key dates
  • Required materials
  • Current strategy
  • Immediate next milestone

Exit condition: The workstream, responsibilities, and next milestone are understood.

This is often where the amount of operational information expands faster than the pipeline record.

Stage 4: Market activity

Depending on the deal, this may include preparing and distributing materials, outreach, buyer or tenant engagement, property review, tours, and feedback.

The system should capture:

  • Materials prepared and current version
  • Distribution or outreach activity
  • Interested parties
  • Tour dates and outcomes
  • Feedback
  • Follow-up commitments
  • Changes to requirements or positioning

Exit condition: The deal has a qualified path into negotiation, or a clear decision about what must change.

A tour is not complete when it ends. It is complete when feedback, follow-up, and ownership are recorded.

Stage 5: Negotiation and diligence

Offers, LOIs, counters, supporting information, and diligence items begin to carry more risk.

The system should capture:

  • Current proposal or term status
  • Material changes
  • Open questions
  • Decision owners
  • Document status
  • Deadlines
  • Dependencies
  • Items requiring explicit human review

Exit condition: Material terms and outstanding conditions are understood well enough to proceed, pause, or exit.

This is not the place for silent automation. Summaries can help, but important terms, commitments, and changes should be confirmed by a person.

Stage 6: Closing and handoff

The transaction moves toward completion, delivery, and final follow-through.

The system should capture:

  • Closing requirements and dates
  • Outstanding documents or approvals
  • Final client commitments
  • Handoff responsibilities
  • Completion confirmation
  • Post-close follow-up

Exit condition: The transaction is complete, required handoffs are made, and remaining relationship actions are owned.

A deal is not operationally closed because the revenue event occurred. It is closed when the remaining commitments no longer depend on memory.


4. How email activity should update the deal record

For most boutique brokers, email is where the deal moves.

That makes the inbox the natural point of capture, but not the final deal record.

A useful email-to-record workflow has four steps.

Re: Tour options
Dana Reyes, Northgate Labs

Thanks for the list. We now need 18,000 SF instead of 15,000 and would like revised tour options by Thursday. Can we also see the floor plans for the second building?

Mon 9:14 AM

Northgate Labs HQ Lease
Proposed updates from 1 email
  • Last activity
    Email from Dana Reyes
    Filed
  • Contact
    Dana Reyes, client
    Filed
  • Next action
    Send revised tour options by Thursday
    Filed
  • Requirement
    15,000 SF to 18,000 SF
    Needs review
  • Waiting on
    Floor plans from landlord rep
    Filed
Example with fictional data: routine facts are filed, while the material requirement change waits for the broker.

Capture

Bring relevant activity into the operating record without requiring the broker to retype the email.

The mechanism may be forwarding a message, connecting an inbox, or another deliberate capture method. The principle is the same: start where the work already enters the business.

Classify

Determine whether the message represents:

  • A new prospect or opportunity
  • An update to an existing deal
  • A task or request
  • A decision or material change
  • A document event
  • An ambiguous item requiring review
  • Noise that should not affect the deal

Propose an update

The system can suggest changes such as:

  • Update the deal status
  • Record the latest activity
  • Create a next action
  • Assign an owner
  • Add or update a contact
  • Flag a deadline or risk
  • Associate a document

Review when the consequence is material

Automation should not turn uncertainty into false certainty.

Use review states when the message is ambiguous, when multiple deals could match, or when an update changes a material term, deadline, commitment, or client-facing output.

A practical rule:

Automate capture and organization aggressively. Automate judgment cautiously.

What not to do

Do not treat every email as equally important. Do not create a task from every sentence. Do not silently overwrite material information. Do not assume that an AI-generated summary is the deal record.

The goal is not an inbox copied into another tool. The goal is a current, reviewable state of the deal.


5. Tasks, risks, and next-action visibility

The fastest way to improve deal visibility is to make next actions explicit.

A strong next action is:

  • Specific
  • Owned by one person
  • Connected to a deal
  • Due at a meaningful time
  • Clear about what it is waiting on
  • Complete only when the outcome is recorded

“Follow up” is weak.

“Send revised tour options to the client by Thursday” is operational.

The Monday deal review

For each active deal, review five questions:

  1. What changed? New requests, responses, documents, terms, contacts, or dates.
  2. What is blocked? Information, decisions, approvals, or responses preventing progress.
  3. What is at risk? Deadlines, stale conversations, unowned work, or assumptions that need confirmation.
  4. What needs a response? Client, counterparty, colleague, vendor, buyer, tenant, landlord, or owner activity awaiting action.
  5. What does the client need next? An answer, update, recommendation, document, tour plan, status report, or decision.

This review should not require reconstructing every deal from the inbox. It should confirm and correct the operating record.

Useful risk signals

Risk does not require a complex score. Begin with visible conditions:

  • Next action overdue
  • No meaningful activity within the expected deal rhythm
  • Important email unanswered
  • Deadline approaching without an owner
  • Deal stage unchanged while unresolved items accumulate
  • Material document awaiting review
  • Conflicting information across messages or files
  • Client commitment without a corresponding task
  • Critical knowledge held by only one person

A risk flag should lead to an action. A dashboard full of alerts without ownership is just a new form of clutter.


6. Client-facing outputs and handoffs

Internal visibility should make client communication easier, not create another reporting job.

Every client-facing output should be connected to the current state of the deal.

That includes materials such as:

  • Deal or status updates
  • Property or tour information
  • Dynamic flyers
  • Shared deal rooms
  • Recommendations and next steps
  • Transaction documents
  • Closing or handoff summaries

For each output, track:

  • Who it is for
  • What question it answers
  • Which source information it uses
  • Its current status
  • Who must review it
  • When it was shared
  • What response or next action it created

The operating principle is continuity.

A requirement change should update the deal record before it appears in the next client-facing material. A new document should be associated with the relevant decision or action. Client feedback should return to the same operating record rather than remaining isolated in a separate thread.

The better the internal record, the less often the broker has to reconstruct status solely for the purpose of communicating it.


7. The one-deal operating-system audit

Choose one active deal, not the cleanest one. Pick the deal most likely to expose gaps.

Score each statement Yes, Partly, or No.

Identity and status

  • The deal has a clear owner.
  • The current stage is accurate.
  • The status describes the real operating condition, not just “active.”
  • The last meaningful activity is visible.
  • Key contacts and their roles are current.

Next actions

  • The next action is specific.
  • One person owns it.
  • It has a due date or review date.
  • Dependencies are visible.
  • Client commitments have corresponding actions.

Conversation and decisions

  • Material email activity is connected to the deal.
  • Requirement changes are recorded.
  • Important decisions include enough context to understand them later.
  • Ambiguous updates are marked for review rather than treated as fact.

Documents and outputs

  • The current relevant document is easy to find.
  • Draft, approved, sent, signed, and superseded versions are distinguishable.
  • Each important document is connected to an owner or next action.
  • Client-facing materials reflect the current deal information.

Risk and continuity

  • Upcoming deadlines are visible.
  • Overdue actions are visible.
  • Unanswered material requests are visible.
  • Someone else could understand the deal without a verbal reconstruction.
  • The client could receive a current status update without an inbox search.

Reading the result

  • Mostly Yes: You have a usable operating record. Focus on keeping updates current with less manual work.
  • Many Partly answers: The structure exists, but the deal still depends on reconstruction. Improve capture and ownership first.
  • Several No answers: The process relies heavily on individual memory. Start with current status, next action, owner, and due date before adding more fields.

Do not respond to a weak score by building a larger spreadsheet. Fix the flow of information.


8. What to automate first, and what to keep human-reviewed

The best first automations remove repetitive administration around facts that already exist.

Automate first

Activity capture
Bring relevant email activity into the deal record without asking the broker to enter it again.

Routing and association
Suggest whether an item belongs to a prospect, an existing deal, or a review queue.

Routine record updates
Propose updates to last activity, contacts, categories, and other low-risk structured information.

Task suggestions
Identify explicit requests, promised follow-ups, and dates that may require an owned action.

Visibility
Surface overdue work, stalled deals, unanswered messages, and approaching deadlines.

Repeatable outputs
Use current approved information to reduce the effort required to produce or update routine client-facing materials.

Keep human-reviewed

Material terms and commitments
Pricing, economics, dates, obligations, concessions, and other consequential changes should not be silently accepted.

Ambiguous deal matching
If an email could belong to multiple opportunities, or none, the system should ask rather than guess.

Client-facing conclusions
Recommendations, negotiation positions, and sensitive communications require broker judgment.

Exceptions
Unusual relationships, confidential situations, and one-off structures need visible human control.

Final document approval
Automation can prepare and organize. A responsible person should approve what is sent or relied upon.

Trustworthy automation makes its confidence and review state visible. It helps the broker decide faster without pretending that every input is certain.


Build the system around work that already happens

Boutique brokerages do not need more software administration. They need operational clarity that survives a busy week.

A useful deal operating system should let a broker see, in one current view:

  • Where the deal stands
  • What changed
  • What happens next
  • Who owns it
  • What is blocked
  • What is at risk
  • What the client needs
  • Which information still requires review

The standard is not perfect data. The standard is a reliable next decision.

Start with one active deal. Run the audit. Fix the first point where the record depends on searching, remembering, or asking around.

Then repeat.


How BrokerOS approaches the problem

BrokerOS is being built for individual brokers and small teams at boutique and independent CRE firms. It starts with the broker’s existing workflow: relevant email activity can be captured through forwarding or connected-inbox polling, organized into the appropriate prospect or deal record, and surfaced for review when the system is uncertain.

The current product also supports client-facing deal rooms and dynamic flyers as shareable webpages or exportable PDFs. The goal is to create continuity from incoming activity to the internal deal record to the materials a client sees, without forcing the broker to administer another complex system.

BrokerOS is currently working with early design partners. To follow the product or request early access, visit runbrokeros.com.

FAQ

Deal operating system questions

What is a deal operating system for a CRE broker?
A deal operating system is not one more place to enter data. It is the discipline of keeping the current state of a deal visible and actionable: where the deal stands, what changed, what happens next, who owns it, what is blocked, what is at risk and what the client needs.
How is a deal operating system different from a pipeline spreadsheet?
A pipeline answers, "What opportunities do we have?" A deal operating system answers, "What work will move each opportunity forward?" A spreadsheet captures structured facts like stage, value and expected close, while the work that keeps those facts current happens in email, calendars, shared drives and memory.
What information does every active deal need?
Every active deal should have six layers of information: identity, current state, next action, commitments and decisions, documents and outputs, and risk. Begin with the smallest record that can support a confident next decision.
What should a broker review every Monday?
For each active deal, review five questions: what changed, what is blocked, what is at risk, what needs a response, and what the client needs next. The review should confirm and correct the operating record, not reconstruct every deal from the inbox.
What should CRE brokers automate first?
The best first automations remove repetitive administration around facts that already exist: activity capture, routing and association, routine record updates, task suggestions, visibility into overdue and stalled work, and repeatable outputs.
What should stay human-reviewed?
Material terms and commitments, ambiguous deal matching, client-facing conclusions, exceptions and final document approval. If an email could belong to multiple opportunities, or none, the system should ask rather than guess.