Written and reviewed by the Green Arrow Consultancy team, led by Darren Tyler, founder and chief executive.
Website, brand, a property management system and a Salesforce integration, for a property and real estate business. Eight years is the interesting number here, because almost nothing about owning a system for eight years is visible on the day it launches.
Green Arrow Consultancy has developed and managed Healey Fox’s websites for more than eight years. The work covers website development, new branding, a bespoke property management system and a Salesforce CRM integration. This page is about what a long single-client relationship actually involves, and why property businesses are harder to build for than they appear.
Healey Fox is a property and real estate business. Green Arrow Consultancy has developed and managed its websites for over eight years, and the engagement has grown beyond the website into new branding, a property management system and an integration with Salesforce.
That list is worth reading slowly, because it is four different kinds of work. A website is a communication problem. A brand is an identity problem. A property management system is an operations problem. A CRM integration is a data problem. Suppliers who are strong at one of those are frequently weak at the next, which is the usual reason a growing business ends up with four of them and nobody accountable for the joins between them.
Work of this shape is not bought in a single procurement round. It accumulates over years, as a business grows and each solved problem makes the next constraint visible. That is the ordinary pattern for long client relationships outside large tender processes, and it is worth naming, because it is the pattern a prospective client is really trying to assess when they ask for a case study.
We do not publish this client's commercial figures, enquiry volumes or transaction data. What we can write about is the engineering, which is generalisable, and the working relationship, which is the part most prospective clients are actually trying to assess.
Green Arrow Consultancy has developed and managed my websites for Healey Fox for over 8 years now. I have been delighted with his online media and website knowledge and skills, the great value they offer and the high level of customer service and care they have offered us.
A property website looks like a brochure site with a search filter on it. It is not. It is a public interface onto a live inventory that changes every day, and almost every difficulty in the build comes from that inventory rather than from the pages.
Consider a single property record. It carries a price that changes, a status that moves through several states, photography of varying size and quality, floor plans, an energy performance certificate, descriptive text written by a person under time pressure, location data, viewing arrangements and sometimes tenancy or lease detail. Multiply by the number of live properties, then note that several people update these records concurrently, from an office and from a phone in a car park.
In UK property, a listing typically has to reach the firm's own website and the major portals, each of which has its own feed format, its own field requirements and its own opinions about image dimensions. A change made once should propagate everywhere. When it does not, a customer sees one price on a portal and another on the website, and the resulting phone call is not a pleasant one.
Property is a photography-led business, and photography is heavy. Large images are the most common reason property sites fail Core Web Vitals, and a slow gallery on a mobile connection is a lost enquiry. Responsive image handling, sensible formats, lazy loading below the fold and a pipeline that processes uploads rather than trusting whoever uploaded them are all necessary, not optional.
The value of a property website is measured almost entirely at the point of enquiry. A form that emails a shared inbox is where most sites stop, and it is why leads get lost. The requirement is routing: the right person, with the property context attached, quickly, with a record kept and a fallback if nobody responds. That requirement is what eventually makes a CRM integration unavoidable.
Six components, and the failures cluster in the joins rather than inside any one of them.
| Component | What it holds | Where it usually breaks |
|---|---|---|
| Public website | Search, filtering, property pages, media galleries, enquiry forms and content | Image weight, filter performance on large inventories, and forms that lose context about which property was viewed |
| Property management system | The authoritative property records, media, documents, availability, status and internal workflow | Exceptions. Every business has property states the original model did not anticipate |
| CRM | People: enquirers, applicants, vendors, landlords, and the full history of contact with them | Duplicates, and fields that two systems both believe they own |
| Portal feeds | Syndicated listings in each portal's required format | Silent failures. A rejected feed item does not usually announce itself to anyone in the business |
| Routing and notification | Rules for who receives an enquiry and what happens if they do not act | Staff changes. Routing rules written around named individuals rot the moment somebody leaves |
| Documents and brand assets | Particulars, brochures, boards, email templates and signage artwork | Rebrands. These are produced by different tools and are the last things to be updated |
A general anatomy of property digital estates, not a description of any single client system.
Six stages. Only one of them is writing the connector, and it is not the one that takes the longest.
Before any code, the business has to define the object. Is a viewing request the same thing as a valuation request? Is a returning enquirer a new lead or an update to an existing one? Teams frequently discover during this conversation that two departments have been using the same word differently for years.
Property records, contacts, enquiries and their relationships have to map onto Salesforce objects and fields. Every field needs one system designated as the source of truth. Fields owned by two systems will diverge, and the divergence will be discovered by a customer rather than by a report.
Real-time synchronisation is right for enquiries, where minutes matter. Scheduled batches are usually right for bulk property data, where volume matters more than latency. Choosing real-time for everything is a common and expensive instinct.
APIs time out, rate limits are hit, and payloads get rejected for a field that changed. The integration needs retries, a queue that survives a restart, an alert to a person, and a way to replay what was missed. An integration that fails silently is worse than no integration, because the business trusts it.
The same person enquires about three properties across two months from two email addresses. Matching rules, merge behaviour and a human review path for ambiguous cases have to be decided before go-live, not after the database has learned bad habits.
Who gets the lead, in what order, with what escalation if it is not picked up. Write these rules against roles and rotas rather than against named people, so that a leaver does not silently become a black hole for enquiries.
The branding work and the property management system arrived at different times and for different reasons, but they share a characteristic: both are the sort of project that is judged on how it behaves years later rather than on how it looks at launch.
A rebrand for a property business is not a logo exercise. The identity appears on property particulars, brochures, boards outside houses, email signatures, portal listings, document headers and the website, and those artefacts are produced by different systems and different people. A rebrand that changes only the website leaves the business visibly inconsistent in the places customers actually encounter it, which for property is frequently a PDF or a street. The useful deliverable is not the logo, it is the set of templates and rules that make every subsequent document come out right without anyone thinking about it.
There are established products in this space, and for many businesses buying one is the correct answer. We say so, in the same way we argue against building a new website on an estate when an existing one would do, which is a recurring conversation on the Energizer account. Building is justified when the workflow genuinely does not fit the market products, when the business would otherwise be paying per user for a fraction of a large product's surface area, or when the integration requirements around it are the actual point. The honest test is whether the business would still choose to build it after being shown the maintenance cost, and we make a point of showing that cost before anyone commits.
What a bespoke system buys is a data model that matches how the business actually works, including the exceptions, and an integration surface you control rather than one you request from a vendor's roadmap. What it costs is permanent ownership. Someone has to patch it, update its dependencies, keep it working as browsers and platforms change, and extend it when the business does. That is the trade, and it is a reasonable one when it is made with open eyes.
Launch is one day. These are the other three thousand.
Five things this engagement has taught us, all of which apply to clients far larger than this one.
More on how we scope, build and hand over systems in the full FAQ.
Website development, new branding, a property management system and a Salesforce CRM integration, over a relationship that has now run more than eight years. Daniel, Director of Healey Fox Property, has described the work publicly in terms of online media and website knowledge, value, and level of customer service. The commercial detail of the account is not something we publish.
Because the website is the smallest part. A property business runs on a live inventory that changes daily, with photography, floor plans, documents, pricing, availability and status all attached to each record. That inventory usually has to appear in several places at once, feed portals, generate enquiries, and route those enquiries to the right person quickly enough to matter. A brochure site has pages. A property site has a data pipeline with a public face on it.
A property management system holds the properties: records, media, documents, availability, status and the internal workflow that moves a listing from instruction to completion. A CRM holds the people: enquirers, applicants, landlords, vendors and the history of every interaction with them. They overlap at the point where a person expresses interest in a property, and that overlap is exactly where integration work lives.
Deciding which system owns each field, mapping objects between the property system and Salesforce, choosing between real-time synchronisation and scheduled batches, handling failures so nothing is silently lost, deduplicating people who enquire twice, and building the routing rules that decide who receives a lead and what happens if they do not act on it. The connector is the easy half. The agreement about which system is the source of truth is the hard half.
A straightforward brochure and listings site is a matter of weeks. Where a bespoke property management system or a CRM integration is in scope, the timeline is driven by data and by decisions rather than by build effort: how clean the existing property records are, how many exceptions the workflow contains, and how quickly the business can settle questions about ownership of data. We scope those separately for that reason.
That is the normal shape of our work. Websites are not delivered, they are operated. Platform and dependency updates, security patching, browser changes, integration endpoints that move, content changes, performance and accessibility maintenance, and periodic redesign of the parts that have aged worst. See website management for how that is structured.
The client. We build systems to be handed over and we document them accordingly, including the integration mappings, the routing rules and the deployment process. A supplier who makes themselves impossible to replace is managing a risk for themselves, not for you. The test of this is simple: ask any incumbent supplier what a handover pack would contain and how long it would take to produce.
On a working property business, quite a lot. Property particulars, brochures, board designs, email templates, portal listings, document headers, signage and the website all carry the identity, and they are produced by different systems. A rebrand that stops at the website leaves the business looking inconsistent everywhere a customer actually encounters it, which is usually in a PDF or on a street.
Yes. Engagements range from a single website to estates of hundreds of sites, and the property work sits nearer the first end. Smaller clients often get better outcomes because decisions are made in one conversation rather than in a governance forum.
Written and reviewed by the Green Arrow Consultancy team, led by Darren Tyler, founder and chief executive.
We take over other people's builds regularly. A short technical review tells you what the system actually is, what it depends on, where the risks sit and what it would cost to keep or to replace.