Maintenance Request Triage

Classify incoming tenant maintenance requests by urgency, open the appropriate work order, and immediately escalate anything that looks like an emergency to a human property manager.

When to use

• A tenant submits a maintenance request through a portal, email, or SaaS (software as a service) ticketing system
• A request needs urgency classification (emergency, urgent, routine) before a work order is created
• A request describes conditions that could be an emergency (gas leak, flooding, no heat in freezing weather, fire hazard, lockout, security breach)
• A property manager wants a status update or summary of open maintenance work orders

Tools

• http-get
• http-post
• send-message
• create-task
• delegate-task

Playbook

1. Retrieve the new or updated maintenance request record with http-get, e.g. GET https://api.propertysoftware.example.com/v1/maintenance-requests/{id}. Auth is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials.
2. Read the request description, unit, and any attached notes to classify urgency into one of three tiers: emergency (immediate danger to health, safety, or property — gas smell, active water leak, no heat/AC in extreme temperatures, fire/smoke, break-in, elevator entrapment), urgent (significant inconvenience but not dangerous — broken appliance, clogged toilet with no backup, pest sighting), or routine (cosmetic or non-critical — squeaky door, paint touch-up, minor leak drip).
3. If the request is an emergency, immediately notify a human via send-message with the unit, tenant contact, and description, flagged as EMERGENCY, and do not wait for further workflow steps before this notification goes out.
4. For urgent and routine requests, create a work order by calling http-post against the property management platform, e.g. POST https://api.propertysoftware.example.com/v1/work-orders with unit, category, priority tier, and description.
5. If the work order requires a formal notice to the tenant (for example a late-rent or lease-violation notice tied to the maintenance issue), draft the notice text but never send it autonomously — route it via delegate-task to a human manager for review and approval.
6. Assign the work order to the correct vendor or maintenance technician queue using http-post or, if the platform only exposes a partial-update endpoint, use http-request (not covered by this skill's declared tools — escalate via create-task if assignment fails).
7. Log a create-task entry on the board summarizing the request, urgency tier, and work order ID so the team has a shared trail of open items.
8. If the SaaS integration returns 401/403 or no Integration row exists for the host, stop and use send-message to alert a human, naming the service and the scopes required.
9. Confirm receipt to the tenant with send-message (or the platform's own notification channel via http-post), stating the urgency tier and expected response window.

Failure modes

• Misclassifying an emergency as routine delays a dangerous situation — when any doubt exists about danger to people or property, default to the emergency tier and escalate immediately.
• Sending a formal legal notice (late rent, eviction warning) without manager approval — always draft and hand off via delegate-task, never post or send such notices autonomously.
• Creating duplicate work orders for the same request — check existing open work orders with http-get before creating a new one.
• Silently failing when the property management API is unreachable — always surface API errors to a human via send-message rather than dropping the request.

Done when

• The request has an urgency classification, a work order is open (or an emergency escalation has been sent to a human), and the tenant has received acknowledgment.
• Any legal or formal notice tied to the request is sitting in manager review, not sent.
• The board task reflects the current status and links to the work order ID for follow-up.