Improving how facilities issues are reported, assigned and resolved

The Context

A facilities-management service process spanning fault reporting, triage, dispatch and estate management, explored through a working prototype rather than a requirements document.

The Challenge

Facilities issues were moving through a fragmented service process. Reports could be difficult to categorise, the wrong trade could be dispatched, jobs could be closed without resolving the underlying problem and the person who raised the issue had little visibility of progress.

The same information gap affected management. Repeat faults could be treated as unrelated jobs, engineers could visit the same location separately and recurring problems did not easily surface as evidence that an asset or building required a more significant intervention.

What Quant8 Did

Quant8 created a working facilities-management service-desk and work-order prototype on Palantir Foundry. It included:

Voice and mobile fault reporting, including photographs and supporting detail
Immediate work-order references and requester status tracking
A central queue for enrichment, triage and exception handling
Classification by fault type, location, urgency and operational impact
Skill-based matching between work orders and engineers or subcontractors
Calendar and dispatch planning with manual override
Mobile engineer access to routes, job detail, photographs, notes and supporting manuals
Duplicate detection and bundling of nearby or related work
Kanban, ageing and route-to-green views
SLA and resolution-performance analysis
Building-level views of repeated faults and systemic maintenance patterns

How It Was Delivered

The prototype modelled fault reports, work orders, engineers, buildings and assets as connected operational objects. That made it possible to answer questions that are difficult when information is held in tickets and spreadsheets alone:

Which qualified engineer should attend this fault, and in what order?
Is another job already open in the same building?
Is this an isolated issue or part of a repeated pattern?
Has the reporter been told what is happening?
Is the work approaching or breaching its service level?
Would continued reactive repair cost more than capital intervention?

The Result

The work showed how a single operational application could reduce reporting friction while giving different users an appropriate view of the same process.

The prototype demonstrated how reporters could gain acknowledgement and progress visibility, while service teams could work through a structured triage and dispatch workflow. It also showed how engineers could receive the context needed to complete work effectively and how estate managers could gain a clearer view of service levels, repeat failures, expenditure and building health.

The prototype was designed to integrate with existing service-desk, ERP and asset-management systems rather than requiring them all to be replaced. It was a demonstrator and proposed delivery foundation; no claim is made here that it progressed into a production deployment.