How I Used n8n to Build an AI-Powered Dispatch System for a 300-Property Airbnb Management Company

A behind-the-scenes look at replacing a manual, error-prone process with a deterministic AI pipeline — and the lessons learned along the way.

The Problem: 300 Properties, One Overwhelmed Operations Team

Running a short-term rental business at scale is harder than it looks from the outside.

When you manage 300 Airbnb properties, guest issues don't trickle in — they flood. A broken AC in unit 47. A clogged drain in unit 203. A missing key fob in a building across town. Every one of those issues lives inside a guest conversation thread somewhere in your property management platform — buried in a stream of check-in questions, review requests, and casual back-and-forth.

For this property management company, the process of identifying and acting on those issues was entirely manual. A team member would read through guest conversations, decide whether an issue required a dispatch — meaning a physical visit from an employee or contractor — and then log that ticket in Breezeway, the company's field operations platform.

It worked. Until it didn't.

At scale, manual processes accumulate friction. Tickets got missed. Entries were inconsistent — different team members used different language, categorized things differently, and logged different levels of detail. The operations team was spending hundreds of hours per month just identifying problems, before a single contractor had even been called.

The opportunity was clear: the information was all there, inside those guest conversations. The challenge was extracting it reliably, at scale, without adding headcount.

The Solution: A Data Pipeline, Not an Agent

When I set out to solve this, the instinct might have been to build an AI agent — something autonomous that reads conversations, makes decisions, and creates tickets end to end without human involvement.

I went a different direction, and I believe that choice was a primary driver of the system's success.

I built an AI-driven data pipeline.

The distinction matters. An agentic system is flexible but opaque — it can be hard to understand why it made a particular decision, and correcting errors often means prompting your way around problems. A data pipeline is structured, sequential, and deterministic. Each step produces an observable output that can be inspected, tested, and corrected independently.

For a system that would be triaging real guest issues across 300 properties — where a missed dispatch could mean a guest spending the night without AC — determinism and debuggability weren't nice-to-haves. They were requirements.

Here's how the system was built.

The Architecture

Tools and Integrations

The system was built in n8n, an open-source workflow automation platform, and connected to several external APIs:

• Guesty — the property management system where all guest conversations live

• Breezeway — the field operations and task management platform where dispatch tickets are created

• Slack — the team's primary communication tool, used for human-in-the-loop (HITL) approvals

• Supabase — a Postgres-based backend used for data storage, conversation state tracking, and deduplication

• OpenAI — the AI layer responsible for parsing conversations, classifying dispatch requests, and drafting Slack messages for manager review

• Retool — used to build internal dashboards for reporting and visibility

n8n's custom API connection system was central to making this work. The platform's flexibility allowed all of these services to be wired together without forcing everything into a pre-built integration that didn't quite fit. That flexibility is genuinely one of n8n's most underrated strengths.

How the Pipeline Works

Step 1: Pull and monitor guest conversations from Guesty

The pipeline runs on a recurring schedule, pulling new and updated guest conversations from the Guesty API. Conversation state is tracked in Supabase to ensure each message is processed once and only once — no duplicate tickets, no missed updates.

Step 2: AI classification with OpenAI

Each conversation is passed to OpenAI with a structured prompt designed to answer one key question: Does this conversation contain a guest request that requires a physical dispatch?

The model isn't just doing sentiment analysis or keyword matching. It's reading the full context of the conversation and making a judgment about whether something is broken, missing, or needs hands-on attention. If a dispatch is identified, the model also extracts the relevant details: the nature of the issue, the property, urgency signals, and any relevant context from the guest's messages.

Step 3: Draft a Slack message for manager review

Rather than automatically creating a Breezeway ticket, the system drafts a structured Slack message summarizing the identified issue and sends it to the appropriate manager for review. This is the human-in-the-loop step — the point where a real person confirms that the AI's classification is correct before anything gets logged.

The Slack message includes the core details of the guest request, a link to the original conversation in Guesty, and simple approve/reject controls. The manager reviews it in seconds. If they approve, the ticket is created automatically in Breezeway.

Step 4: Ticket creation in Breezeway

On approval, the pipeline calls the Breezeway API to create a structured, consistently formatted dispatch ticket. Because the AI extracts and standardizes the key fields, every ticket looks the same regardless of which guest wrote the original message or which manager processed it. This was a significant improvement over the manual process.

