When no one picks up, the ticket never exists.
An AI voice agent platform that transforms how facility management companies capture, track, and resolve resident maintenance requests — from chaotic WhatsApp threads to a structured, self-operating ticket system.
The stakes
In traditional facility management, an estimated 35–40% of maintenance requests are never logged — not because residents don't report them, but because there's no reliable system to receive them. Calls go unanswered. WhatsApp messages get buried. Spreadsheets lag by days.
For FM companies managing 10–100 properties, this isn't a workflow inconvenience — it's a direct hit to resident retention. Residents are 3× more likely to decline lease renewal after two or more unresolved maintenance requests. A facility management company came to Thirtydays Studio needing more than a ticketing tool. Their ops team was drowning in calls, WhatsApp threads, and missed handoffs.
The problem
Mid-sized FM companies fail to capture resident maintenance requests reliably because intake happens across fragmented, unmonitored channels — phone calls, WhatsApp, walk-ins — with no structured data collection, resulting in an estimated 35–40% of requests being missed or unresolved within SLA, directly increasing resident churn.
What we found
Stakeholder workshops
Ops coordinators spent 2–3 hours per day manually logging calls, following up on WhatsApp, and chasing service personnel. No structured intake meant every request depended on one person's memory or inbox.
Competitive audit
Tools like Buildium, Facilio, and ServiceMax are built for enterprise property groups — heavy ERP-style systems requiring weeks of onboarding. None solve the front-door problem: getting a request into the system in the first place.
Heuristic audit
The highest failure rate was at intake — the moment a resident tries to report something. Phone calls weren't answered. Form submissions were never seen. WhatsApp went to personal phones, not shared ops inboxes.
Options considered
Option A — Resident web form + email intake
RejectedResidents don't open web portals for maintenance. Adoption rates for tenant-facing forms in residential FM are below 20%. The channel mismatch remains — residents call, not click.
Option B — WhatsApp chatbot intake
RejectedResidents call — not text — for maintenance. WhatsApp also requires personal phone numbers, creating data ownership risk. A text bot doesn't solve after-hours or urgent call escalation.
Option C — AI voice agent + ticket CMS platform
ChosenMatches the channel residents already use (phone). Eliminates human dependency at intake. Scales to unlimited properties without adding headcount.
Tradeoffs
English-only in v1
We chose English-only over full multilingual support. Residents who prefer Arabic, Hindi, or other regional languages — an estimated 15–25% in Gulf FM markets — must communicate in English. We accepted this because the primary buyer is an English-operating FM company. Shipping a working product in one language beats shipping a broken product in five. Phase 2 addresses this directly through a multilingual WhatsApp surface — same LLM pipeline, but residents pick the channel and language they prefer.
Mandatory sequential wizard, no shortcut setup
We chose a mandatory wizard over a freeform settings interface. Technical users who want to jump to a specific setting can't bypass it on first setup — adding roughly 3 minutes to initial onboarding. We accepted this because stakeholder workshops showed admins consistently skipped critical config steps when given freeform access, particularly escalation contacts and business hours. A sequential wizard prevents a live agent with no emergency escalation path.
Local numbers only, no toll-free
We chose local number provisioning only. FM companies managing properties across multiple countries cannot use one centralised number. We accepted this because the core buyer is a single-market FM operator — and one number per property is also a trust feature. Residents see their building's number, not a corporate switchboard. Multi-country enterprise is a v2 segment.
What we built
Ticket queue with status filters
The home screen is the ticket queue, not a vanity dashboard. Request totals sit at the top — total, unassigned, pending, resolved — so an ops coordinator knows the state of the building in one glance. Every row carries status, priority, channel, and owner, filterable by property and date. The single design rule: "who's responsible right now?" must always be visually answerable, which is what kept tickets from stalling in the old WhatsApp workflow.
Agent configuration
One screen to define the voice agent: name, voice profile, language, first message, and the full system prompt that governs how it collects a request and when it escalates. The prompt is editable in plain text rather than buried behind toggles — the people configuring an agent are FM ops leads, not prompt engineers, so the personality and escalation rules read like instructions to a new hire. Phone number provisioning and the knowledge base live one tab away.
Call logs, transcripts & recordings
Every call the agent takes is logged as a row with resident, location, the captured issue, duration, priority, and a one-tap recording. This is the proof layer — it's where ops verifies the agent heard the resident correctly and where call duration gets watched against the 30–40s target. Issue text is pulled straight from the transcript, so the link between what was said and the ticket that was created is never lost.
Properties & per-building rules
The agent has to know which building it's answering for. Properties is where each tower, its type, and its address get registered — the unit a resident references on a call resolves against this list, and per-property rules (escalation contacts, business hours) hang off it. Keeping properties as first-class objects is what lets one account run many buildings without one number per company becoming a bottleneck.
Staff, roles & permissions
Managers, admins, and service personnel each get scoped access — a superadmin sees everything, a service person sees only what they need to close a job. Granular permissions (view tickets, create tickets, and more) are assigned per member so the account can grow from a two-person ops team to a full FM org without re-architecting access.
Usage & call analytics
A usage view rolls calls up into the numbers an FM operator actually budgets against — total calls, total and average duration, and call volume by day, week, and month. Average call duration is the metric to watch: it's the leading indicator of whether the agent is capturing complete requests efficiently, and it sits beside subscription and billing so usage and cost stay in one place.
Design targets
The product hasn't launched yet — these are the targets we're designing against, not measured outcomes. Call duration is the primary one. A 30–40s call means the agent has captured the full request — address, issue, severity, preferred window — including any back-and-forth needed to clarify. Shorter calls usually mean an incomplete ticket; longer calls usually mean the agent should have escalated. These targets get validated with real instrumentation after the first FM pilot goes live.
What's next
Auto-assigned ticket dispatch
Phase 2 removes the manual handoff. As soon as a ticket is created, the system routes it to the next available service person matched on request type, property, skill set, and current workload — no admin in the middle. This collapses the ticket-to-assignment window from hours to seconds and is the single biggest unlock for scaling beyond ~50 properties.
Multilingual WhatsApp channel
Phase 2 adds a structured WhatsApp surface where residents can chat with the agent in any language — Arabic, Hindi, Malayalam, Tagalog. The same LLM pipeline that runs the voice agent handles translation in-flow, so ops still sees normalised English tickets. This makes the agent reachable to the 15–25% of residents who don't speak English without forcing them into voice.
Resident satisfaction loop
A post-closure WhatsApp survey — one question, 10-second response — tied to ticket close events. CSAT per service person, per property, per request type is more valuable to FM operators than any internal dashboard metric.