Making HotSOS work for the front office

A guest at the desk once told me the air conditioning in her room had not worked all afternoon, and I could see in her face that she expected the usual answer, a promise and a shrug. Instead I opened HotSOS, logged the issue with her room number and the words she used, marked it a guest-facing priority, and told her engineering had it and I would follow up within the hour. Her shoulders came down. Not because I had fixed the room, but because for the first time in her stay a problem she raised had visibly gone somewhere. That is what the tool is for, and most desks use maybe a third of it.

HotSOS is a service and maintenance dispatch platform, and the plainest way to describe it is a system that refuses to let a request disappear. Someone speaks a problem, and the system turns it into a work order with a location, an owner, and a running clock. For a front office team that spends all day catching requests it cannot personally solve, that is not a nice extra. It is the difference between a property that remembers and one that forgets. Here is how it actually works, and how to use it so it earns its place.

What does HotSOS actually do?

At its core, HotSOS takes an event and gives it structure. A guest reports a broken thermostat. Instead of a note on a sticky pad or a verbal handoff to whoever walks by, the desk creates a task. That task carries a room number, a category, a priority, and a timestamp, and the system routes it to the department that owns that kind of work. Engineering sees it, picks it up, works it, and closes it, and every one of those steps leaves a record.

The value is in the structure, not the technology. A spoken request has no owner and no memory. The moment your shift ends, it is gone unless you happened to tell the right person. A HotSOS task has both an owner and a memory built in. It cannot quietly evaporate on a shift change, because it lives in the system until someone closes it, and the system keeps asking to be closed. That single property, that a task nags until it is done, is why a well run house feels like it remembers guests, and a poorly run one feels like it forgets.

A spoken request has no owner. A logged task has a name, a location, and a clock. That is the entire difference.

How the front desk should use it

The desk is mostly a creator and a monitor of tasks, not a closer of them. Your job splits into two halves. First, log the request cleanly enough that it routes to the right place and the person who picks it up understands it without calling you. Second, watch the task until it closes, so when the guest asks, or when you decide to follow up on your own, you are speaking from real status instead of a guess.

The logging half is where most of the quality lives, and it is the half people rush. A task that says "AC issue, room 812" routes fine, but a task that says "guest reports AC not cooling since 2pm, room warm, guest in room now, VIP arriving tomorrow" tells engineering everything it needs to prioritize correctly and fix it right the first time. The detail you enter in ten seconds saves a callback, a second trip, and a second complaint. This is the same discipline the desk uses everywhere, the same care that makes a clean shift handover hold, and it fits into the broader set of screens an agent touches that I walk through in the front desk tech stack, explained.

What a good task entry includes

• The exact location. Room number, and if it is a public area, the specific spot. A vague location is the top reason a task bounces back.
• The guest's own words. What they reported, not your paraphrase, so the person fixing it solves the real problem.
• The right priority. A guest in the room now is not the same as a preventive note for later. Honest priority keeps the urgent things urgent.
• Any context that changes the timing. A VIP arrival, a checkout deadline, a guest who is upset. The person picking it up cannot see the lobby you are standing in.

Logging a task, step by step

When I train a new agent on HotSOS, I do not start with the buttons. I start with the shape of a good task, because the buttons are easy and the judgment is not. Here is the order I have them run every time a guest raises something, using that afternoon AC call as the example:

1. Capture the location preciselyRoom 812. If it were a public space, I would name the exact spot, such as the third-floor ice room, not just "third floor."
2. Pick the correct categoryHVAC, not a generic maintenance bucket, so it routes to the tradesperson who can actually fix it rather than bouncing through a dispatcher first.
3. Write the guest's words"AC not cooling since 2pm, room feels warm," rather than my summary of "AC problem." The specifics tell engineering whether to bring a part.
4. Set an honest priorityGuest in the room now, on a warm afternoon, is guest-facing and urgent. I do not inflate every task to urgent, because that is how urgent stops meaning anything.
5. Add the timing contextNote the VIP arriving into that room type tomorrow, so engineering knows a lingering fix has a hard deadline.
6. Confirm it routedI watch that the task landed with engineering and did not sit unassigned, then I tell the guest a real timeframe.

