Skip to content
Imagio Labs

Work / 04 Operating System / System Architecture

ORB

The system a transaction runs on

The operating layer for a property transaction — the CRM and the working system a deal is carried through, from first enquiry to completion.

ORB · Active system

01 The engagement

ORB is an operating system for Flatr’s internal operations. Imagio’s role extended beyond interface design into system thinking, process architecture and build optimisation, helping turn complex operational workflows into a coherent digital environment.

02 The surface

ORB — the resolved system

GENERATED COMPOSITION · NO APPROVED SCREENSHOT EXISTS, AND NONE HAS BEEN INVENTED

ORB runs a live operation. Nothing about it is published, and nothing about it is claimed.

03 The problem
and the idea

The problem. A property transaction does not happen in one system. The listing is somewhere else, the buyer is somewhere else, the agent’s own records are somewhere else, and the deal itself — the part that has to hold together from first message to completion — is held together by people. The person becomes the integration layer, and the deal is reassembled by hand at every hand-off.

Complexity → clarity

The idea. Give the transaction one place to live. One record that starts at the enquiry and is carried to completion, one vocabulary across every screen it passes through, and workflows grouped by the moment of use rather than by the org chart.

04 The work

What we did,
in order.

One nodeBranchesA living system

01 · One record for the whole transactionORB is modelled on the transaction, not on the department. Listing, buyer, match, agent assignment and the deal itself are parts of one object with one history, so “where is this deal” is a lookup rather than an enquiry. The dealroom workflow carries that record from enquiry to completion instead of handing it between tools.
02 · Grouped by the moment of useWorkflows were drawn from how the work actually gets done — what arrives, what it waits for, what it produces, and who picks it up if nobody does — and reorganised so the things one person needs at one moment sit together. Grouping by function is what produced the original distance; grouping by the moment of use is what removes it.
03 · One vocabulary across every surfaceThe same nouns mean the same thing everywhere: a unit of work is one kind of thing, whatever screen it is on. Consistency at that level is not tidiness; it is what lets someone move between two parts of the operations without relearning them.
04 · Agents and automations work in the same roomAutomation runs inside the same environment as the people it works for, on the same objects and the same vocabulary, rather than beside it in a separate tool. That is what makes an orchestration layer an operating system rather than a plugin.
05 · Designed for the second dayAn operations system is used all day, so nothing in it was allowed to be beautiful only on arrival. Alongside the information architecture the build process and the system architecture were tightened, because a system that is expensive to change does not stay wrong — it drifts, and it begins drifting the moment the team around it changes.

05 Craft & sequencing

The decisions,
and why.

Why the model follows the transactionA CRM shaped like the org chart makes the person the integration layer. A system shaped like the transaction does not — and it is also the shape that survives the team changing, which is the test any internal system has to pass.
Why two directions at onceReorganising the information and making the system cheaper to change are usually separate projects with separate owners. Run together they reinforce each other: reorganising while the build is still cheap is the only moment the reorganisation is genuinely affordable.
Why nothing here is measuredORB is a system we helped build and can show. The figures that would make it a case study belong to the people who run it, so the architecture and the reasoning are published and the reporting is left to them.
Why there is no screenshot of it hereSpec §05 asks this project to resolve into screenshots of ORB. None exist publicly and none has been drawn: a mock of an internal operating system would be the easiest lie on this page. So the scene resolves into the system itself — the six branches, connected, at rest — and the caption under the frame says exactly that.

06 The scope

The part we held

System design; workflow and information architecture; build-process and architecture optimisation; product-experience direction.

ClientFlatr — internal
StatusActive system
PublicationInternal — no public link and no public screenshot exist for this system

07 Through the method

Observe. Think.
Imagine. Launch.

OBSERVEA property transaction never happens in one system — listing, buyer and agent records each live somewhere else, so the person becomes the integration layer between them.
THINKThe deal is held together by people. The deal is the part that has to hold.
IMAGINEGive the transaction one place to live — one record from enquiry to completion, instead of the same conversation carried across four windows.
DESIGNOne vocabulary across every screen, with workflows grouped by the moment of use rather than by the department that owns them.
BUILDAgents and automations working in the same room, designed for the second day rather than for the demo.
TESTWhy nothing here is measured, and why there is no screenshot of it on this page.
LAUNCHActive system, internal. No public surface exists, so none is shown.

ORB runs a live operation. Nothing about it is published, and nothing about it is claimed.

← FLATRSONJA →All engagements