How to Update Guests When Maintenance Tasks Change

Written by Punn Kam, ex-Google AI engineer and Y Combinator repeat founder. He is the co-founder of Conduit, an AI agent platform built for hospitality, serving 300+ hospitality brands in 140+ languages. Last updated October 7, 2026.

To update guests automatically when a maintenance task changes, tie each guest message to a task event (the task is created, assigned, changes status, or is completed). Write what the guest should hear at each event, keep the rest internal, and let a workflow or agent send the message. Your task system has to publish those events somewhere your messaging can act on them.

Which task changes should a guest hear about?

A guest should hear about a maintenance task change when the change affects the guest's plans or comfort. The four usual moments: the issue is logged, someone is booked with a time, the work is under way if it affects them, and the work is done. Everything else stays internal.

Internal changes include a reassignment between two technicians, a parts order, a cost estimate, a note between the manager and the owner. Sending those to the guest creates noise and invites questions you can't answer yet. A guest with a broken air conditioner in July wants to know that someone knows, when it will be fixed, and that it's fixed. Write your updates around those.

How do task events trigger guest messages?

Task events trigger guest messages through triggers that fire on the task and act on the reservation it's linked to. Conduit fires four: task created, task assigned, task status changed, and task completed. The status changed trigger can be narrowed to specific statuses your workspace defines, so a move to "Scheduled" can send one message and a move to "Waiting on parts" can send nothing.

Each trigger can run a workflow (fixed steps, such as a message template) or an agent (which reads the conversation and the task and writes a reply that fits). Templates suit the confirmation that a task is logged. An agent suits the completion message, where it can refer back to what the guest originally reported.

The trigger only helps if each task carries a link to its guest. Tasks created from a guest conversation in Conduit are already linked to the property and the reservation. Tasks created by hand need that link added, or the trigger has nobody to message.

What should each message say?

Each message a guest gets about a task should say what changed and what the guest should do about it, in one or two sentences. The set below covers a typical dishwasher repair, and you can use it as fixed templates or as written instructions for an agent.

• When the task is created: "Thanks for letting us know about the dishwasher. I've logged it with our maintenance team and will update you as soon as a technician confirms a time."
• When the status moves to scheduled: "A technician is booked for tomorrow between 10am and noon. Someone will need to let them in, or reply and I'll arrange access."
• When the status moves to in progress: only if the guest needs to know, for example that the water will be off for an hour.
• When the task is completed: "The dishwasher is fixed. Let me know if anything still looks wrong."

Keep the guest's original words in mind. If they reported "the dishwasher," don't send "Work order #4412 resolved."

How do you share arrival windows without promising an ETA?

Share an arrival window only after the technician has given one, and send it from a status change instead of a guess. In Conduit you build the arrival-window update yourself as a workflow: when the task moves to a "Scheduled" status with a due time set, the status changed trigger messages the guest with that window.

Conduit dispatches work orders to cleaners and contractors by SMS or email with accept and decline links, and the response updates the task. Move the task to your scheduled status once the technician has accepted and confirmed a time, so the guest only hears about a booking that's real. If the technician declines, the task goes back for reassignment and the guest hears nothing until someone new accepts, which beats two messages with two different times.

If a window slips, change the status and send a new message, so no agent has to guess a new time from silence.

What other updates can run on task changes?

Task events drive more than repair confirmations, because many operations decisions change something about a guest's stay: when they can arrive, whether a repair goes ahead, or what you offer after an outage. The patterns below run on the same task triggers and need no extra integration.

• Early check-in after an early turnover. When the cleaning task for a same-day turnover completes ahead of schedule, a workflow can offer the arriving guest early check-in as a paid upsell in the same conversation.
• Owner approval above a cost threshold. A repair estimate over your limit moves the task to an approval status and messages the owner, and an agent reading the owner's reply moves the task forward. The guest hears about it once the work is approved and scheduled.
• Service recovery after a long outage. When a task for something the guest couldn't use (heat, hot water, Wi-Fi) completes after a set number of hours, an agent can offer a goodwill gesture from a list you approved in its instructions.

