---
id: imobiliario/jornada-lead-contrato
industry: Real estate
usage: widely used
effort: medium
grain: Lead with the date of the first milestone in each macro stage; stage transition (event) for time in stage; post-sale deal x current stage for the SLA
---

# Lead journey to contract

How long each lead takes to reach the viewing, the offer and the signed contract, where each team loses clients, and which post-sale deals have blown their stage deadline.

## Executive summary

**For:** Brokerages and developers that need to know how long it takes from first contact to signed contract and where the process gets stuck.

**What it solves**

- Leadership sees the full journey from lead to contract, even with lead and deal stored as separate entities in the CRM.
- Each back-office stage has a deadline, and the panel shows who is late and by how much.
- A stalled card becomes an alert to the broker before the client goes cold.

**Why it matters:** Selling property has a long cycle and many hands: pre-sales, broker, manager, back office, bank and notary. The CRM keeps only the current stage, so nobody knows whether the bottleneck is the first viewing, the offer or the draft contract. Without the journey measured the same way every month, there is no way to enforce SLAs or predict when commission and bank financing will come in.

**Business questions it answers**

- On average, how many days does a lead take from first contact to signed contract?
- At which stage does each team lose the most leads?
- How many back-office deals are late today, and at which stage?
- How long does it take from lead arrival to the first viewing?
- Which cards have been stalled longer than the stage allows?
- Which lead source closes contracts the fastest?

**What you need**

- CRM connected with the stage history of leads and deals (in Bitrix24, lead_stage_history and deal_stage_history)
- A map of every CRM stage to a journey macro stage, approved by management
- The deadline for each post-sale stage, agreed with the back office

**What you get**

- A table per lead with the date of each milestone and the days between them
- A stage event table with time in stage, team, broker and source
- Post-sale SLA panel with late or on-time status
- An AI agent that answers questions about cycle time and bottlenecks with the right rule

## Detailed

### The problem

In a real estate CRM the journey starts as a lead and ends as a deal, and both keep only the current stage. Many deals are created without the lead id, so the journey breaks in half and the time to contract disappears. Measuring with the last-updated field resets the clock on every edit, and treating a won lead as a sale reports contracts that were never signed.

### Business rules