Step 5: Logging and reporting in Supabase and Retool

Every conversation processed, every classification made, and every ticket created is logged to Supabase. A Retool dashboard surfaces this data for the operations team — showing open dispatches, classification accuracy over time, and trends by property or issue type.

Why a Data Pipeline Beat an Agentic Approach

This is worth spending time on, because it runs counter to a lot of current AI tooling enthusiasm.

Agentic systems — where an AI model reasons through a task and takes actions autonomously across multiple steps — are powerful, and the right tool for certain problems. But they introduce variability that's hard to manage in a production operations context.

In a pipeline, every step is inspectable. If the system misclassifies a conversation, you can look at exactly what input the model received and why it responded the way it did. You can adjust the prompt for that step, reprocess the conversation, and verify the fix worked — all without touching the rest of the system.

In an agentic setup, errors can emerge from the interaction between multiple model calls, tool uses, and reasoning steps. Triaging those errors is significantly more complex.

For this use case — classification and ticket creation, not open-ended reasoning — a well-designed pipeline gave us nearly all the power of an agentic approach with a fraction of the debugging surface area. The system is AI-driven, but it behaves predictably. Managers knew what to expect from it, which made adoption far smoother.

The Results

The impact was measurable and immediate.

Dispatch coverage across all 300 properties. The operations team is no longer relying on someone manually reading every conversation. Every guest thread is reviewed systematically, and nothing falls through the cracks.

Hundreds of hours saved per month. The manual identification process was eating significant team bandwidth. That time is now redirected to actually resolving issues rather than finding them.

Dramatically more consistent ticket quality. Because the AI extracts and formats ticket information in a standardized way, Breezeway now has clean, consistent entries across all properties. That consistency makes downstream operations — scheduling, contractor coordination, reporting — significantly easier.

A reliable HITL layer. Managers aren't just rubber-stamping AI decisions — the Slack review step adds genuine oversight without slowing things down. Most reviews take under a minute. And because the system flags its classifications explicitly, managers quickly develop a sense of where the AI is confident and where it needs a closer look.

Lessons Learned

Start small and scale deliberately

The system was initially rolled out across fewer than five properties. This was not a technical limitation — it was a strategic choice, and the right one.

Starting small kept the feedback loop tight. When the AI misclassified something, it was easy to spot, investigate, and fix before that error was propagated across 300 properties. It also made it easier to keep the operations team engaged without overwhelming them during the early stages.

The temptation to deploy immediately at full scale is real, especially when the technology is working well in tests. Resist it. Production data surfaces edge cases that test data never will.

Keep the operations team in the loop — throughout, not just at launch

The most technically correct system in the world will fail if the people using it don't trust it.

Getting ongoing feedback from the operations team was not a nice-to-have — it was a core part of the build process. They knew the domain. They knew what a real dispatch request looked like versus a guest venting frustration. They knew which property types generated which kinds of issues.

That knowledge shaped the prompts, the classification logic, the ticket fields, and the Slack message format. Systems built in isolation from the people who use them tend to solve the wrong problem elegantly.

n8n's flexibility is a genuine competitive advantage

Most automation platforms optimize for common use cases. Connecting a form to a spreadsheet, sending a notification when something changes — the standard playbook.

This was not a standard use case. It required orchestrating four external APIs, a vector-adjacent classification step, a custom HITL approval flow, and structured data logging — all as part of a single coherent workflow.

n8n's custom API node system made all of this possible without requiring the workflow to be broken across multiple tools or platforms. That flexibility is underappreciated. For teams building custom operations tooling, it's one of the strongest arguments for n8n over more opinionated automation platforms.

Final Thoughts

The automation industry has a tendency to reach for agents when pipelines would serve better. Agents are exciting. They feel powerful. But power without predictability is hard to operate in production, especially when real guests are experiencing real problems in real properties.

This system works because it's designed around what the problem actually requires: reliable classification, consistent data entry, and a lightweight approval layer that keeps humans in control without burdening them.

The right AI system isn't always the most autonomous one. Sometimes it's the one that earns trust steadily, surfaces the right information at the right time, and gets out of the way.

Interested in building similar automation systems for property management or hospitality operations? This architecture — connecting your communication data to your field operations platform through an AI classification layer — applies across a wide range of operational contexts. The specifics change. The principles don't.