Custom work: one group, several branches, one set of books

Agencies that have grown by acquisition tend to arrive with a specific problem. Each office has its own book, its own staff, and often its own historic way of doing things. The group needs one view across all of it. The offices need to not see each other’s clients.

Solved badly, this becomes several separate systems and a spreadsheet that reconciles them monthly. Solved worse, it becomes one system where everyone can see everything and the group relies on people not looking.

The two requirements pull in opposite directions

The design decision that makes this work is boring and load-bearing: a branch is a label on the work, not a separate tenant. A property belongs to a branch. So do its tenancies, its rent schedule, its notices, its deposits and its documents — every child record inherits the branch of the property it hangs off, at the moment it is created.

Staff accounts, meanwhile, always belong to the group. A member of staff with access to one branch is restricted by their membership, not by being moved into a different organisation.

Contacts are the interesting case

Properties are easy to assign. Contacts are not, because one table holds tenants, landlords, guarantors and contractors — and a contractor works across every branch you have. Assigning a contractor to a branch is wrong; hiding them from the other branches is worse.

So contact visibility is derived rather than labelled. A tenant is visible to the branches whose properties they are attached to. A contractor attached to work in three branches is visible in all three. A contact attached to nothing yet stays visible to everyone, which is what keeps a newly added contractor reachable before their first job.

That last clause looks like a hole and is actually the point. Tightening it is the kind of change that seems obviously correct and then hides your entire contractor list from the person trying to instruct one.

What we configure in a branch engagement

Reassigning a property later — an office closes, a book moves — fans the new branch across every record hanging off that property in one operation. That is deliberately not something anyone does by hand, because a tenancy left pointing at the old branch is invisible to the new one and nothing complains about it.

When branches are not enough: separate legal principals

Branches are an operational division of one agency’s book, and for a multi-office agency that is exactly the right model. Some groups need something stronger, because their structure is not operational — it is legal.

A management group sitting above block management and lettings, where each underlying principal is a distinct legal entity — an SPV, an RMC, an RTM company, a landlord entity — has requirements branches do not meet. Each entity keeps its own records, its own controls, and its own client money. Buildings, units and tenancies have to inherit the right entity context automatically, because getting it wrong is not a reporting inconvenience.

This is bespoke enterprise work rather than configuration, and we have built it for groups whose structure required it — alongside the other two modules that tend to arrive with it, statutory workflows specific to an entity type and building-safety records that have to sit against the building rather than the tenancy.

Either way, tell us the structure early. Details to hello@tekniti.ai.