Back to work

One service platform, four personas and a rules engine

I defined one service-request model and a role-based rules layer so residents, frontline staff, managers and executives worked from the same state—reducing response times by 19% and complaints by 23%.

Impact: 19% faster response times

23% fewer resident complaints

One state shared across four personas
System scope: Shared service-request object

Role-based views

SLA and escalation rules

Immutable state history
Company: StarRez
Ownership: System architecture

Multi-persona UX

Operational modelling

Rules and permissions
Signals: Platform ArchitectureMulti-persona SystemsRules EngineService OperationsResidential Technology

The decision I owned

Unify the operating model

Keep one service request as the source of truth; vary the interface and permissions by role.

Fragmented resident tickets, maintenance work orders and management reporting created reconciliation delays. I decoupled the interface layer from the data model so a state change made by one persona was immediately visible to every other authorised view.

Four personas, one system

Resident: Self-service requests and real-time status.
Frontline staff: Mobile triage and direct action tools.
Manager: Command centre, allocation and escalation.
Executive: Aggregated performance and compliance.

The interfaces are different because the decisions are different. The underlying request, lifecycle and evidence remain the same.

The shared data object

I defined the request as a single primitive used by the portal, operational tools, rules engine and reporting layer. Three constraints protected integrity:

Immutable state history for auditability and accountability.
Role-based field visibility so each persona sees the right evidence and actions.
Standardised metadata so routing, reporting and escalation operate on the same terms.

The schema below is a conceptual model used to explain the architecture, not a literal production API contract.

{
  "entity_id": "req_9942A",
  "type": "maintenance",
  "urgency": "high",
  "location_ref": "BLD-A-402",
  "lifecycle": {
    "current_state": "assigned",
    "assigned_to": "staff_uid_09",
    "escalated": false
  },
  "view_permissions": [
    "resident_read",
    "staff_write",
    "manager_override"
  ]
}

Rules, permissions and control

StarRez role and permission topology
Interface	Primary persona	Read access	Write access
Resident portal	Resident	Own requests only	Create or cancel
Mobile triage / inbox	Frontline staff	Assigned requests	Status and notes
Command centre	Manager	Facility-wide	Reassign or escalate
Executive dashboard	Executive	Aggregated	None

The rules engine handled assignment, SLA targets and escalation without splitting the request into separate departmental records. Managers could override when judgement was needed; executives remained read-only.

System instances

Different surfaces, one operating system.

StarRez resident portal dashboard — **Resident portal.** Self-service status and communication drawn from the shared request state.

StarRez resident request detail view — **Request detail.** The resident sees the same lifecycle history used by staff and managers.

StarRez staff unified inbox — **Frontline inbox.** Role-filtered work queues expose only the requests and actions relevant to staff.

StarRez service request command center — **Command centre.** Managers reassign, prioritise and escalate work without creating a parallel record.

StarRez manager operations dashboard — **Operations dashboard.** Aggregated workload and service performance derived from the same object model.

StarRez SLA and escalation builder — **Rules builder.** SLA, routing and escalation logic sit above the shared lifecycle rather than inside separate tools.

StarRez executive impact and compliance view — **Executive view.** Read-only trends and compliance evidence without another reporting database.

What changed

19% reduction in response times as teams worked from one current request state.
23% reduction in resident complaints through clearer status and fewer communication gaps.
Managers gained operational control without creating a separate reporting workflow.