If your PMS tracks cleaning status, a fourth pattern runs on a different trigger. Conduit has no prebuilt "your unit is ready" message, but its PMS cleaning-status trigger (for Guesty and for PMSs connected through Calry) plus a short workflow sends one when the unit is marked clean.

What goes wrong when task updates don't reach guests?

Task updates fail to reach guests in three common ways when messaging and tasks run in separate tools. Each time, a person on your team ends up copying status changes from a task board into the inbox by hand, or the guest waits without hearing anything and writes in to ask.

The first is no event at all. The task tool has no webhook for the change that matters, so somebody watches a board and copies updates into the inbox. Turno's external API lists one webhook type, Project Completed, so a scheduled or started job produces no webhook a messaging tool can act on.

The second is events that nobody has wired up. Breezeway publishes 11 task webhook types: created, committed, updated, deleted, assignment-updated, started, paused, resumed, cost-updated, supply-updated, and comment-updated. The list has no separate completion event, and Breezeway's docs say it sends the task for all events and the receiving system decides which ones to process. Somebody still has to build and maintain the rules that turn each event into the right message for the right guest.

The third is a task with no guest attached. The event fires, but nothing links the task to the reservation, so there's nobody to message.

How do the main tools compare on guest updates?

The table below compares how five tools expose maintenance task changes that could drive a guest message. Each cell comes from the vendor's own page or developer docs, opened October 2026. "Not published" means I couldn't find it on their pages; the feature may still exist.

Hospitable creates tasks from check-in, check-out, and mid-stay events and sends them to teammates by email, SMS, or iCal feed; its tasks page doesn't describe guest updates on completion. For the step before this one, see how to turn guest messages into maintenance tasks.

Do you need messaging and tasks in one system for this?

Guest updates on task changes need two things, task events and a link from each task to its guest, and one system provides both. With separate tools, plan for webhook work on one side, rules on the other, and a person covering whatever the integration misses.

Conduit's Full Suite package, at $48 per unit per month, adds tasks and workforce, scheduling and dispatch, and agentic operations workflows to everything in Guest + Devices (see pricing). The case for running both together is in guest messaging and operations in one system, and the wider tool landscape is in the best hospitality operations platforms and our Operto review.

FAQ

Operators who want guests updated automatically when a maintenance or cleaning task changes usually ask the questions below, from which events to use to how to avoid flooding a guest with updates. Each answer stands alone, so you can read the one that matches your setup.

How do I notify a guest when maintenance is complete?

Trigger the message from the task's completion event. In Conduit, the task completed trigger runs a workflow or an agent that messages the guest on the linked reservation. With a separate task tool, you need an event for completion and a rule in your messaging tool that acts on it.

Which task status changes should go to the guest?

Send the guest the changes that affect their plans: the issue is logged, a technician is booked with a time, work is under way if it disrupts them, and the work is done. Keep reassignments, parts orders, and cost discussions internal.

How do I tell a guest when the technician will arrive?

Tell the guest the booked window once the technician has confirmed it, from a task status change. In Conduit you build this as a workflow, so when the task moves to a scheduled status with a due time, the status changed trigger messages the guest with that window.

Can a completed cleaning task trigger an early check-in offer?

Yes. A workflow on the task completed trigger can check whether a same-day turnover finished early and offer the arriving guest early check-in as a paid upsell in the same conversation.

What if my task tool only sends a webhook when a job is completed?

You can automate the completion message but not the earlier updates. Turno's API, for example, lists one webhook type, Project Completed, so scheduling and start updates need a person or a different source of events.

How do I keep automatic updates from spamming guests?

Filter the status changed trigger to the few statuses a guest cares about, and send nothing for the rest. One message per meaningful change is enough.