Client Experience Management

The problem

A third-party apartment manager grows by winning management contracts from institutional owners. That work lived across a shared spreadsheet of owner contacts, a second spreadsheet of active pitches, a folder of executed agreements, and the memory of the people doing it.

The questions leadership actually asked — how many doors did we win this year against how many we lost, which owners have we not spoken to in sixty days, which pitches are stalled — each required someone to go and assemble the answer by hand.

What it does

One system covering the whole relationship lifecycle: owner and broker accounts with their contacts and portfolios, a pitch pipeline through eight stages, the management agreements that result, per-owner health assessments, conference and meeting planning, and the activity log underneath all of it.

• Pipeline — pursuits by stage, with units and fee value attached.
• Scoreboard — acquisitions minus dispositions by year, in doors and in annual fees, against goal.
• Client health — a six-dimension assessment per owner, tracked over time so movement is visible.
• Events — conference meeting planning, with the pursuits attributable to each one.

Design decisions worth naming

The scoreboard is derived, never entered

Every figure on the year view — acquisitions, dispositions, net doors, net annual fees, win rate — is computed from the underlying agreement rows. There is no place to type a total. That is deliberate: the moment a summary can be edited independently of its components, the two drift, and the summary is the number people quote.

Anything that can be typed in two places will eventually disagree in two places.

Likely dispositions are modelled, not assumed

An owner signalling they may sell is not yet a disposition, but pretending it is not happening produces a forecast nobody trusts. Agreements carry a likely flag, and every scoreboard figure has an “including likely” counterpart, so the optimistic and the realistic view sit side by side rather than one quietly replacing the other.

Guest access without a second application

Owners occasionally need to see their own records and nothing else. Rather than building a separate portal, access is granted per record and enforced by row-level security in the database — so a guest session physically cannot query rows it was not granted, regardless of what the client asks for.

What is in the demo

A fully synthetic book of business: 180 owner and broker accounts, 130 properties across eight markets, live pursuits at every pipeline stage, executed agreements spanning several years, health assessments with history, and an activity feed.

It is generated to be internally consistent, which is harder than it sounds — an owner's stated portfolio size has to square with the properties attached to it, an activity cannot predate the account it belongs to, a meeting cannot fall outside its own conference, and every aggregate on screen has to equal the rows behind it. A verifier asserts those invariants on each build.

The demo signs you in as a member of the business-development team, mid-week, with her own tasks and pursuits in progress.