From Resident Complaint to Results Management Can See

1. The problem

In residential communities, resident requests and complaints arrive through scattered calls and office visits:

• Front-desk pressure. Around a third of requests are walk-ins, and they consume the team's time.
• Lost data. A request gets solved and closed without ever becoming a number anyone can measure.
• Invisible effort. The volume and quality of the facility team's work never reach senior management.
• Decisions without evidence. Equipment is bought from catalogues and contractors are chosen by relationship, not by their actual track record.

2. Approach

1. Understand the domain. Studied the challenges facility leaders describe and the standard FM KPIs: SLA compliance, time to resolve, preventive maintenance ratio, resident satisfaction.
2. As-Is → To-Be. Mapped today's path (call or visit → manual log → verbal follow-up) and designed the target path (message → automatic classification → routing → ticket → live dashboard).
3. Data design. A data model that links each request to its building, category, asset and vendor, so every ticket can be analysed later.
4. Prototypes. Generated realistic simulated data with Python and built the interactive prototypes with Claude.

3. The solution: two layers

Layer 1 — Capture and automate

1. The resident sends the request on WhatsApp, the channel they already use.
2. An n8n workflow receives the message, classifies it, sets the priority and routes it to the right team.
3. The request is logged as a ticket, and the resident receives a confirmation with its status and target resolution time.
4. An operations dashboard shows requests, maintenance, assets and vendors live.

Layer 2 — Intelligence and decisions

5. Analyse thousands of requests and work orders to find patterns.
6. Turn the patterns into three decisions: - Smarter procurement: the real failure rate of every equipment model. - Insurance recovery: catch latent-defect patterns before the mandatory 10-year Inherent Defects Insurance (IDI) cover in Saudi Arabia expires. - Evidence-based contracting: a vendor scorecard that links rework to defect patterns.

4. The prototypes

Simulated data: a fictional community (3 towers + villas, 500 units) over 12 months: 1,400 requests, 600 work orders, 250 critical assets, 18 vendors.

5. Design decisions

• WhatsApp instead of a new app. Higher adoption and zero training for residents.
• n8n for automation. Fast to build, easy to change, and integrates with WhatsApp and databases without custom development.
• Layer 1 before intelligence. Analysis is worthless before the data is structured; the first layer produces the fuel for the second.
• KPIs that serve management, not technology. Every chart on the dashboard answers a management question and points to a decision.

6. Expected value

• Fewer walk-in requests, moved to a digital channel.
• Higher SLA compliance through instant classification and routing.
• The facility team's workload and quality made visible to management in numbers.
• Procurement, contracting and insurance claims based on an actual record.

7. Limitations and what I would do differently

• The figures come from simulated data; the next step is a pilot on one building with real data to measure actual impact.
• Automatic classification needs its accuracy measured against human classification before it is fully trusted.
• Resident data is personal; any real deployment needs hosting compliant with Saudi Arabia's Personal Data Protection Law.
• I would start with short interviews with the front-desk team before designing, to confirm the most frequent request types.