A property passes through agents, owners, tenants and contractors, and each of them tends to keep their own copy of the truth. We build the system that keeps one.
Portals each want a listing in their own shape, and the fastest way to end up with four versions of a property is to let four people maintain them. We build the property as one record with a feed per destination, so a change to a price or a floor plan goes out everywhere from one edit. Where a portal rejects a listing, the failure comes back into the system as something to fix rather than disappearing into an integration log.
Booking a viewing by phone costs an agent a call and a customer a wait. We build the slot picker against the calendar of whoever is actually doing the viewing, with the confirmations and reminders that stop people not turning up. Applications carry their documents with them, so references, checks and signatures sit against the tenancy rather than in an inbox, and a colleague picking the file up on Monday can see exactly where it got to.
Most of a property's life is the years after it is let, and that is where the software usually stops. We build the maintenance side so a tenant report opens a job, the job carries the contractor, the quote and the approval, and the owner can read it without ringing the office. Rent, arrears and statements come off the same record, which is what lets a portfolio be reported on rather than counted up by hand each month.
A listing is sold by its first image and very little else, and yet media handling is the part most agency software treats as an upload field. It deserves better. Files arrive from a negotiator's phone at the kerbside on a weak connection, from a photographer as a folder of large originals, and from a developer as renders in the wrong aspect ratio, while every destination wants its own sizes, its own minimums and its own opinion about watermarks. So the system keeps the original, generates what each portal needs, corrects the rotation the camera recorded and nobody else reads, and makes the running order something set on purpose rather than an accident of upload sequence. Floor plans and energy certificates live in the same place, because a listing missing one is filtered out of searches before a buyer ever sees it.
Every portal has mandatory fields, its own list of property types, its own tenure values and its own view of what a price qualifier means, and none of those lists agree with each other. If the only place this is checked is the outgoing feed, an agent finds out days later through a rejection nobody read, and the listing was invisible the whole time. So the checks move to the point of entry. The fields a destination requires are required on the form, values are chosen from lists that map cleanly outward, and the address is resolved against a reference rather than typed twice by two branches, which is how the same house ends up listed as two. It is unglamorous work, and it is the difference between syndication that runs itself and syndication somebody nurses every morning.
A single record with a feed per destination, so a price change or a new floor plan goes out everywhere from one edit rather than being maintained four times by four different people.
Originals kept, portal sizes generated, rotation corrected and running order set deliberately. The first image is the listing, so it is treated as more than an attachment on a record.
A feed per portal in its own shape, with counts and rejections coming back attached to the property, and an alert when a destination quietly stops accepting listings at all.
Slots against the calendar of whoever is actually doing the viewing, with the confirmations and reminders that stop people not turning up, because a phone call costs the agent time and the buyer a wait.
References, checks, contracts and signatures held against the tenancy with a history of what was agreed when, so a colleague picking up the file on Monday can see where it got to.
A tenant report opens a job, the job carries the contractor, the quote and the approval, and both owner and tenant can follow it without ringing the office for an update.
Where the applicant, the vendor and the pipeline already live. We build against it and keep property and contact in step, rather than asking negotiators to work in two systems at once.
Each with its own schema, its own required fields and its own rejection rules, changed on their timetable rather than yours. The integration is per destination, not one generic export.
Resolving an address against a reference instead of accepting free text is the cheapest duplicate prevention available, and it is what lets two branches recognise the same property.
Rent, deposits and landlord payments, with the account separation and the scheme deadlines that are statutory in several markets rather than a matter of internal policy.
Energy certificates, gas and electrical safety, licensing and deposit protection all carry dates. The useful software is the part that warns you a fortnight before one lapses.
Rent, arrears, fees and contractor invoices posted from the same records, which is what lets a portfolio be reported on rather than counted up by hand at the end of each month.
Take a single instruction from photographs through to every portal via one record, and watch what each destination rejects. It is the fastest way to find the fields your data has never held.
Reordering images, choosing a real hero shot and meeting each portal's minimum size costs nothing and moves enquiry numbers before a line of code has been written.
Counts sent and accepted per destination, with an alert on the drop. Small, quick, and it ends the class of problem where a week of enquiries goes missing without anyone noticing.
Usually where the calls are. A tenant who can report a repair and follow its progress removes a large share of what a property team spends its week answering.
Yes, and that is the point of holding the property as one record. Each portal takes the listing in its own shape from one source, so a price or floor plan change goes out everywhere from a single edit. Rejections come back into the system as something to fix rather than disappearing into a log nobody reads.
We build against it rather than replacing it where it is doing its job. Agents should not be asked to work in two systems, so the integration keeps the property and the contact in step. Where the CRM is the thing holding the business back, that is worth saying plainly, with the reasons.
That is usually where the return is. A tenant who can report a repair and see its progress, and an owner who can read the maintenance trail and the statement without ringing the office, removes a large share of the calls a property team spends its week on.
They belong to the tenancy rather than to an inbox. References, checks, contracts and signatures sit against the record they relate to, with a history of what was agreed and when, so a colleague picking up the file on Monday can see exactly where it got to.
It has to, because that is the normal state of an agency. A phone set from the negotiator, a paid photographer's files, the developer's renders and whatever the previous agent left behind all arrive at different sizes, orientations and quality. The system takes them as they are, corrects the rotation the camera recorded, generates the sizes each destination wants, and keeps the original so a portal that later asks for something larger can be served without a second visit. Order is the part people forget. The first image decides whether anyone clicks, so it is chosen deliberately rather than being whichever file uploaded first. Rights matter as well, since a photographer's licence often ends when your instruction does.
You cannot prevent it, so the aim is to notice the same day rather than the following week. Every destination carries a count and a status: how many listings were sent, how many were accepted, how many were rejected and for what reason. A drop below the expected count raises an alert instead of sitting in a log nobody opens. Rejections come back into the system attached to the property, so a negotiator fixes the missing field, which is where most of them belong anyway. Changes are staged against a portal's test endpoint where one exists. A week of lost enquiries almost never comes from a dramatic failure. It comes from a silent one nobody was watching for.
Almost certainly not, and it is better to hear that now than after the second year of spending. A portal is a two sided marketplace: worthless to buyers until it holds most of the local stock, and worthless to agents until it brings the buyers. Winning that from a standing start takes years of marketing money and a reason for rival agents to hand their listings to a competitor, which they will not do. Where the money does work is on your own site and your own audience. Better property pages, a search that filters the way local buyers actually think, saved searches and alerts that bring people back, and a registration path that turns a portal enquiry into a contact you own rather than rent.
It divides into three, and treating it as one pile is what gets agencies into trouble. Identity documents and the checks made from them were collected for a purpose that has finished, and they should be deleted on a schedule rather than sitting in a folder indefinitely. The tenancy record itself, meaning the agreement, the deposit, the inventory and the correspondence, carries a statutory retention period in most markets and has to stay findable long after the tenant has gone. The maintenance history belongs to the property rather than to the person, so it survives every tenancy and is exactly what the next contractor needs. Building those three lifetimes in from the start is far cheaper than separating them later under a data request.
We are happy to answer any questions you have and help you work out which of our services fit your needs.
