Jely All insights
Facilities management··9 min read

From WhatsApp fault report to the right facilities work order: an intake and triage checklist

A WhatsApp fault report often arrives before anyone has opened a work order. “Water by reception” may be useful to the sender but insufficient for a portfolio helpdesk deciding which building, asset and response team are involved. Fast acknowledgement matters; so does avoiding a confidently misrouted job.

This guide covers the intake stage: clarify the report, check existing work, choose the right destination and confirm what has been recorded. The 7 October facilities-management work-order guide covers the subsequent coordination, contractor handover and completion stages.

Why the first report is rarely a complete instruction

Multi-site portfolios reuse names: “main reception”, “Block B” and “the goods lift” may each describe several locations. A group name may identify a contract rather than a building. Forwarded photographs can lose their captions, and yesterday's video can look like evidence of today's fault.

The report may also contain an assumed diagnosis: “pump failed” could mean a noise, standing water or a control-panel warning. Record the observation separately from that interpretation. Several people may report one disruption, while similar wording can describe unrelated faults.

Words such as “urgent” and “again” are useful context, not formal priority or proof of recurrence. Intake should preserve them as the reporter's description while an authorised role applies the organisation's prioritisation policy.

Build a minimum intake packet

Ask only for information needed to identify and route the issue. Use short follow-up questions rather than requiring a long form before acknowledging a report. Keep unknown fields explicit; never infer a site or asset from the last conversation alone.

  • Reporter and contact route: who observed the issue, their relationship to the site and an approved way to clarify it.
  • Exact site and local location: portfolio site reference, building, floor, room or approved area identifier.
  • Asset or service: the visible asset reference, if safely available, or the affected service and precise location.
  • Observed symptoms: what the reporter saw, heard or experienced; label any proposed diagnosis as unverified.
  • First observed: date and time with the relevant time zone, distinguishing observation from message receipt.
  • Current impact: who or what is affected, whether service is unavailable or intermittent, and any known alternative.
  • Photo/video context: capture time, location, asset, what the attachment shows and whether it depicts the current condition.
  • Safety and access constraints: reported hazards, restricted areas, access windows and actions already taken under approved procedures.

Do not ask someone to enter a restricted plant room, operate equipment or approach a hazard to complete the packet. Avoid unnecessary personal details, access codes or identifiable bystanders in attachments. Use approved restricted channels for sensitive information.

Choose one of five triage outcomes

1. Clarify before routing

If location, affected service or impact is unclear, keep an owned intake item with a specific question and next review time. Missing information must not prevent an immediate escalation required by policy. “Awaiting clarification” should never mean an unattended message.

2. Link to existing work

Search the authorised helpdesk or work-order system using site, asset, symptoms and timing. If the report concerns an existing incident, preserve it as an additional observation against that record, including any changed impact. Confirm the link rather than silently discarding the message as a duplicate.

3. Create a new record

When identity and routing requirements are sufficient and no matching record exists, create the work order through the approved process. Preserve uncertainty in its description. If an asset identifier is unavailable, use the permitted location/service route rather than inventing an asset or selecting a similar one.

4. Route outside facilities scope

A report may belong to IT, a landlord, security or another service owner. Explain the destination and obtain accepted ownership through the agreed handoff. Where scope is disputed, retain a named intake owner until responsibility is resolved; forwarding alone is not acceptance.

5. Escalate under existing policy

Route a reported safety concern, major disruption or unclear high-impact situation to the designated duty role. Record when escalation was accepted and any authorised instruction. Ordinary WhatsApp messages are not continuous monitoring or emergency response. Direct emergencies to established emergency procedures rather than asking people to wait for a chat reply.

Check duplicates without combining different faults

Similar wording is a search clue, not an identity match. Compare the precise site, local area, asset or service, symptom, observation period and existing incident scope. Two reports of “no water” on different floors may share a cause, but that relationship requires review rather than automatic merging.

Keep the original reports and reporter routes distinguishable even when linked. New evidence of a wider impact should reach the incident owner. A previously closed job requires a recurrence decision under the organisation's process: reopen it or create a linked new record, rather than assuming “again” settles the question.

If reports concern different assets, retain separate faults unless an authorised coordinator establishes a parent incident. Record why a link was made, who reviewed it and unresolved differences. When uncertain, leave a candidate relationship for review.