1. **Link the deal to its source lead in a cascade.** The deal's lead_id is often empty. Resolve it in three tiers, in this order: 1) the deal's direct lead_id; 2) the first lead of the same contact_id created before the deal; 3) a lead with the same normalized contact name, created up to 730 days before the deal, keeping the most recent. Store a column saying whether the link was recovered, to measure quality. (Avoid: Using only the deal's lead_id and losing the journey for deals without it.)
2. **A milestone is the first entry into the macro stage.** Map each lead status and each deal stage to a numbered macro stage (qualification, contact, viewing, offer, won, offer accepted, contract, signing, contract signed). The milestone date is the earliest entry date in the history for any stage in that macro stage. Always sort by the macro stage number, never by name. (Avoid: Counting the lead by the stage it is in today.)
3. **A won lead is not a signed contract.** On the lead, won (CONVERTED in Bitrix24) means it became a deal. Contract signed is a deal stage, after offer accepted, drafting and signing. Close rate uses contract signed over leads; deal conversion rate uses won leads over leads. (Avoid: Reporting a converted lead as a closed sale.)
4. **Cohort by lead month.** The journey is read by the lead's qualification date: the March leads and how far each one got. Time between two milestones exists only when both dates exist; incomplete journeys stay out of the average, they do not count as zero. For monthly output (how many viewings happened in March), use the event table by event date, and never mix the two readings in the same chart. (Avoid: Filtering March leads and counting contracts signed in March.)
5. **An open stage has an age, not a duration.** In the stage event, time in stage is the next entry minus the current entry. The stage a deal is in today is measured up to the current date, so its average grows every day. Show the duration of completed stages separately from the age of deals still in the stage. (Avoid: A single average of days in stage with open and completed mixed together.)
6. **Stage entry comes from the history.** The entry date into the current stage comes from the stage history. Per-stage date fields filled by automation can support it, checked against the history. The deal's last-updated date never works: any field edit changes it. (Avoid: Days to first viewing = last update minus creation.)
7. **Each post-sale stage has its own deadline.** The back-office pipeline (data validation, draft contract, signing of the CCV, i.e. purchase and sale agreement, financing, deed, ITBI transfer tax and registration) has very different deadlines. A real example: data validation within 1 day, analyst validation within 2 hours, drafting within 8 hours, draft under review by the parties within 2 days, CCV signing within 1 day, financing signing within 90 days, deed and registration within 30 days each, cash sale annotations within 45 days. Stages that depend only on third parties may have no deadline. Show the status (late or on time) and how far past the deadline it is. (Avoid: One deadline for every stage.)
8. **Convert the time zone before measuring.** Bitrix24 stores dates in the server time zone. Convert to America/Sao_Paulo before cutting the day and before calculating deadlines in hours. In a stage with a 2-hour deadline, a wrong time zone marks everything as late. (Avoid: Calculating hours in stage with the raw CRM date.)
9. **A stalled card uses the stage's threshold.** Stalled means an open deal with days in the current stage above that stage's limit. Use the limit configured in the CRM when it exists (Imobzi stores stagnant_days per pipeline stage) and a declared default when it is empty (for example, 14 days). Won and lost never enter the alert. (Avoid: Alerting every deal with no change for 7 days, in any stage.)
10. **Group averages use the events.** Summary tables by team or source store the average already calculated. When combining several teams, calculate the weighted average from the events or individual journeys. An average of averages distorts when teams have different volumes. (Avoid: Adding each team's average and dividing by the number of teams.)

### Journey milestones

Example with Bitrix24: lead statuses and sales pipeline stages grouped into numbered macro stages.

- **Lead: NEW and qualification statuses** → 1. Qualification (`status_id NEW`)
- **Lead: IN_PROCESS and contact attempts** → 2. In contact (`status_id IN_PROCESS`)
- **Lead: viewing scheduled** → 3. Viewing (`status_id PROCESSED`)
- **Lead: offer made** → 4. Offer
- **Lead converted into a deal** → 5. Lead won (`status_id CONVERTED`)
- **Deal: offer in negotiation and accepted** → 6. Offer accepted
- **Deal: drafting and sending to the parties** → 7. Contract
- **Deal: contract signed** → 8. Contract signed
- **Lead JUNK, deal lost** → Lost, outside the progression (`stage_semantic_id F`)

### Definitions

| Metric | Definition |
|---|---|
| Source lead | lead linked to the deal through the cascade of lead_id, contact with an earlier lead, or name within 730 days; one per deal |
| Milestone date | earliest entry date, in the stage history, into any stage of the macro stage, in the America/Sao_Paulo time zone |
| Days from lead to signed contract | contract signed milestone date minus qualification milestone date, per lead; average only over journeys that have both dates |
| Signed contract rate | cohort leads that reached contract signed / cohort leads; null if the cohort has zero leads |
| Days to first viewing | entry into the viewing stage minus lead creation, in days and in hours |
| Time in stage | next entry minus current entry, per transition; for the current stage of an open deal, today minus entry (age) |
| SLA delay | time in current stage minus the stage deadline, when positive; in hours for stages with hour deadlines |
| Stalled card | open deal with days in the current stage above the stage limit (configured in the CRM or declared default) |

### Pitfalls

- **Conversion above 100%.** Skipped stages or stages recorded after the fact made more leads reach the offer than the viewing. How to avoid: Declare the rule: either mark the skipped stage as passed, or accept and explain rates above 100% without capping the number.
- **Clock reset on every edit.** Days to first viewing were calculated with the last-updated date, and any edit to the deal changed the result. How to avoid: Use stage entry from the history.
- **Journey broken in half.** Deals created directly by the broker had no lead_id and the journey stopped at the lead won stage. How to avoid: Recover the lead by contact and by name, and measure how many links were recovered.
- **An average that only grows.** The average days in stage rose every month because open deals were measured up to today. How to avoid: Separate the duration of completed stages from the age of open stages.
- **Loss reason in two fields.** The last stage before the loss was read as the reason, and two reason fields with different lists coexisted. How to avoid: Use the stage to know where it was lost and the consolidated reason to know why.
- **Impossible financing handover SLA.** Projects with direct developer financing or still in launch entered the bank financing handover SLA and dragged the indicator down. How to avoid: Calculate the handover SLA only for projects with an active bank financing portfolio.

### Acceptance test

- [ ] For a closed lead cohort, the count at each milestone matches a manual count in the CRM of entries into each stage (difference below 2%).
- [ ] Every deal in the sales pipeline has a source lead or the no-link flag, and the share recovered by the cascade is reported.
- [ ] No lead shows a signed contract without having passed through lead won or the corresponding deal stage.
- [ ] For a chosen post-sale deal, the current stage, entry date and SLA status match what the back office sees in the CRM.
- [ ] The sum of the times of a deal's completed stages equals the exit date of the last one minus the entry of the first.

### Context document

```text
Lead journey to contract
- The journey runs from the lead to the deal. The deal is linked to its source lead in a cascade: direct lead_id, then the first lead of the same contact created before the deal, then a lead with the same name within 730 days. The lead_origem_recuperada column says whether the link came from the cascade.
- Milestone = first entry into the macro stage, from the stage history. Order: 1 qualification, 2 in contact, 3 viewing, 4 offer, 5 lead won, 6 offer accepted, 7 contract, 8 contract signed. Sort by number, never by name.
- Lead won (CONVERTED) means it became a deal. Contract signed is a deal stage. Never call a won lead a sale.
- Cohort by the lead's qualification date. Monthly output by event date. Do not mix the two.
- Days between milestones only when both dates exist. Incomplete journeys stay out of the average.
- The current stage of an open deal is measured up to today: it is age, not duration. Answer the two separately.
- Average across several teams or sources: recalculate from the detail rows, do not average averages.
- CRM dates converted to America/Sao_Paulo before cutting the day or calculating hours.
- Post-sale SLA: each stage has its own deadline (deadline table per stage). Late when time in stage exceeds the deadline.
- Stalled card: open deal above the stage's day limit; default of <days> when the stage has no limit.
- Rates with a zero denominator return null.
Client exceptions:
- <client>: the official signed contract date is field <field> from <date>; before that, the first entry into the signed stage.
- <client>: bank financing handover SLA calculated only for projects <list>, with a ceiling of <days> days.
```

### Variations

- **Developer financing handover:** From contract to the bank's money: SLA in days between the handover sale date and entry into the stage where the financed amount is received, with a 60-day ceiling, only for projects with a handover portfolio.
- **Vista and Imobzi:** Vista: deal stage and completed viewings in the calendar. Imobzi: deal stage and entry date, with stagnant_days per stage. Without native history, save a daily snapshot of deals starting now.
- **Onboarding of managed properties:** Same method for a property entering the management portfolio: contract closed, inspection, adjustments, property active, with the days between each milestone.