Pipeline design · 15 minute read
Real estate CRM pipeline stages should describe what is true now.
A stage is useful when two agents looking at the same relationship would choose the same label—and know what decision comes next. This guide turns a seven-stage model into observable definitions, movement rules, and practical review views.
A pipeline is a shared language, not a scoreboard
The purpose of real estate CRM pipeline stages is to make current work legible. An agent should be able to scan the pipeline and tell which relationships need an initial response, which clients are actively searching, which offers need coordination, which deals are under contract, and which opportunities are paused or complete. A manager should be able to find exceptions without asking everyone to reconstruct the week from memory.
Stages become unreliable when they mix facts, opinions, urgency, and tasks. “Hot” is an opinion. “Call today” is a task. “Buyer” is a relationship type. “Searching” is a state. Keeping those concepts separate makes the pipeline easier to update and the dashboard easier to trust.
Keep three decisions separate
Stage
What is true about the active relationship now? Example: Searching.
Next action
What specific thing will someone do? Example: send the three reviewed listings Friday.
Priority
Which work deserves attention first, based on commitments, timing, and context?
One field cannot carry all three meanings. If an agent changes a stage to “Follow up” simply to remember a call, the pipeline loses the relationship state. If a dashboard treats every Searching client as equally urgent, it ignores due dates and commitments. Keep each decision in its proper field and build views that combine them when needed.
A practical seven-stage model
The following model matches GridCRM's default real estate lifecycle: New, Searching, Offer In, Under Contract, Closed Won, Closed Lost, and Paused. The operating definitions are examples; brokerage policy and the facts of a particular transaction remain authoritative. The important part is that every label has an observable meaning and a clear way out.
New
A relationship or inquiry has entered the system, but an agent has not yet established what the person needs or whether active work should begin.
- Entrance test
- Create or import the record, preserve the source and original question, and assign an accountable owner.
- Exit test
- Move on when the agent has enough verified context to begin an active search, or pause or close the record with an honest reason.
- Useful next-action examples
- Respond to the specific inquiry; confirm preferred contact details; identify whether the person is buying, renting, selling, or referring.
Searching
The client has an active property search with usable requirements and the agent is reviewing inventory, arranging showings, or refining the brief.
- Entrance test
- Record the active intent and enough structured criteria—such as budget, location, property type, bedrooms, and requirements—to support the work.
- Exit test
- Move on when the client is preparing or submitting an offer, or pause the search when activity has deliberately stopped.
- Useful next-action examples
- Review likely listings; confirm a showing; answer a property question; update requirements after feedback.
Offer In
A specific offer has been submitted or is actively being negotiated. This is narrower than general interest in a property.
- Entrance test
- Identify the relevant property and record the offer context the team needs to coordinate the next step.
- Exit test
- Move to Under Contract when an accepted agreement reaches that state, return to Searching if the offer fails and the search continues, or close the work accurately.
- Useful next-action examples
- Record the response; coordinate the responsible person; update the client with the agreed information and timing.
Under Contract
The relationship has reached an accepted-deal state and the remaining work is about progressing that deal, not continuing ordinary search activity.
- Entrance test
- Confirm the accepted deal and connect the client and property records so the shared context is recoverable.
- Exit test
- Use Closed Won when the deal completes, or Closed Lost when this deal ends without completion. If the client resumes searching, make that decision explicit.
- Useful next-action examples
- Track the next deal milestone and responsible party without pretending the CRM replaces legal, brokerage, transaction, or document systems.
Closed Won
The represented relationship reached the intended completed outcome. The record becomes durable relationship history rather than disappearing from the database.
- Entrance test
- Verify completion, retain the relevant client and property context, and close outstanding next actions that no longer apply.
- Exit test
- Usually this remains a historical outcome. A later referral, sale, purchase, or rental need should begin as new active work attached to the durable relationship.
- Useful next-action examples
- Complete any promised follow-through, then use respectful past-client relationship work based on relevance and preference.
Closed Lost
The active opportunity ended without the intended outcome. It records an outcome; it should not become a judgment about the person.
- Entrance test
- Capture a concise, factual reason the work ended and clear or resolve next actions that assumed the opportunity was still active.
- Exit test
- Keep the historical outcome. If circumstances change, begin new active work with current context instead of rewriting the old result.
- Useful next-action examples
- Only schedule future outreach when there is a relevant reason, an agreed time, and permission to do so.
Paused
The relationship may resume, but active work has intentionally stopped because of timing, readiness, availability, or the client's request.
- Entrance test
- Record why the work is paused, what event could restart it, and whether a review date or no outreach is appropriate.
- Exit test
- Return to the correct active stage when the underlying condition changes, or close the opportunity if the work has actually ended.
- Useful next-action examples
- Review at the agreed trigger; do not repeatedly postpone a generic reminder without learning whether contact remains useful.
Write movement rules before building reports
A stage definition should answer four questions: what must be true to enter, what evidence belongs on the record, what causes the relationship to leave, and which neighboring stages are legitimate next states. Write these rules in ordinary language and test them against recent relationships—including an easy win, a long pause, a lost offer, and a client who returned months later.
Use an evidence test
Ask, “What fact would another agent find on the record that proves this stage?” A submitted offer can support Offer In. A saved search alone does not prove that a person is actively Searching. A verbal impression that someone is “very motivated” does not create a transaction state.
Do not force every movement to be forward. A failed offer can return to Searching. An active search can become Paused. A paused client can resume. Preserve the reason and current next action so a backward or sideways move remains understandable rather than looking like data damage.
Build working views around decisions
A pipeline view shows distribution, but most daily work needs a more specific filter. Combine stage with owner, next-action date, and missing-data checks so the view answers a question an agent can act on.
New and unworked
New records assigned to the agent, sorted by arrival, with the source and original inquiry visible.
Active searches due today
Searching clients whose next action is due or overdue, with location, budget, and the purpose of the task.
Offers needing a decision
Offer In records with the relevant property, latest outcome, responsible person, and next commitment.
Under contract exceptions
Under Contract records missing the next milestone or accountable owner—not a replacement for a transaction system.
Paused reviews
Paused relationships whose agreed review trigger has arrived, excluding people who requested no outreach.
Pipeline hygiene
Active records without an owner, specific next action, due date, recent context, or a defensible stage.
Saved views are most useful when their inclusion rule is written down. “My pipeline” may mean assigned active work. “Needs attention” may mean overdue commitments or missing next actions. A label alone is not enough; the team should know why a row appears and what removing it from the view requires.
Common pipeline-stage mistakes
Too many stages
A separate label for every small activity makes updates fragile. Keep activities in the timeline and tasks; reserve stages for meaningful state changes.
Temperature labels
Hot, warm, and cold often reflect opinion rather than an observable relationship state. If priority matters, define it separately and explain the evidence.
Tasks disguised as stages
Call back, send listings, and follow up are actions. They need a responsible person and date, not a permanent place in the lifecycle.
Closed means deleted
A completed or lost opportunity is valuable history. Preserve the relationship and outcome, then attach future work to the same durable client context.
Paused means forgotten
A pause needs a reason and a deliberate trigger—or an explicit decision that no future outreach is appropriate.
Dashboards before definitions
A precise chart of inconsistently chosen stages is still unreliable. Audit a sample of records and movement rules before interpreting conversion or aging.
Run a short pipeline review
A weekly pipeline review should repair exceptions and make decisions—not ask every agent to narrate every row. Start with records that are unowned, overdue, inactive despite an active stage, missing a next action, or stuck in a state beyond the team's normal experience. Then inspect a small sample of recent movements for definition consistency.
- 1Confirm every New relationship has an accountable owner and a specific initial response decision.
- 2Review Searching clients with no recent context, no next action, or requirements too vague to support the work.
- 3Check Offer In and Under Contract records for the property, current outcome, next milestone, and responsible person.
- 4Resolve Paused records whose review trigger has arrived; do not roll dates forward automatically.
- 5Close work honestly when it has ended and preserve a concise factual reason.
- 6Sample stage changes across agents. If the same facts produce different labels, repair the definition or training before trusting the report.
Stage counts, time in stage, and conversion rates can be useful after the underlying choices are consistent. Treat them as operating signals, not complete judgments about agent performance or client quality. Market conditions, lead sources, client timing, and data-entry behavior all affect the numbers.
A CRM stage does not replace professional judgment or transaction controls.
Use brokerage-approved terminology and follow applicable legal, fair-housing, privacy, recordkeeping, and transaction requirements. Do not encode protected characteristics or subjective assumptions about people into stage or priority decisions. GridCRM organizes relationship and property context; it does not claim to replace an MLS, IDX site, legal advice, brokerage supervision, or a transaction document system.
Pipeline setup checklist
- Give every stage one observable definition
- Write an entrance and exit test
- Keep relationship type outside the stage
- Keep next action and due date separate
- Assign one owner to every active record
- Allow honest return and pause paths
- Preserve Closed Won and Closed Lost history
- Record a reason for pause or closure
- Build due-work and hygiene views
- Test definitions against recent real records
- Review exceptions weekly
- Audit consistency before trusting dashboards
Make the stage mean the same thing to everyone.
GridCRM connects real estate client stages with owners, next actions, conversation context, requirements, listings, showings, matching, and saved views in one spreadsheet-native workspace.