Keep priority and the formal record authoritative

Only authorised people or approved policy rules assign formal priority. Intake records the reported impact and escalates uncertainty; it should not promise a response class or attendance time from the reporter's wording. Apply actual monitored hours and fallback arrangements.

The approved CAFM, helpdesk, FSM or work-order system remains authoritative for job identity, priority, ownership, status and closure. Any automation or integration must be configured and tested for matching, permissions, supported fields and failure handling. Where none exists, use a controlled manual handoff: a named person creates or updates the record, verifies the saved result and returns its reference.

Track provisional intake separately until accepted triage is confirmed. An intake reference is not a work-order number. If the system is unavailable, follow the approved temporary-log process and assign reconciliation; do not announce a formal record that has not been created.

A fictional example: “Lift not working again”

This example is invented to illustrate intake, not a customer deployment or result.

  1. Receive: “Lift not working again” arrives in a portfolio WhatsApp group. The intake coordinator acknowledges it, takes ownership and asks which site, lift and current impact. They do not assume a previous building discussed in the group.
  2. Clarify: the reporter identifies site P-014, East Building, passenger lift L-02. At 08:15 Europe/London, the landing button illuminated but the lift did not arrive. The reporter says nobody is known to be trapped; the coordinator does not treat that statement as a safety assessment. Any trapping or immediate danger must use established emergency procedures.
  3. Separate fact from diagnosis: the reporter adds “probably the motor again”. The packet records the button behaviour as the observation and the motor explanation as unverified. No one is asked to inspect machinery. A permitted photograph shows the landing indicator, with location and capture time.
  4. Check duplicates: an open record at P-014 concerns goods lift L-01. Similar wording and a shared site do not make it the same fault. A closed L-02 job is retained as relevant history, not automatically reopened.
  5. Create and route: under this fictional portfolio's process, the coordinator creates a new L-02 work order, links the previous history and passes the reported impact to the authorised triage role. That role applies the local priority policy; the saved assignment is verified.
  6. Acknowledge: “Recorded as WO-731: P-014, East Building, L-02; landing call registered but lift not arriving. Assigned to the facilities triage queue. Next update by 09:00 Europe/London. Follow the site's existing lift-outage instructions; use the emergency procedure for immediate danger.” The reference and update time are illustrative, not a service promise.

Return a useful acknowledgement

Once accepted triage is verified, return the work-order reference, recorded summary, owner or accountable queue and next-update expectation. Explain whether the report created new work or was linked to an existing incident. If clarification remains open, say so and name the next action instead of implying dispatch.

Include only safe interim instructions already authorised by policy. Do not invent technical advice, promise attendance or imply resolution. Check that the reply reaches the original reporter through the permitted route, without exposing another reporter's details.

A phone-friendly intake template

  • Reporter / reply route: [approved contact]
  • Site / exact location: [reference, building, floor, area]
  • Asset / service: [identifier or description; unknown if necessary]
  • Observed / first noticed: [symptom; date, time, zone]
  • Impact / constraints: [affected service; reported safety/access issue]
  • Evidence: [permitted photo/video reference and context]
  • Triage: [clarify / link / create / route / escalate]
  • Owner / record / next update: [verified destination and time]

Test at one site before expanding

Choose one site, trained intake staff and a named review owner. Test a vague location, missing asset, duplicate observation, separate fault with similar wording, out-of-scope request and safety escalation. Verify manual handoff and any configured integration, including failed creation and unclear acknowledgements.

  • Clarification rate: reports needing follow-up divided by all reports received.
  • Duplicate-link rate: reports confirmed as linked to existing incidents divided by all reports received; review incorrect links separately.
  • Time to accepted triage: elapsed time from receipt to verified acceptance by the appropriate role or queue; show still-pending reports separately.
  • Misrouted reports: count and proportion sent to an incorrect site, asset or service owner.

Agree definitions and coverage hours before measuring. Review cases, not just totals: a higher link rate is not success if distinct faults are merged. Correct the questions and routing rules before extending the pilot.

Connect the report to the right work

Jely helps service businesses oversee and connect WhatsApp communication with internal workflows while people remain in familiar tools. For facilities intake, start by mapping the questions, triage authority, record handoff and acknowledgement—not by assuming automatic CAFM/FSM write-back. The useful outcome is a report the responsible team can identify and accept, with uncertainty still visible.