An operations system for fifteen buildings and 10,000+ assets.

Every repair created more messages, but almost no organisational memory.

Daftarkhwan runs roughly fifteen coworking locations serving thousands of members, with more than ten thousand physical assets: HVAC, electrical, furniture, internet and plumbing. Coordination lived in WhatsApp. A fault could start in a branch group, move to operations, get escalated to facilities, be discussed with finance and vanish into chat history once fixed. The next time the same asset failed, it looked like a new problem.

The business did not lack information. It lacked structured history.

Every facilities issue as a structured record attached to the asset.

One operational queue replaced the fragmented reporting. Each incident attaches to a physical asset, moves through a defined workflow, keeps its history and feeds future maintenance decisions.

The software worked. The workflow assumptions didn’t.

The first version behaved like a normal ticketing system and asked reporters for priority, assignee and due date. Almost everyone marked their own problem urgent, most didn’t know who owned the fault, and every due date became “today”. Tickets also showed total elapsed time, not who owned the delay, so a technician waiting days on finance or a vendor looked slow.

The first version digitised the existing process. It had not yet redesigned it.

We removed decisions from people when the system could derive them from the asset.

A reporter really knows two things: what is broken, and what it looks like. Priority now comes from asset and failure type, and routing from branch, category, department and ownership. Diagnosis, finance approval, vendor response, procurement and repair are tracked separately, so delay lands on whoever owns it.

Rules handle priority, routing, SLAs, escalation and permissions. AI handles titles, repair-history summaries, recurring-fault patterns and explaining repair-versus-replace recommendations. Spending decisions stay with a person.