ChatGPT maintenance triage: Who owns the next step?

A maintenance ticket can be assigned and still be stuck. Someone's name is on it, but nobody has said what happens next. Or the team is waiting on an answer without knowing who should get it. A ChatGPT maintenance triage board can make those gaps visible.

In my maintenance triage walkthrough, I used three fictional requests, with no real resident information or inbox access. The demo shows how a coordinator could review who needs to act, what is holding a request up, and what information is missing.

Organize the work around what is holding it up

The board groups requests into three situations: nobody is working on the ticket, we're waiting on someone, or the ticket has been assigned without a next step or date. Those labels are more useful to me than a general summary that says maintenance is busy.

Each card should give a short explanation of the reported issue and a next human action. If we're waiting, it should identify who we're waiting on. An owner decision is different from a vendor response, and both are different from information we still need from the resident.

A ticket belongs in one group at a time. Otherwise the same issue can appear in several places and make the workload harder to read. Empty groups should still be visible, too. Knowing that nothing currently sits in one category is useful information, not a reason to hide it.

The goal is to look at the board and know where follow-up is needed. It isn't to create a second record system that competes with the one your team already uses. After reviewing a suggestion and making a decision, someone still needs to put that decision into the actual maintenance process.

Clicking around the demonstration board doesn't send a message, contact a vendor, approve an expense, or update your property-management software. Keep that distinction clear when you introduce it to the team.

ChatGPT maintenance triage still needs a person checking the facts

In the AC example, I first compare the summary with what was actually reported. Then I look at the suggested urgency and the reason for it. The question isn't whether the wording sounds convincing. It's whether we have enough information to agree with the suggestion.

A missing detail should stay missing until somebody supplies it. If the intake doesn't establish a condition, a time, or an authorization, the board shouldn't quietly fill it in. It should tell us what we need to check.

That same rule applies to draft messages. A draft can turn an undecided question into a promise if nobody reads it carefully. Before any vendor follow-up goes out, a person needs to verify who's going, what's been authorized, and whether a time has actually been agreed.

It's easy to skim a message that looks finished. That's why I want the draft visibly labeled as a draft and kept separate from the final send. The person sending it still owns the facts and commitments in it.

The prompt is part of this discipline. I ask ChatGPT to use only the information provided, flag material gaps, and distinguish reported facts from suggested triage decisions. Those instructions support the review. They don't remove the need to do it.

Safety questions and owner decisions need different treatment

The water issue in the demonstration makes the boundary easier to see. When safety or habitability is unclear, I want questions for a person to assess, not an AI decision that the situation is safe or that a particular response is sufficient.

Your existing emergency procedures and responsible people still govern the response. Don't make a review board a reason to delay an assessment or wait for an AI answer. The tool can organize the information you need to consider without becoming the authority on what to do.

The fridge request raises a different issue. If an owner needs to approve something, the card should say so. It should also make clear who's responsible for obtaining that decision. Waiting on the owner doesn't mean the ticket has no next action.

The card can show a supplied quote and spending limit. If either amount isn't available, it should say Not provided. In the draft owner message, I deliberately leave the money fields for a person to complete and check, even when an amount appears elsewhere on the card.

That's a review step, not needless repetition. A number appearing in the intake doesn't establish that it's the final quote, the relevant limit, or an approved expense. The person responsible for the decision needs to verify what the message will say.

These examples shouldn't all produce the same kind of draft. A safety question may need an assessment checklist. An owner decision may need a request for approval. A vendor follow-up may be appropriate only after the facts and authority are clear.

Tell the team where the AI stops

The phrase I use in this workflow is simple: ChatGPT drafts, we decide. Nothing auto-sends. I want the team to hear that explanation once together, then see it in the written instructions they use. The same limits belong in the hire pack for an AI agent before you give it a recurring job.

The AI can prepare a cleaner intake summary, suggest urgency with a short reason, identify what appears stuck, and draft an appropriate follow-up. The team reviews those suggestions rather than treating them as decisions already made.

Money, safety, habitability, after-hours decisions, displacement, and changes involving leases or legal issues need the appropriate human review under your existing procedures. The final communication goes through the company channel after a person has checked it.

Be specific about that handoff. If someone sees a proposed next action, who checks it? If the board flags missing information, who collects it? If the request falls outside the coordinator's authority, who receives the escalation?

Without those answers, people can react in opposite ways. One person won't use the tool because they don't trust it. Another may assume it has more authority than you intended. A clear boundary gives them a way to use the draft without surrendering responsibility for the work.

Review the workflow, not just the appearance of the board

I'd have the maintenance team review this kind of intake daily, with an owner or supervisor reviewing the broader workflow weekly. The weekly review can focus on tickets outside your established expectations rather than asking the owner to touch every routine request again.

That isn't a promise of a particular time saving. The intended result is fewer unnecessary touches and clearer follow-up. You'll need to compare what happens in your own process before claiming an improvement.

Start with a small set of composite or properly anonymized tickets you can check yourself. Compare the summaries with the source. Check whether the suggested next action is useful, whether missing information is visible, and whether the board respects the limits you gave it.

If the output looks neat but leaves the team unsure who acts next, revise the instructions. If it suggests a decision outside its role, stop and correct that boundary before using it again. The appearance of the board isn't the test. The handoff is.

The prompt is a starting point for a reviewable workflow. Keep the information appropriate for the tool, check the result, and leave the decisions with the people responsible for them.

If you're working through something like this, feel free to reach out. I'm always happy to talk through it.