Automating Work Order Intake and Triage From End to End

Every maintenance operation I have walked into has the same bottleneck, and it is almost never the technicians. It is the front door. Requests pour in through a portal, an email alias, a phone that rings all day, a WhatsApp group, a building management system throwing alarms, people stopping the supervisor in a corridor, and inspectors writing findings on paper. Someone in the middle re-keys all of it, guesses a priority, and picks a name. Automating intake and triage is really about deleting that someone as a single point of failure. This is the end-to-end recipe I use.

Map every channel a request actually arrives through

Before you automate anything, you map reality, not the process on the wall. Sit with the helpdesk for two days and write down every way a request physically enters. In a typical mixed portfolio I find seven live channels:

• Self-service portal:structured, but only the disciplined users touch it.
• Email:the real default, unstructured, often a forwarded thread with no asset named.
• Phone:the agent captures it, so quality depends entirely on the agent.
• WhatsApp or chat:fast, informal, and completely off the record unless you bridge it.
• BMS / SCADA alarms:machine-generated, high volume, and prone to floods.
• Walk-up:the corridor conversation that never becomes a work order.
• Inspection findings:rounds, audits, and PM callbacks that spawn corrective work.

The mistake is to automate each channel separately. You end up with seven mini-processes, seven priority scales, and no single place to see the backlog. The whole game is to normalise all seven into one queue.

Two channels always cause the most argument, so deal with them deliberately. WhatsApp is where half your real requests already live, whether the process allows it or not, so bridge it rather than banning it: a shared number that a bot or an inbox rule turns into structured intake beats pretending the group does not exist. BMS alarms are the opposite problem, a firehose that can flood the queue in seconds during a plant trip. Put a debounce and a severity filter in front of them so only actionable, sustained alarms create requests, and let the informational chatter stay in the BMS where it belongs. If you skip these two, your clean queue drowns on day one.

Design one intake funnel into a single queue

Every channel points at one normalisation layer. That layer does three jobs: it captures the raw request, it enriches it into a common shape, and it drops it into a single work request queue. Whether the enrichment logic lives in your CMMS inbound rules or in a middleware layer like Microsoft Power Automate does not matter for the design. The shape does.

The funnel is only as good as the contract it enforces. Nothing enters the queue without a required minimum data set. If a channel cannot supply a field, the funnel asks for it, defaults it, or flags it for a human, but it never lets a blank through. My non-negotiable minimum:

• Requester identity and a callback route.
• Location resolved to a real building, floor, and room or zone code.
• Asset where one applies, matched to the asset register, not free text.
• Request type from a controlled list (see work order types in a CMMS).
• Symptom or problem from your failure-code vocabulary, not a paragraph.
• Channel and timestamp, stamped automatically for later analysis.

The hardest field to enforce is location and asset, because free-text location is where automation quietly dies. "AC not working, second floor" cannot be routed by any engine on earth. So the funnel resolves location against a hierarchy: a QR code on the door, a room picker in the portal, a geofence, or a lookup that maps the requester to their default building. Where an asset applies, the same discipline binds it to the asset register by tag or barcode, never by typed description. That one constraint, structured location and structured asset, is what lets every later rule reason instead of guess.

Get this contract right and triage becomes arithmetic. Get it wrong and every downstream rule is guessing. I have watched teams spend a fortune on a routing engine and then feed it blank asset fields, and the engine did exactly what you would expect: it shrugged and dumped everything in a general pool for a human to sort, which is the very job the project was meant to delete.

Turn context into priority with triage rules

Triage is the decision that assigns a priority and, by extension, an SLA clock. Humans do it inconsistently because they weigh mood, who shouted loudest, and whatever they remember. A rule engine does it the same way every time. The inputs I combine are asset criticality, request type, and the SLA tier the location or contract carries. The output is a single priority band.

This is a starting matrix, not gospel. The point is that the logic is explicit, testable, and identical for a P1 whether it arrived by alarm or by corridor. When a client wants a formal service-management vocabulary behind these bands, I map them to the priority and impact model in ITIL , so the maintenance queue speaks the same language as the wider IT and service desk.

