Request intake
- Entry channels
- Classification
- Emergency calls
- Link to the building
Executive summary
1. What the review found
A management company looks after several dozen stairwells and hundreds of flats. The work is split across trades that share almost no common picture: plumbers, electricians, technical staff and dispatchers each keep their own queues.
The review found that a resident request is not an object. It reaches somebody, is passed on, and is then poorly tracked: who took it, which building, which flat, how it ended. In an emergency that is the most expensive question — and precisely when it is hardest to answer.
The second layer is communication. Building-wide notices, private requests and work orders all travel the same channels, so the control desk is busy with what does not belong to it and misses what does.
| Finding | Statement |
|---|---|
| Primary constraint | A request is not addressed from the moment it arrives: building, flat, contact and nature of the problem are not always recorded, and not in one place. Ownership changes without leaving a history. |
| Recommended first step | Introduce a single request register with a mandatory link to building, flat and contact, plus category and deadline; then separate the trade queues. |
| Expected effect | A request becomes trackable from intake, emergencies are separated from routine work, closure is confirmed. Quantitative effect is assessed after rollout. |
Areas reviewed
Trades
- Plumbing
- Electrical
- Technical staff
- Building supervisors
Finance and documents
- Billing
- Payments and arrears
- History
- Internal documents
Communication
- Building-wide notices
- Direct channel to the company
- Notifications
- Voting
Starting position
2. Baseline capture of current work
The review starts by capturing how a request travels today. For each operation we record who performs it, how often, which carrier holds the data, and whether the same data is moved again. Everything else in this document rests on this table.
| Operation | Who performs it | Frequency | Where the data lives | Re-keyed |
|---|---|---|---|---|
| Taking a request by phone | Dispatcher | Continuously | Log, notepad, memory | Yes — details are asked again and written down afresh |
| Identifying building and flat | Dispatcher | Per request | A verbal question to the resident | Yes — the address is asked even of a known resident |
| Classification and priority | Dispatcher | Per request | A judgement call | Yes — criteria are unwritten, the assessment repeats |
| Passing to the responsible trade | Dispatcher | Per request | A phone call to the tradesperson | Yes — the request is retold by voice |
| Assigning work to a tradesperson | Trade lead | Daily | Own queue in a notebook or chat | Yes — the trade keeps a parallel record |
| Marking work complete | Tradesperson | On finishing the job | A verbal report to the trade lead | Yes — the result is passed on in words |
| Informing the resident | Dispatcher | On request | Ringing round the trades | Yes — status is reassembled |
| Billing for services | Bookkeeping | Monthly | Separate accounting software | Yes — flat data is entered again |
| Resolving a billing query | Bookkeeping and dispatcher | Regularly | Different channels | Yes — the query does not arrive where the bill lives |
| Building report | Building supervisor | Monthly | Manual assembly from the trade logs | Yes — data comes from four sources |
What follows from thisIn ten operations out of ten the data is moved again. The critical point is the second: if building and flat are not captured in structured form at intake, all downstream tracking is impossible in principle, no matter how many systems sit further along the chain.
Diagnostic panel
3. State of the operational system
Losses occur between taking a request and the responsible trade, and between operational work and per-building reporting.
49/100average process maturityManual reconciliation risk high
10points of re-keyingCandidates for removal
6critical data handoversNeed an owner
2priority pilot flowsRequest register + routing
Process maturity
Expert assessment on a 0–100 scale. Higher means a more resilient process.
Structure of operational risk
Distribution of recorded observations by type.
16observations
40% — scattered data32% — losses at handover28% — unclear ownership
The numbers on this demonstration panel are illustrative. In a paid review the assessments are derived from interviews, a sample of requests, observation of the control desk and an agreed 0–100 scale.
Process map
4. Current process and handover points
The chain describes the typical path of a resident request. An emergency follows the same path with an incomparably shorter allowable time. It is a process model, not a snapshot of any particular client system.
Request
The resident reports a problem through any channel.
Attribution
Building, flat, contact and nature of the problem.
Classification
Category, urgency and deadline.
Assignment
The request goes to the responsible trade.
Execution
The tradesperson does the work on site.
Confirmation
The result is recorded and confirmed.
Notification
The resident is told the request is closed.
Reporting
The data flows into the building report.
Risks at the handover points
| Handover | What can be lost | Consequence | Priority |
|---|---|---|---|
| Resident → dispatcher | Building, flat, contact, nature and scale of the problem | The request is not addressed and cannot be tracked further | Critical |
| Dispatcher → classification | Signs that it is an emergency | An emergency lands in the general queue | Critical |
| Dispatcher → trade | Details of the problem, access to the flat, resident contact | The tradesperson arrives without the necessary data and a second visit is needed | High |
| Trade → tradesperson | Priority relative to other requests | The order of work is set by the convenience of the route | High |
| Tradesperson → closure | What exactly was done, what remains, what materials are needed | The request is closed without confirmation and the problem returns | Critical |
| Closure → resident | The fact and time of closure | The resident learns the outcome only by calling in | High |
Risk heatmap
| Area | Likelihood | Impact | Detection | Result |
|---|---|---|---|---|
| Emergency request does not get the right priority | Medium | Critical | By the scale of the damage | Critical |
| Ownership changes without a history | High | High | When a complaint is investigated | Critical |
| Closure not confirmed by resident or dispatcher | High | Medium | On a repeat request | High |
| Building-wide notice mixed with private correspondence | Medium | High | On a privacy complaint | High |
| Building report assembled by hand | High | Medium | Monthly | High |
Root causes
5. Why this happens
Repeat requests, disputes over ownership and lost emergency calls share the same structural causes.
A. The request is not an object from intake to closureIt exists as a sequence of conversations. It has no shared identifier, so the question "what is happening with my request" technically has no answer — it has to be reconstructed.
B. Classification depends on a person, not a ruleCategory and urgency are decided by the dispatcher on the spot. The criteria are unwritten, so identical requests get different priority depending on who answered the phone.
C. The trades keep parallel queuesPlumbers, electricians and technical staff work from their own lists. Nobody holds a shared picture of load, so work cannot be redistributed between trades.
D. Communication channels are not separatedWhat residents settle among themselves and what the company must do travel the same channels. The control desk is busy with neighbour matters and misses operational ones.
Decision principleThis is not a place to start with a resident app. An app connected to unstructured intake increases the volume of requests without changing the ability to track them. Addressed requests and routing rules first, the resident channel second.
Responsibility zones
6. Who does what — and how much of it is moving data
The work is split across trades with no shared picture, so each keeps its own records. Below is where work is duplicated and where a role does not decide anything but retells the request onward.
| Role | What it does today | How much of that is moving data | Review observation |
|---|---|---|---|
| Dispatcher | Taking calls, classifying, ringing the trades, answering residents | Most of a shift is retelling requests by voice and collecting statuses | The request is captured once and routed by rule; the role keeps the emergencies |
| Trade lead | Keeping the trade queue, allocating to tradespeople | The parallel record duplicates the request register | The queue comes from the shared register; the role keeps allocation by skill |
| Tradesperson | Travel, doing the work, reporting to the trade lead | A verbal report instead of a mark on the request | The result is recorded on site; the role keeps the work itself |
| Building supervisor | Watching building condition, reporting, handling complaints | Monthly manual assembly of the report from the trade logs | The report is built from closed requests; the role keeps building condition |
| Bookkeeping | Billing, taking payments, chasing arrears | Re-entering flat data and answering queries in the wrong channel | The bill sits where the question about it is asked |
| Management | Resolving conflicts, decisions per building | Reconstructing what happened from conversations | The request history is available without reconstruction |
The organisational conclusion stays with the companyThe review shows which part of the work is moving data and which part is deciding. What happens with the time freed up — redistributing tasks, retraining people or changing the structure — is the owner’s call. In property management the dispatcher’s freed time usually goes into emergencies, where a person cannot be replaced.
Separating the channels matters more than any featureTwo levels of conversation — a chat per building between residents and a direct channel to the company — look like an interface detail. In practice that separation is what keeps the control desk free for what actually belongs to it. Without it, any request system drowns in neighbour discussions.
Target operating model
7. States, boundaries and rules
The request passes through explicit states. Each defines an owner, the required data and the condition for moving on.
| State | Owner | Required information | Transition condition |
|---|---|---|---|
| Registered | Dispatcher or resident via the app | Building, flat, contact, nature of the problem | Required fields filled, the request has a number |
| Classified | Rule; the dispatcher on exceptions | Category, urgency, deadline | Category assigned, deadline computed |
| Assigned | Routing rule | Trade, owner, time of assignment | Request accepted by the trade |
| In progress | Tradesperson | Start time, access to the premises | Work started on site |
| Completed | Tradesperson | What was done, what remains, materials used | Result recorded on site |
| Closed | Dispatcher or resident | Confirmation of the result | Closure confirmed, resident notified |
Boundaries of automation
The system should determine
- Which building and flat the request belongs to
- Which trade is responsible for this type of work
- Whether the category deadline has expired
- Who performs the next action and how long the request has been open
- Whether this is a repeat of the same problem
The system should not decide
- Whether a situation is an emergency when the signs are ambiguous
- Whether work counts as routine maintenance or major repair
- Whether to write off a resident’s arrears
- Who is liable for damage
- What decision a vote produced
Rules, deadlines and escalation target
In building services the deadline is the service. A rule without a deadline and an addressee means a request lives for as long as somebody remembers it.
| Rule | Deadline | Escalates to |
|---|---|---|
| A request is not registered without building, flat and contact | At the moment of intake | Blocking rule, no escalation needed |
| Emergency request not assigned to a trade | 15 minutes | Senior dispatcher, then management |
| Emergency request not accepted by a tradesperson | 30 minutes | Trade lead, then management |
| Routine request not assigned | 4 working hours | Senior dispatcher |
| Category deadline expired | The category deadline | Trade lead, then building supervisor |
| Request completed but closure not confirmed | 2 working days | Dispatcher, then building supervisor |
| Repeat request for the same problem in the same premises | At the moment of registration | Building supervisor |
Priorities and sequence
8. What to do and in what order
The sequence is built so that each stage delivers value on its own and does not require the next one to be finished.
| No. | Recommendation | Why now | Acceptance criterion |
|---|---|---|---|
| 1 | A single request register linked to the building | Without addressing, all downstream tracking is impossible | Every request has a building, flat, contact, number and history |
| 2 | Classification and routing rules | Removes the dependence of priority on who answered the phone | Category and trade are assigned by rule; the dispatcher handles exceptions |
| 3 | Separate trade queues | Removes the parallel record in notebooks and chats | Each trade works its own queue drawn from the shared register |
| 4 | Closure control | Removes requests closed without a result | Closure requires a result, a time and a confirmation |
| 5 | Resident account and separated channels | Relieves the control desk and puts the bill where the question is asked | Billing, history and resident requests sit in one place |
| Later | Voting and per-building work planning | Useful once requests and reporting are reliable | Building history is fit for planning across an agreed horizon |
Do not start with the resident appThe app is the most visible part and the most dangerous as a first step. It increases the flow of requests immediately; the ability to track them does not follow. Addressed requests and routing first, the resident channel second.
Rollout plan
These durations are indicative for a demonstration sample. A real estimate is formed after access to the request logs, the building and flat register, the work categories and the integration constraints.
| Stage | Duration | Outcome | Checkpoint |
|---|---|---|---|
| Capture and building register | 2–4 weeks | Buildings, flats, residents, work categories, deadlines, roles | Building supervisors approve the register and categories |
| Request register and control desk | 4–6 weeks | Intake, attribution, classification, number and history | A request is trackable from intake to closure |
| Routing and trade queues | 3–4 weeks | Assignment rules, per-trade work areas, deadlines | The trades stop keeping parallel lists |
| Closure control and reporting | 2–4 weeks | Confirmation, repeat requests, building report | The building report comes together without manual assembly |
| Resident account | 3–5 weeks | Billing, payment, history, notifications, separated channels | Part of the request flow arrives structured, bypassing the phone |
Measuring the outcome
9. Metrics, reporting horizon and next step
This sample claims no numeric effect. In a real review the baseline is recorded first, then the metrics are compared after an agreed period of use.
| Metric | How it is calculated | How to capture the baseline | Direction |
|---|---|---|---|
| Share of requests fully linked to a building | Requests with building, flat and contact / all requests × 100 | A sample of the request log over two weeks | Up |
| Time to assign an owner | Mean per period, tracked separately for emergencies | Manual measurement from the log and call records | Down |
| Share overdue against the category deadline | Overdue requests / all requests × 100 | A one-month sample with actual times assessed | Down |
| Repeat requests for the same problem | Repeat requests per premises / all requests × 100 | Manual analysis of the log over a quarter | Down |
| Age of open requests | Mean time a request stays open | A snapshot of currently open requests | Down |
| Share of requests with confirmed closure | Requests with confirmation / closed requests × 100 | A sample of closed requests over a month | Up |
Horizon: from the request to the annual report
A review does not end when a request is closed. Operational data has to reach per-building reporting and annual planning without being entered again — otherwise the maintenance budget is built from last year’s budget rather than from the actual condition of the buildings.
| Level | What must arrive without manual assembly |
|---|---|
| Day | Open and overdue requests, emergencies, trade workload |
| Week | Completion by trade, repeat requests, material consumption |
| Month | Report per building, billing and arrears, contractor performance |
| Quarter | Problem points per building, seasonality of requests, cost of service |
| Year | Condition of the portfolio and the maintenance budget on one data model |
If the work plan for a building is built from last year’s plan, the cause is usually not the planning but that requests do not accumulate into a history against specific parts of the building.
Questions to settle before development
- Which signs unambiguously classify a request as an emergency?
- What deadlines apply to each work category, and what are they based on?
- Who may close a request without the resident’s confirmation?
- Which resident and request data may appear in a building-wide channel?
- How are routine maintenance, emergency work and work at the resident’s cost delimited?
- What data does the accounting software accept, and in what format?
Recommended next decisionCapture two weeks of requests for a single building: the call log, trade queues, completion marks and complaints. Output: a register of categories with deadlines, a data model, a role matrix and a pilot scope for one building.
This document demonstrates the structure and level of detail of the deliverable of the “Process review” service. It is based on the mechanics of a delivered, anonymised platform for building services, is not legal, tax or industry advice, and contains no confidential client information. Maturity scores are illustrative. The mechanics — control desk, trades, resident account, voting — transfer between jurisdictions; the formal requirements for service-charge statements, budgets and owner resolutions do not, and must be modelled separately for a given country.