At 19:10 on a Friday, a guest in your two-bedroom flat sends four words: the oven is broken. There is a chicken out of the fridge and six people arriving at eight.
Those four words describe at least four different situations. The oven may be working perfectly and waiting for the clock to be set, because many electric ovens with a digital timer will not heat until it is. The bulb may have failed and the guest has read a dark oven as a dead one. The cleaner may have left the last guest's roasting tray on the bottom shelf, in which case the problem is smoke. Or the element has genuinely gone, and you are calling an appliance engineer while the guest orders a takeaway.
Four situations, four people to call, four costs, four levels of urgency, and one message that distinguishes none of them. Triage is the work of getting from the message to the category before you spend anything. It usually gets done badly, in ninety seconds, by someone already doing three other things.
This article covers the four categories a fault report resolves into, the questions that separate them without interrogating the guest, what a report should carry before a contractor reads it, and the repeat-fault pattern that turns a repair into a purchase.
The Four Reports Hiding Behind One Message
Every appliance complaint from a guest lands in one of four buckets, and the wording of the message is rarely a reliable guide to which.
Guest error. The appliance works; something between the guest and the appliance does not. The clock is unset, the child lock is on, the induction hob is in key-lock, the dishwasher's supply tap was closed at the last turnover. Nobody owns this but you, and it costs one clear instruction delivered fast.
A consumable. The oven bulb, the extractor filter, the remote's batteries, dishwasher salt, a gas bottle, a vacuum bag. Nothing is faulty; something has run out. This belongs to whoever restocks the property, which is usually the cleaner with a standing list rather than a trade with a van.
A cleaning miss. The dishwasher was never run, the lint trap is full so nothing dries, the hob was not degreased so it smokes on first use, there is no detergent. The guest experiences all of these as a broken appliance. The owner is the cleaning team and the fix is a return visit, not a repair.
A genuine fault. An element, a pump, a control board, a door seal, or an error code that survives a power cycle. This is the only category that needs a trade, and the only one billed at a callout rate.
You will have your own distribution across the four. The operational point is narrower: three are resolved by information, a part or a cleaner, and only the fourth justifies the call that starts a bill.
Who Owns Each Category, and What the Wrong Call Costs
| Category | What it usually looks like | Who owns it | What it costs | How fast it moves |
|---|---|---|---|---|
| Guest error | Functional appliance; a setting, lock or sequence in the way | Nobody, one instruction | Two minutes of attention | Immediately; the guest is standing in front of it |
| Consumable | Bulb, filter, batteries, salt, gas bottle, vacuum bag | Cleaner or host, on the restock list | The part | Next turnover, unless it is a smoke alarm |
| Cleaning miss | Dishwasher not run, filter full, tray left inside, no detergent | Cleaning team | A return visit, plus goodwill | Same day; the guest is in the property |
| Genuine fault | Pump, element, board, seal; a code that survives a reset | A trade | Callout plus parts | Depends whether the property still functions |
Misclassification fails differently in each direction. Call a genuine fault guest error and the guest works through three instructions that were never going to help, gets steadily more annoyed, and writes the review from that feeling rather than from the eventual repair. Call guest error a genuine fault and you pay your market's minimum callout to have a qualified person press the clock button, a bill that is embarrassing rather than large, until it happens monthly.
The cleaning miss is the category most often filed in the wrong place, because it arrives sounding mechanical and gets routed to maintenance. A dishwasher full of the last guest's plates is a turnover failure, not a maintenance ticket, and it should reach the person who did that turnover rather than a handyman. Moving guest-originated facts across that boundary is its own problem, covered in how guest issue reports should flow directly to your cleaning team.
Getting the Facts Without an Interrogation
The information that separates the four categories is not complicated. Extracting it from a guest who is hungry, cold or already irritated is the hard part, and the usual failure is a list of six questions that reads like a warranty claim.
Ask what the guest can see, not what they can diagnose. "What does the display show?" is answerable. "Is the heating element working?" is not, and asking it invites a confident guess that sends you down the wrong path.
Lead with the fix, then ask. Put the most common resolution in the same message as the question, so guest error resolves itself before you have spent any attention on it. "Two things usually do it: hold the clock button until the time flashes and set it, and check the dial is not on the timer symbol. If not, send a photo of the front panel."
Ask for a photograph, not a description. One photo of the control panel and one of the rating plate (the sticker inside the door frame or on the back) takes ten seconds and gives you the error code and the exact model. That second photo is the most useful artefact in the process: it is what lets a contractor bring the right part on the first visit.
Two more questions earn their place. Did it work earlier in your stay? separates something that arrived broken, which points at the turnover, from something that failed mid-stay, which points at the appliance. And what have you already tried? stops a contractor repeating your first three steps, phrased neutrally, because a guest who feels accused of breaking something stops reporting anything at all.
The standing sequences behind all this belong in a library you write once and reuse, organised by the symptom a guest reports rather than by the system an engineer would name. That is the subject of appliance troubleshooting for vacation rental guests, and it is what makes the first message instant rather than thoughtful.
One complication: this whole exchange assumes you and the guest share a language. Diagnostic instructions are exactly the kind of text where a small translation error changes the meaning: a wrong preposition sends someone to the switch beside the door rather than behind it. If that describes your guest mix, read how to answer guests in languages you do not speak before relying on a translated troubleshooting script.
What the Report Should Contain Before a Contractor Reads It
A contractor quoting from "the oven is broken" is quoting for an unknown, and the price reflects it. One reading a complete report can often bring the part, which is the difference between one visit and two.
- The property, the unit, the floor, and how they get in: key, lockbox code, or someone who will be there.
- The appliance: make, model and serial from the rating-plate photo, where it sits, roughly how old it is.
- The symptom in the guest's own words, and anything you observed yourself, kept separate from each other.
- The error code or display state, photographed rather than transcribed.
- What has already been tried, so nobody repeats it.
- When it started, and whether it is constant or intermittent. Intermittent faults need a longer visit and a warned contractor.
- Whether the property is occupied, the access window that creates, and the next arrival time.
- Who authorises spend and the ceiling below which the contractor should simply proceed. Someone who has to call you before buying a €40 part turns one visit into two.
- Whether the appliance is under warranty or on a service contract. A visit you pay for on a machine still in warranty is avoidable.
One item belongs there and almost never does: has this appliance been attended before, and what did the last engineer write.
The Third Report Is a Purchase Decision, Not a Repair
A washing machine is reported in March: not draining. You pay a callout, the engineer clears the pump filter, everyone moves on. In May a different guest reports it stopping mid-cycle: another callout, a new drain pump. In July a third guest reports a burning smell and you replace the machine anyway, after three callouts, one pump, and a guest who spent an evening of their holiday with wet laundry.
Each report was handled competently in isolation. The failure is that nobody put them in a row. Guest conversations are organised by guest, invoices by date, and the appliance (the thing actually failing) has no record of its own anywhere in the operation.
The fix is a log keyed to the appliance rather than the conversation. One line per event: date, property, appliance, symptom, who attended, what was done, what it cost. A spreadsheet is fine. What makes it useful is a threshold set in advance: two events on one appliance is a coincidence, three inside twelve months is a replacement decision. The arithmetic usually agrees, since three callouts plus parts on a mid-range machine will often exceed the price of a new one; run it with your own contractor's rates rather than treating the example as a number.
Two costs never appear on the invoice. One is review risk: the guest in stay three knows nothing about stays one and two and simply experiences a property where the washing machine does not work. The other is the shadow pattern: faults guests work around instead of reporting. The second hob ring nobody uses, the extractor that has not run in a year. Those never enter the log and surface later as a sentence about tired fittings. Only the cleaner catches them, and only if someone asked them to look.
Where the Triage Actually Happens
Triage is time-sensitive in a way maintenance rarely is. The questions that separate guest error from a real fault are only cheap if they are asked within a minute or two, in the channel the guest already has open. Asked at 21:30, when you finally reach your phone, they land on a guest who has stopped cooking and started drafting.
This is where a guest-messaging layer sits, and it is worth being precise about which half of the job it does. Welco is a WhatsApp AI assistant for vacation rental hosts. It answers verified guests (a phone number matched to a reservation) from what you have loaded, including appliance manuals, so the standing first step goes out immediately rather than when you are free. Voice notes are transcribed, which matters when a guest would rather describe a noise than type it, and it replies in the guest's own language across 30-plus languages. When the answer is not in what you loaded, it raises an escalation with an urgency level by WhatsApp, email or push, and you can take the conversation over from the dashboard, with replies translated both ways. A question it could not answer is saved once you answer it and reused, so the second guest to hit the same quirk gets the instruction the first one waited for.
What it does not do is the operational half. It does not raise a work order, schedule a contractor, hold the appliance history, or decide which of the four categories a report belongs to. That judgement is yours, dispatch belongs to your ops tooling or your phone, and the cleaning side belongs to whichever scheduling platform your crew already uses. Triage is one lane of a wider coordination problem; the rest of it is in the guide to managing cleaning crews across multiple properties.
What Triage Cannot Do
Triage classifies. It does not diagnose, and treating a classification as a diagnosis is how the process fails.
A category assigned from a text message is a hypothesis, not a finding. Symptoms overlap across all four buckets: no hot water is a boiler fault, a tripped breaker, a cleaner who switched the immersion off, or a guest using a tap that runs cold for longer than they expected. A misrouted report costs a callout fee for work that did not need doing, and repeat offences cost the contractor's patience, harder to buy back than the fee.
The guest is not a reliable witness to their own mistake, and that is not dishonesty. By the time someone messages you they have pressed several things in an order they cannot reconstruct, and they genuinely do not know which was wrong. "I didn't touch anything" is usually sincere and frequently wrong. Build the triage so it does not depend on a guest reporting their own actions correctly.
Some reports should skip triage entirely. A smell of gas, water through a ceiling, an electrical burning smell, anything involving a guest's safety: that is an evacuation and an emergency call, and the sorting happens afterwards. The decision tree for those is in handling after-hours guest emergencies, and it belongs above your triage rather than inside it.
The repeat-fault log only works if the discipline holds. A manager who records two events in three never sees the third-report pattern, and a log with gaps is worse than none: it produces a confident "this is the first time" that is wrong.
Two limits on the automated part. An assistant can only deliver the instruction you loaded; with no manual for that oven it escalates rather than diagnoses, which is the correct failure but still a failure from the guest's side. And a fast, well-written acknowledgement creates a strong impression that something is being handled, so if the escalation lands where nobody is watching, you have bought a worse outcome than silence: a guest who waited politely because they were told someone was on it.
The Operational Picture
Most maintenance spend in a small portfolio is not lost on hard repairs. It leaks through reports nobody sorted, callouts nobody needed, and one appliance failing three times without anyone seeing the three together. Welco's part is narrow and upstream: catching the report as it is sent, asking the first questions in the guest's language, and putting a flagged escalation in front of a human instead of leaving it in a thread. If that is the part breaking for you, request a demo and test it on your own properties in the simulator first.