Kill duplicates before they clog the queue

The fastest way to lose trust in an automated queue is duplicate flooding. A chiller trips, the BMS fires an alarm, three tenants report it too hot, and a technician walking past logs it as well. That is five records for one fault. Automated triage will happily route all five. So the funnel needs a dedupe check before anything reaches triage.

My rule is a three-key match inside a time window:

• Same asset (or same location where no asset is named), and
• Same location node down to the room or zone, and
• Within a time window tuned per asset class, commonly 30 to 120 minutes.

When all three match an open request, the newcomer is attached as an additional report on the existing record rather than opened as a new one. Requester count goes up, work order count does not. Tune the window carefully: too wide and you merge genuinely separate faults, too narrow and the flood gets through. I start conservative, watch the merge log for a fortnight, and adjust per asset type.

What must be true in the CMMS before auto-assignment

This is the section most automation projects skip, and it is the one that decides whether they survive contact with reality. Auto-assignment, the step where the system picks not just a priority but an actual crew, only works if the data it reasons over is clean. Two structures have to be right first.

1. A clean craft-and-crew model.

The system needs to know who does what and who is available. That means real craft definitions (mechanical, electrical, HVAC, plumbing, BMS), crews mapped to those crafts, shift calendars, and coverage by site. If your CMMS has one generic craft called "Maintenance" and every technician sits in it, auto-assignment has nothing to reason with. It will assign work to a pool and you are back to a human sorting it.

2. A working skills matrix.

Beyond craft, the routing needs to know competence: which technicians are certified for high-voltage work, permit-to-work holders, vendor-trained on a specific chiller, night-shift qualified. A skills matrix that is populated and maintained is what lets the engine send the fire-pump fault to someone allowed to touch a fire pump. An empty skills matrix means every rule collapses back to craft alone.

So the honest sequence is: clean the asset register, build a real craft-and-crew model, populate a skills matrix, tidy the failure codes, and only then switch on auto-assignment. Skip a step and the automation amplifies the weakest link. There is no shortcut, and any vendor who tells you their AI removes these prerequisites is selling you the demo, not the deployment. For a wider view of where automation genuinely pays off, my workflow automation buyer's guide covers what to buy versus build.

Metrics that prove it worked

If you cannot measure the before, you cannot claim the after. I baseline four numbers for a month before touching anything, then track the same four. These are the ranges I typically see on a mixed CAFM portfolio once intake and triage are automated and the foundations above are in place.

Watch reassignment rate hardest. It is the truth serum for your craft-and-crew model and skills matrix. If auto-assignment sends work out and humans keep bouncing it to someone else, your routing data is wrong no matter how slick the front end looks. A falling reassignment rate is the single clearest proof that the plumbing underneath the automation is sound.

A word on how fast to expect these numbers to move. Time to acknowledge and percentage triaged without a human touch improve almost immediately, within the first week, because they depend only on the funnel and the rules being switched on. Reassignment rate and first-time-fix lag by a month or two, because they depend on the craft, skills, and failure-code data being genuinely clean, and that cleaning is ongoing work. If someone promises you all four numbers on go-live day, they are describing a demo environment, not a live portfolio. Set the expectation early so nobody reads the slower metrics as failure when they are simply maturing.

Putting it together

End-to-end intake and triage automation is not one clever feature. It is a chain: map every channel, funnel them into one queue with an enforced minimum data set, dedupe on asset plus location plus time, triage on explicit rules, and auto-assign only after the CMMS foundations are real. Do it in that order and the system will carry the routine ninety percent while surfacing the genuinely hard cases to people. Do it out of order and you get faster chaos.

A note on independence: I am not affiliated with, and receive no commission from, any of the products or standards mentioned here. Power Automate and ITIL are named as examples I have worked with, nothing more. The design in this article is vendor-neutral and works the same whether your rules live in a native CMMS engine or a middleware layer.