That whole sequence takes under a minute, and it is the difference between a fix that happens once and a fix that takes two trips because the first tech showed up without the right part. The gotcha I coach against hardest is the generic category. A task filed under the wrong bucket routes to the wrong queue, sits, and then everyone blames the system when the real problem was ten seconds of careless entry.

The clock is the point

What separates HotSOS from a notepad is that it measures time. Every task carries a response clock, and the property can see how long requests take to get picked up and closed. For a manager that is a performance tool. For an agent at the desk it is something more useful in the moment: it means you can tell a guest exactly where their request stands. Not "someone should be up soon," but "engineering picked this up eleven minutes ago and it is being worked now." Guests forgive a problem far more easily when they can feel it moving.

That measured response is also how a property learns where it is weak. If bathroom fixes always run slow, the reports show it, and a manager can look at staffing or parts rather than blaming individuals. The desk feeds that learning every time it logs a task honestly. Fudge the priority or skip the entry and the data lies, and a house that runs on lying data cannot fix the thing that keeps generating complaints. Using the system straight is not bureaucracy. It is how the building gets better at the thing you keep apologizing for.

HotSOS or a PMS trace: which do you use?

This trips up new agents, because both are ways of not forgetting something. The difference is what the reminder is attached to and who needs to act. A PMS trace is a note tied to a reservation inside the property management system. It is perfect for guest record reminders that the desk itself will handle, like a note to offer a late checkout or to confirm a preference at arrival. It travels with the guest's stay and shows up when you pull the reservation.

HotSOS is the right tool when the job needs an owner in another department and a measured response, like a repair, a delivery, or a cleaning request. The rough rule I teach is this: if the desk will act on it and it belongs to the guest's record, trace it in the PMS; if someone else has to act and the clock matters, log it in HotSOS. The two systems are cousins, not rivals, and a strong front office uses both fluently. I go deeper on the reminder side of that in trace and task systems guests never see, because the traces are half of how a property remembers a guest at all.

Side by side, the split is easy to hold in your head at the counter:

Match the request to the correct column and it lands with the right owner and the right clock the first time, which is the whole game.

A quick way to decide

• Needs another department and a repair or delivery, with a response time that matters: HotSOS.
• A reminder the desk itself will handle, tied to a specific reservation: PMS trace.
• Both, when a repair also needs a followup with the guest at arrival: log the task and trace the followup.

The mistakes that quietly kill the system

A dispatch system does not fail loudly. It degrades one careless entry at a time until the team stops trusting it. These are the patterns I watch for and correct on the spot:

• Everything marked urgent. When every task is a priority, the queue loses its meaning and the genuinely urgent room waits behind a lightbulb.
• Paraphrasing the guest. "Bathroom issue" could be a slow drain or a flood. The vague version guarantees a second trip.
• The generic category. Filing under a catch-all bucket sends the task to a dispatcher instead of straight to the right trade, adding a hop and a delay.
• Logging and forgetting. Creating the task is half the job. An agent who never checks status cannot close the loop with the guest.
• Working around it when busy. The moment a request skips the system, it loses its owner and its clock, which is exactly when it fails.

Why teams work around it, and why that fails

Every property has agents who skip the system when it is busy. A guest asks for extra towels, the agent radios housekeeping directly, the towels arrive, and no task was ever created. It feels faster, and sometimes it is. But it only works when nothing goes wrong. The moment housekeeping is slammed and the towels do not come, there is no record, no clock, and no way to know the request was even made. The guest calls back annoyed, and the agent who took the original request is gone for the day.

The workaround also starves the property of the very data that would fix the recurring problems. If half the requests never enter the system, the reports show a building that runs cleaner than it does, and nobody fixes the towel shortage that keeps happening at four in the afternoon. A tool that is used only when convenient is not really a system. It is a habit some people have, which is exactly the state I describe in the larger stack piece, where a request that lives only in someone's memory is not a system yet. The point of HotSOS is to make sure it never has to.

Building the habit on the team

