Skip to main content
Operations → Service Requests → /service-requests A service request is a piece of work to be done on a unit or a property: a leak, a broken lock, a lift fault, a scheduled repair. It is the operational counterpart to the financial modules — the record of what was wrong, who fixed it, when, and what it cost.

How requests arrive

Logging a request

1

Add the request

Service Requests → Add.
2

Identify the location

The unit or block. Attribution matters — it decides whose cost this is and whether it is recoverable from a tenant or an owner.
3

Identify the reporter

The tenant or staff member who reported it, so follow-up has an addressee.
4

Describe the problem

Write what was observed, not what you assume the cause is. “Water on the kitchen floor” ages better than “burst pipe”.
5

Set category and priority

Category routes the work; priority sets the expectation. Be honest about priority — if everything is urgent, nothing is.
6

Attach evidence

Photos at the point of reporting settle most later disputes about scope and condition.
7

Save

The request enters the queue for triage and assignment.

Triage and assignment

1

Confirm it is real and correctly located

A request against the wrong unit sends a contractor to the wrong door.
2

Decide who does it

In-house staff, or a vendor. Assign it explicitly — an unassigned request is an unowned request.
3

Set the due date

Against your service-level commitment for that priority.
4

Tell the reporter

A tenant who knows the job is assigned stops calling. See Communications.

Working a request

Status moves through the lifecycle as work progresses — typically open → in progress → completed, with the request’s history recording each transition. Along the way, record:
  • Notes — what was found, what was done.
  • Costs — parts and labour, so the true cost of a unit is visible.
  • Vendor — who attended.
  • Attachments — before and after photos, invoices, sign-offs.

Cost and recovery

A service request that costs money should end in an expense attributed to the right unit or block. That attribution is what lets the cost:
  • appear in the property’s cost reporting;
  • flow into the owner’s statement where the owner bears it;
  • be recharged to a tenant where the lease makes them liable, as an invoice line.
An expense recorded without unit or block attribution never reaches an owner statement. The cost silently stays with you — the single most common leak in managed-property economics.

Scheduling and planned maintenance

Recurring work — servicing, inspections, statutory checks — is driven from the asset maintenance schedule and from scheduled tasks, rather than from someone remembering. Planned work raised this way arrives in the same queue as reactive requests, so one list shows everything outstanding.

Views and reporting

The list supports grid and kanban views — kanban by status is the natural shape for a work queue. Service request reports (/reports/service-request-reports) answer:
  • What is outstanding, by age and priority?
  • Which units generate the most work?
  • Which categories dominate — and is that a maintenance problem or a specification problem?
  • How long are we taking, against our commitments?

Closing a request

1

Confirm the work is actually done

Photos, a sign-off, or a tenant confirmation — not just the contractor’s word.
2

Record the cost

Close the financial loop while the detail is fresh.
3

Tell the reporter

Closure without notification generates a duplicate request within a week.
4

Close

Set the final status with a resolution note.

Common problems