Real estate
The lettings pipeline between an applicant registering interest and a signed tenancy is short in duration but heavy in coordination: matching the right applicants to the right stock as it comes to market, scheduling viewings without double-booking a property or a negotiator, tracking competing offers accurately enough to advise a landlord properly, and knowing exactly where each applicant's referencing has got to before agreeing a move-in date. Generic CRM software organises this as a generic sales pipeline with stages like "contacted" and "qualified," which describes almost nothing useful about a lettings transaction. We build lettings CRM platforms around applicant requirements, viewing logistics, offer comparison and referencing status as first-class, structured data.
This is built either as the front end to an existing lettings ledger such as Reapit or Alto, handing off a confirmed let into that system once terms are agreed, or as part of a fuller property management platform where we hold the tenancy ledger directly. Either way, the negotiator's day-to-day work — matching, scheduling, chasing offers, checking referencing — is designed around how lettings actually moves, not adapted from a template built for a different kind of sale.
The workflow this replaces
Without a lettings-specific pipeline, most agencies run the applicant-to-tenancy journey through a mix of a generic CRM, spreadsheets, and negotiator memory.
Step 01
Area, budget, bedroom count and move-in date are captured in a phone call and recorded as a free-text note against a contact record, which means matching against new stock depends on a negotiator remembering or re-reading the note rather than the system surfacing a match automatically.
Step 02
When a property comes to market, negotiators think through which applicants they remember as a fit and call around, which favours whichever applicants a negotiator happens to recall clearly and disadvantages applicants who registered weeks earlier with a different team member.
Step 03
A viewing slot is booked in a negotiator's own calendar without a reliable check that the property isn't already booked for another viewing at an overlapping time, or that a second negotiator hasn't independently offered the same slot to a different applicant.
Step 04
When more than one applicant offers on the same property, the comparison — rent offered, move-in date, referencing readiness — is assembled manually, and the landlord conversation happens from a spreadsheet the negotiator updates in real time, prone to being out of date by the time the call happens.
Step 05
Once an offer is accepted and referencing is initiated through Goodlord or Canopy, checking progress means a negotiator logging into that provider's own interface separately from the CRM, then updating the applicant and the landlord by phone once a status changes.
Step 06
Once terms and referencing are through, applicant and property details are manually re-entered into Reapit, Alto or whichever system manages the actual tenancy, repeating data entry that was already captured earlier in the process and introducing the risk of a transcription error in the rent or term.
A skilled negotiator compensates for a lot of this through experience and diligence, but the process does not scale past a handful of active lettings per person without something breaking — a missed applicant, a double-booked viewing, or a landlord given an out-of-date comparison. The CRM we build exists to remove that dependency on memory and manual reconciliation.
What we build
Area, price band, bedrooms, move-in date and specific criteria held as structured fields per applicant, matched automatically against new and updated stock with a ranked shortlist and notification to the assigned negotiator.
Viewing slots held against both the property and the negotiator's calendar simultaneously, preventing double-booking, with automated confirmation and reminder messages sent to the applicant.
Competing offers on the same property held as separate, comparable records — rent, term, move-in date, referencing readiness — presented together for the landlord conversation, with automatic status update to declined for unsuccessful offers once one is accepted.
Referencing requests triggered to Goodlord or Canopy at offer acceptance, with status — pending, passed, passed with conditions, failed — displayed against the applicant record and the pipeline stage it is blocking.
Right to Rent verification status held against the applicant ahead of tenancy start, and, where the agency's policy requires it, AML and KYC check status for landlords onboarding a property, both visible on the record that would otherwise block a tenancy from proceeding.
Confirmed let details passed automatically into the incumbent tenancy ledger (Reapit, Alto or equivalent) through its API, or into our own property management platform where the full lifecycle is built by us, without manual re-entry.
Integrations
Management platforms
Referencing
Portals
Communication
Portal enquiries are typically the entry point for new applicants, so the CRM is built to capture leads from Rightmove, Zoopla and OnTheMarket directly into the applicant register rather than through a separate inbox that a negotiator has to check and re-key from.
Data and compliance
Architecture note
Applicant, property, viewing and offer are held as distinct but linked entities, so a shortlist, a viewing schedule and an offer comparison can each be generated as a query across the relationships rather than as separately maintained lists that drift apart.
Referencing integration is built as an asynchronous adapter against Goodlord's or Canopy's API, receiving status callbacks rather than polling continuously, so the pipeline view updates promptly without hammering the provider's interface.
Portal lead capture writes directly into the applicant register with a source tag per portal, so lead volume and conversion by portal can be reported without a separate marketing analytics layer.
Handoff to the tenancy ledger is a discrete integration step triggered on offer acceptance and referencing pass, keeping the CRM focused on the pre-tenancy pipeline and the ledger system authoritative for the tenancy itself once it exists.
Timeline
Weeks 1-2
Mapping of the current applicant, viewing and offer process, referencing provider setup, and integration points with the incumbent management platform.
Weeks 3-7
Structured applicant data model, matching logic, and viewing scheduling with double-booking prevention.
Weeks 8-11
Offer comparison workflow and referencing integration with Goodlord or Canopy, including status callback handling.
Weeks 12-14
Portal enquiry ingestion into the applicant register and tenancy handoff integration with the incumbent ledger.
Weeks 15-17
Pilot with a subset of negotiators, adjustment based on real pipeline use, then rollout across the branch or business.
Indicative cost
Bands assume a single-brand agency with an established referencing provider relationship. A multi-branch agency with varied processes per branch typically sits toward the upper end due to configuration and change management effort.
Where this sits
Questions
Every applicant's requirements — area, price band, bedrooms, move-in date and any specific criteria such as pet ownership or garden access — are held as structured data, and every new or updated property is matched against the live applicant register automatically, generating a ranked shortlist and a notification, rather than relying on a negotiator remembering which applicant said what during a phone call weeks earlier.
Yes. Viewing slots are held against the property and the negotiator's calendar simultaneously, so a slot booked by one negotiator is immediately unavailable to another, and back-to-back viewings at the same property automatically account for realistic travel and viewing duration rather than being scheduled on a fixed grid that ignores it.
The CRM triggers the referencing request to Goodlord or Canopy at the point an offer is accepted, and polls or receives a callback on status — pending, passed, passed with conditions, failed — displaying it against the applicant and the tenancy pipeline so a negotiator knows exactly what is blocking move-in without logging into the referencing provider's own portal separately.
Yes. Multiple offers against a single property are held as competing records, each with its own status, so a negotiator can present the landlord with a genuine comparison rather than working from memory, and once one offer is accepted, the others are automatically moved to a declined state with an option to notify the applicant.
Yes. The CRM is built to read and write applicant, viewing and offer data against Reapit's or Alto's API where the tenancy then needs to be created in the incumbent ledger, so a confirmed let flows through into the existing rent and compliance system without manual re-entry. Where an agency is replacing its incumbent system entirely, the CRM becomes the front end for the full lettings lifecycle instead.
A CRM covering applicant matching, viewing scheduling, offer progression and referencing status tracking, integrated with an existing management platform, typically runs £250,000 to £420,000 over four to six months. A build that also replaces the underlying tenancy ledger runs considerably higher and is scoped as part of a wider property management platform programme.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us