Getting a desk to use HotSOS every time is a leadership problem more than a training one. Everyone can learn the buttons in an afternoon. The harder part is making logging the default even when the lobby is full and radioing someone directly feels faster. The way I have gotten teams there is by closing the loop out loud. When a task I logged gets resolved and I get to tell the guest exactly what happened and when, I make sure the team sees that moment, because it is proof the extra ten seconds bought something real.

I also refuse to reward the shortcut. When a request that was radioed instead of logged falls through, the honest debrief is not that housekeeping failed. It is that the request had no owner and no clock, so of course it could fall. Naming that plainly, without blame, teaches the lesson faster than any policy. Over time the desk internalizes that the system is not extra work sitting on top of the job. It is the job, done in a way that survives your shift ending.

Closing the loop is part of the job

One habit separates a desk that merely logs tasks from one that actually serves guests: closing the loop back to the person who raised the problem. Logging the task is the start, not the finish. The finish is the moment you tell the guest their issue was resolved, or you check in when it is taking longer than promised. HotSOS makes this possible because the status is right there. You do not have to guess or chase anyone down. You can see the task closed and go find the guest, or call the room, and say the thing that turns a complaint into loyalty: it is done.

Most agents skip this step, and it is the most valuable one. A guest whose problem gets fixed silently is satisfied. A guest who is told, by name, that the thing they raised has been handled feels cared for, and those are different feelings that produce very different reviews. The system hands you the information for free. All it asks is that you use it to go back to the guest instead of assuming they noticed. I tell my teams that a task closed in HotSOS is only half closed until the guest knows, because the guest never sees the system, only whether the property remembered them.

The tool is only as good as the entry

Everything about HotSOS comes back to the quality of what the desk puts in. The routing, the timing, the reports, the guest followup, all of it rests on an agent taking a few seconds to log a clear, honest, complete task. Get that right and the system does exactly what it promises, which is to make sure nothing a guest raises ever quietly disappears. Get it wrong and you have an expensive platform full of vague tasks that route slowly and teach the property nothing.

So if you take one thing to the desk, take this: treat the task entry as the real work, not the paperwork after the work. The guest in front of you does not need you to fix the thermostat yourself. They need to feel that their problem went somewhere with a name on it and a clock running. HotSOS gives you the power to make that true every single time, on every shift, long after you have gone home. Use it fully, log it cleanly, and watch how quickly a property stops being a place that forgets and becomes a place that remembers.

Questions from the desk

What is HotSOS used for in a hotel?

It is a service and maintenance dispatch system. It turns a guest request or a facility issue into a tracked work order with an owner, a location, and a clock. Instead of a request living in one person's memory, it becomes a routed task the whole team can see, follow, and close.

How does the front desk use HotSOS?

The desk mostly creates and monitors tasks. When a guest reports a problem or asks for something, the agent logs it, and the system routes it to the right department. The agent then watches the task until it closes, so a followup is based on real status rather than a guess.

What is the difference between HotSOS and a PMS trace?

A trace is a reminder attached to a reservation inside the PMS. HotSOS is a dispatch platform built to route and time a task across departments. Traces are good for guest-record reminders the desk handles. HotSOS is better when a job needs an owner in another department and a measured response.

What makes a good HotSOS task entry?

A good entry has an exact location, the guest's own words rather than a paraphrase, an honest priority, and any context that changes the timing, such as a VIP arrival or an upset guest in the room now. Those four things let the task route correctly the first time and get fixed without a callback.

How does HotSOS measure response time?

Every task carries timestamps from creation to pickup to close, so the system can show how long a request took to be acknowledged and resolved. Managers use that data to find slow spots in staffing or parts, and agents use the live status to tell a guest exactly where their request stands instead of guessing.

Why does logging a task in HotSOS matter?

Because a spoken request has no owner and no record. Once it is in HotSOS it has both. The task cannot quietly disappear on a shift change, the response time gets measured, and the desk can tell a guest exactly where their request stands instead of promising and hoping.

Why do teams work around HotSOS, and why does that fail?

Agents skip the system when it feels faster to radio a department directly, and sometimes it is. But a request with no task has no owner, no clock, and no record, so it fails silently the moment the other department gets busy. It also starves the property of the data that would fix recurring problems, because reports show a building running cleaner than it actually does.