Service
For principals and branch directors of sales and lettings agencies who need the property register, the applicant list, viewings and portal feeds to work as one system shaped around their branches and negotiators rather than a generic agency CRM configured to its limits.
The problem
Where it usually starts
An agency runs on a register of instructions and a list of people looking.
Where it gets harder
Enquiries arrive from the portals, the website, the phone and the window card, each in a different inbox.
Scope of the service
A custom agency build normally covers:
Discovery works through a branch week with you: how an instruction moves from market appraisal to live listing, who may change a price and what has to happen on the portals when they do, how keys are held and signed out, which portals must receive feeds and in what format, how offers are recorded and progressed, and what landlords and vendors are allowed to see. Each becomes a named stage in the scope document: instruct, list and feed, enquire, view, offer, progress, complete or let.
A three-branch agency with eleven negotiators handles sales from two branches and lettings from all three, feeds four portals, and wants applicants matched across branches with a single landlord portal. That is a different build from a single-branch lettings agent with sixty managed properties, and the scope document will say so plainly.
Deliverables
Process
Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.
Access to your current CRM export, website, portal accounts and the key log; contacts named for each branch.
Discovery with the principal, a branch manager and a lettings administrator; the lifecycle, the feed list and the scope document are agreed with milestones.
Clickable designs of the register, the applicant match screen, the viewing diary and the public property page, checked on the devices negotiators carry.
Built in stages: register and public search first, then enquiries and viewings, then matching, feeds and the vendor and landlord portal.
A branch runs a test fortnight on live-shaped data, checks feed output against each portal and tells us where the lifecycle does not match practice.
Status rules, routing and feed mappings are adjusted from the review and re-checked against the scope document.
Instructions and applicants migrated, feeds switched over portal by portal, alert emails tested on addresses you control, checklist signed off.
The branches run on the new system; optional maintenance and hosting continue under their own agreement.
Integrations
Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.
How we would approach it
In this scoping scenario, an agency with three branches ran three copies of the same CRM, so an applicant registered in one town was never matched to a suitable flat listed by the branch six miles away, and landlords with properties under two branches received two different statements of what was happening. The scope we would propose: one register with branch ownership per instruction, applicants held once with requirements that span branch areas, matching that runs across the whole register but routes the enquiry to the owning negotiator, viewing diaries per branch with key custody recorded, and a single landlord portal that shows every property regardless of branch.
The reason this needs a custom build is the ownership model: most agency CRMs assume one branch per database, which is exactly the assumption this agency needed to break without losing branch-level accountability.
Pricing
Every proposal is priced on scope. These are the factors that move it most for this kind of build.
FAQ
Discovery compares your branch week with what the estate agency package does through configuration. A single or two-branch agency with standard portal feeds and a conventional lifecycle usually fits the package. Shared applicants across many branches, unusual offer-progression rules or a portal with a bespoke format point to custom work, and we say which before anything is quoted.
Portal feeds are an integration, configured and tested per portal using the format each one publishes. We name the portals in the scope document and treat each as its own piece of work. We do not control the portals, so timing and acceptance of listings remain theirs; what we build is the feed, the error log and the view that lets a negotiator see exactly what was sent.
It records them: deposit amounts, where they are held, the reference and the dates, alongside tenancy documents and renewal dates with reminders. Which scheme you use and whether your process meets the rules remains your decision and your advisers'. The system gives you the record and the reminder, not a compliance badge.
Usually yes, from an export of your current CRM. Live instructions, applicants with their requirements and archived sales history are mapped into the new register. The scope document states what carries over once we have seen the export, and old enquiry threads are the item most often left behind.
You do. Source code and data are handed over at delivery, portal credentials stay in your name throughout, and hosting and maintenance are optional and agreed separately.
Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.