Automate Maintenance Triage and Technician Dispatch

Most property management companies rely on the built-in work order modules within their Property Management System (PMS) like AppFolio or Buildium. These tools are great for logging and tracking, but their automation is limited to simple, keyword-based rules. The system cannot distinguish between a low-priority "dripping faucet" and a high-priority "water dripping from the ceiling onto a power outlet."

Consider this scenario: a tenant submits a request through the portal at 10 PM on a Friday. The message says, "The heater is making a weird buzzing sound and I smell something funny." A keyword-based system might categorize this as a non-emergency HVAC ticket to be handled Monday morning. An experienced property manager knows the combination of "buzzing" and a strange smell could indicate a serious electrical fault or gas leak, requiring immediate attention. By the time a human reads that ticket hours later, a dangerous situation could have escalated.

Connecting a third-party tool is not a clean solution. While some applications offer better notifications, they do not solve the core triage problem. They still require a human to read the message, interpret the tenant's language, assess the true urgency, and then manually select and contact the correct technician from a separate list. This manual gap introduces delays, risks misinterpretation, and consumes hours of staff time that could be spent on resident relations or owner reporting.

The structural problem is that PMS platforms are built as systems of record, not as real-time decision engines. Their APIs are designed for batch updates, not for the event-driven architecture needed to instantly parse a message, apply complex logic, and trigger an external action. You cannot run a custom Python model inside AppFolio to analyze text nuance, which is why your team is stuck acting as human middleware between the tenant's request and the technician's dispatch.

The engagement would begin with an audit of your current maintenance process. Syntora would map every intake channel, review 500 historical maintenance tickets to understand your specific request patterns, and document your dispatch rules for every trade and emergency level. This discovery phase produces a detailed architectural plan and confirms the exact logic the AI agent will use before any code is written.

The core of the system would be a FastAPI service deployed on AWS Lambda. When a new maintenance request arrives, it triggers the service. The service sends the raw text to the Claude API with a carefully engineered prompt to extract the issue category, location within the property, and an urgency score from 1-5. This structured JSON output, which takes about 800ms to generate, is then processed by the FastAPI logic. The system queries a Supabase database of your approved technicians, filtering by trade, availability, and service area to find the optimal match. Pydantic models are used to validate all data at each step, preventing errors.

The delivered system operates autonomously in the background. For requests scored 1-4 on the urgency scale, the system can automatically create a work order in your PMS, dispatch the job to the selected technician via SMS, and log the action. For the highest-urgency requests (5/5), it can be configured to create the work order but also send an immediate, high-priority alert to a property manager for a final human verification before dispatch. The entire process, from receiving the tenant's message to dispatching a technician, typically completes in under 3 seconds. Hosting costs for this serverless architecture are usually under $50 per month.