Maintenance request software: how requests come in, what makes them complete and who replies

What a maintenance request is

It is a request made by someone outside maintenance. It may be a breakage (“the hand dryer in the second-floor toilets will not start”) or a job (“we need a whiteboard hung in the boardroom”). In large products it is called a service request and is the step before the work order: someone reviews it, approves it and turns it into a planned task. In a small company that middle step does not exist and the request is already the task.

That is why a search for “maintenance request software” mixes two products. One is the intake module of a CMMS, usually a portal. The other is a tool devoted to just that: collecting, handing out and answering. What comes afterwards, once the request is a job with materials and hours, is explained in work order management; if what reaches you is mostly breakages, in fault management software.

The six channels a request comes in through

Each channel shares out the effort in its own way. Whatever is saved for the requester is paid for by the receiver, and vice versa.

The first three put the information in order in exchange for asking the requester to go through a procedure. The next two ask for nothing and leave nothing. The last one tries to keep the good of both sides, and depends on there being something behind the number that acts as the form when one is needed.

What makes a request complete

A request is complete when the technician can turn up with the right tool without ringing anyone first. Four details are enough:

• Where. “The toilets” is no use in a building with nine. Floor, room or office number; and if it is an appliance, which one.
• What is wrong. In the words of whoever sees it: “dripping underneath” and “no water coming out” send different people.
• A photo. It saves the diagnostic visit. The plumber who sees the model of the cistern brings the part first time.
• How urgent. Not according to the requester, who will always say very, but according to what the organisation set beforehand: a leak is urgent; a loose skirting board is not.

There is a fifth detail that nobody fills in and that the channel must bring with it: who is asking, so they can be answered. The portal knows it from the user; WhatsApp, from the phone the message comes from; the anonymous form and the call do not.

With a form, the temptation is to make twelve boxes compulsory so that nothing is missing. The opposite happens: people stop asking that way. It works better to demand the minimum and let the system ask only for what it finds lacking.

Who sorts them: triage

Between the request and the technician there is a decision: whether it belongs to maintenance or to cleaning, whose job it is, whether it can hold until Monday and whether it is the same one two other people already sent. That is triage, and it is done in three ways:

• A person. The maintenance manager, reception or the office reads each request and passes it on. It works while that person is there; during holidays the inbox overflows.
• Fixed rules. Each category has a recipient: plumbing to such-and-such a company, electrics to the staff technician. It is quick, but forces the requester to pick the right category from a drop-down.
• Automatic reading. The product reads the text, works out category and urgency and routes it. The requester classifies nothing; a person should be able to correct the destination.

Whichever the method, ask two things. First: what happens to the request nobody picks up, whether it sits in a queue until someone looks or alerts a superior once the deadline passes. Second: what becomes of urgent requests out of hours, because an inbox does not ring at two in the morning.

How the person who asked finds out

It is the most neglected half of the process. Someone who has asked for something and heard nothing does one of three things: asks again, and now there are two requests; rings, and somebody loses ten minutes finding out how it is going; or stops asking and makes do on their own. A well-run request answers three times:

• On receipt, with a number or a reference that can be used to ask later.
• When someone accepts it, with a rough date: today, tomorrow, next week.
• On closing, so the requester can say whether it was really sorted.

In a portal those answers exist, but you have to log in to look for them, or they go to an email address that floor staff never open. Look at how the reply reaches someone who does not work sitting at a computer.

Which channel suits which organisation

No channel is right for everybody. It depends on where the requester is at the moment they notice:

• Offices with employees at a screen. A portal or a form fits, because the computer is already on. More in maintenance software for offices.
• Buildings with tenants or clients who ask from outside. You need a portal per tenant, with its permissions; that is the territory of facility management platforms.
• Residents of a block of flats. They ask the managing agent, who chooses the channel; it is covered in issue reporting for residents' associations.
• Teams on their feet and on shifts (dining room, kitchen, housekeeping, shop, courts). What cannot be requested with the phone in one hand gets requested out loud. Here the message wins.
• Factories with operators on the line. They usually already have a CMMS and its request screen next to the machine.

Where Bedel fits, and what it does not have

Bedel takes requests through a single channel: the business's WhatsApp. It is best to start with what that rules out. Bedel has no request portal, no web form and no QR codes, and it does not read any mailbox. If your people ask from a computer, or you need outsiders to be able to ask, it is not your tool.

What it does do is treat each message as a whole request. The people on the site's list write, by typing, with a picture or by voice. Bedel gives it a number and a time, and when it is not clear where the problem is, it asks in that same chat. It then sends it to the technician or outside company it belongs to, who reads it on their WhatsApp and installs nothing. The requester gets a message with every change: received, accepted, resolved. What the site defined as urgent rings the on-call phone whatever the hour; what goes past its deadline unanswered moves up to the superior. Each request keeps three dated moments (when it was asked, when it was accepted and when it was closed) and the lot can be downloaded as an Excel sheet. Separately, a monthly WhatsApp reminder tells whoever runs maintenance which dated inspections are about to fall due. How it looks on site, in incident management on WhatsApp.

And since Bedel is not a CMMS, the request goes no further than that:

• It does not turn it into an order with materials, labour hours and costs.
• It does not attach it to an appliance's record, because there is no inventory.
• It does not attach or keep inspection certificates.
• It does not send it to another product: there is no connection to a CMMS or to any other software, only the Excel export.
• It does not add it to those of other sites: each site is a separate account, with its own number.
• It does not accept requests from customers, guests or residents who are not on the site's list.

Data is hosted in the European Union. If you are after the full product, start with maintenance software; if you are unsure whether to install an application or not, with maintenance app.