Turning fifteen WhatsApp threads into a structured operations platform — incident reporting, asset-linked repair history, derived priority and routing, blocker attribution, preventive maintenance and repair-versus-replace analysis.
Daftarkhwan operates roughly fifteen coworking locations across Pakistan, serving thousands of members and managing more than ten thousand physical assets — HVAC, electrical, furniture, internet, plumbing and general facilities.
Operational coordination lived primarily inside WhatsApp. Branch conversations, operations threads and repair discussions created activity without creating durable operational memory.
I worked with the team to turn that into a structured operations platform: incident reporting, asset-linked repair history, automatic priority and routing, blocker attribution, preventive maintenance, repair-versus-replace analysis, and selective use of AI.
The goal was not to build a ticketing system. It was to give the organisation operational memory.
Facilities teams were repairing air conditioners, generators, internet connections and furniture every day. The problem was how that work was recorded.
A fault could begin in one WhatsApp group, move into operations, get escalated to facilities, be discussed with finance, and disappear into chat history once fixed. The next time the same asset failed, it looked like a new problem.
That made prioritisation, routing, recurring-fault detection, maintenance planning, repair-cost accumulation and performance measurement unnecessarily difficult. The business did not lack information. It lacked structured history.
The organisation remembered incidents as conversations instead of remembering them as events attached to assets.
The first solution was to replace fragmented reporting with one operational queue. A member or employee reports an issue, and the system creates a structured ticket — title, description, priority, assignee, due date, asset, location, status, owner and activity history.
Each incident enters the system, attaches to a physical asset, moves through a defined workflow, retains its history and contributes to future maintenance decisions.
If every repair were captured properly, the company could finally reason across time instead of managing one incident at a time.
The first version behaved like a conventional ticketing system. It asked reporters for priority, assignee and due date. All three produced poor operational data.
Almost everyone marked their own problem urgent.
Reporters often did not know which technician, department or vendor owned a fault.
Asked when something should be fixed, users naturally chose today.
A technician could finish diagnosis quickly, then wait days for finance, procurement, a vendor, parts or access. The ticket showed total elapsed time, not who owned the delay.
The common thread was not poor user behaviour. The system was asking people questions they were not qualified or incentivised to answer accurately.
The first version digitised the existing process. It had not yet redesigned it.
The breakthrough was separating what the reporter genuinely knew from what the organisation already had. The reporter really knew only two things: what is broken, and what the problem looks like. Most of the remaining workflow could be derived.
I defined rules based on asset and failure type, so urgency stopped being a claim and became a property of the equipment.
Branch, category, department, technician pool and ownership determine where the ticket goes.
The user primarily needs to identify the asset and describe the fault. Priority and assignee came off the form entirely.
The workflow tracks technician diagnosis, finance approval, vendor response, procurement and repair work separately, so elapsed time lands on whoever owns it.
Each repair accumulates against the asset, exposing repair frequency, recurring faults, cumulative cost, maintenance cadence and time between failures.
Rules handle priority, routing, SLA, escalation and permissions. AI handles title generation, repair-history summarisation, recurring-fault interpretation and explaining repair-versus-replace recommendations.
Rules where the answer must be predictable. AI where interpretation adds value. Humans where judgement still matters.
The system changed both the workflow and the decisions the organisation could make.
| Before | After | |
|---|---|---|
| Faults | Disappear into chat | Become asset history |
| Priority | Chosen by the reporter | Derived from the asset |
| Routing | Ops interprets every request | Derived from the asset |
| Steps to work | Five | Two |
| Delay | Blamed on the assignee | Attributed to the blocker |
| Maintenance | Reacts after failure | Scheduled against the record |
| Repair vs replace | A judgement call | Costed against history |
| Routing rules | Would need a developer | Owned by the client |
AI did not create the evidence. Structured asset history did.
AI could explain the recommendation. The underlying decision came from reliable operational data.
Self-declared priority was a product-design problem, not just a data-quality problem.
Better asset context allowed priority and routing to be derived automatically.
A single completion metric can hide where time is really being lost.
Repair-versus-replace analysis, preventive maintenance and AI interpretation were only possible because every incident was attached to an asset.
Models are powerful at interpretation and poor substitutes for missing structure.
The real product was not a better ticketing system. It was an operational memory layer that let the company make better decisions about its buildings, assets and teams.
That was my first approach. It worked technically, but the assumptions were wrong. I asked users to choose priority, assignee and due date, and those fields quickly became unreliable — everyone thought their own issue was urgent, most reporters didn’t know who owned the fault, and due dates became “today”.
The redesign was less about better software and more about deciding what the user should provide versus what the system could derive itself.
Because tickets disappear once they’re closed, but the asset stays. Once every repair was attached to the same physical unit, I could build a real history: how often it failed, what had already been spent on it, how long repairs lasted, and whether the same issue kept recurring.
That one architecture decision unlocked preventive maintenance and repair-versus-replace later.
I deliberately kept AI out of anything that had to be predictable. Priority, routing, SLA, escalation and permissions were deterministic.
AI was useful for interpretation — cleaning up issue descriptions, summarising repair history, surfacing recurring patterns and explaining repair-versus-replace recommendations.
Rules when the answer must be consistent, AI when interpretation helps, and humans when judgement or money is involved.
That was most of the project. Information started in WhatsApp, ownership crossed facilities, operations, finance, vendors and procurement, and tickets could sit open for reasons that had nothing to do with the technician.
I had to model those blockers explicitly instead of pretending every ticket moved cleanly from open to done. That also stopped the system judging people by a misleading total-completion-time metric.
The core workflow did not depend on AI. A fault could still be reported, routed, prioritised, escalated and closed using the structured data and rules. AI sat on top as an assistive layer.
If an AI feature failed or gave a weak answer, the operational system still functioned. That separation was important for reliability.
I avoided architecture language. Instead of “assignment is derived from asset metadata”, I’d say:
The reporter should only tell us what they know — what’s broken and what it looks like. The system should already know where the asset is and who owns it.
That made it much easier for operations and facilities to challenge the workflow and help shape the rules.
Not automating everything. There were plenty of places where I could have added AI, but doing so would have made the system harder to trust.
I kept high-cost decisions like replacement approval and policy exceptions with humans, while automating repetitive decisions the data could support reliably.
The goal was not maximum automation; it was the right division of responsibility between software, AI and people.
I’d add observability earlier — dashboards for routing failures, manual overrides, bad asset metadata, blocker frequency, AI confidence and recommendation acceptance.
I’d also put more explicit evals around the AI layer, so I could measure when summaries or recommendations were useful versus when users corrected them.
Production AI is as much about monitoring and fallbacks as it is about model quality.