Hospital Maintenance Work Order Automation: An AI Case Study

At a hospital unit in São Paulo, four managers spent two and a half hours every week deciding, work order by work order, what was urgent and what could wait. Agence was brought in to prove that hospital maintenance work order automation powered by AI could handle that first pass without taking the final word away from them.

The bottleneck: 14 hours a week to prioritize maintenance work orders manually

The unit served is part of a large hospital network in São Paulo, with an asset base that ranges from critical ICU equipment to building infrastructure items like air conditioning and lighting. That entire asset base is managed centrally through Manusis4, the CMMS the network uses to log preventive, corrective and predictive maintenance work orders throughout the week. The hospital itself approached Agence in the second half of 2025, with a direct complaint: the weekly work order prioritization process was consuming too much of the management team's time.

The routine followed a fixed script. Every Monday morning, the planning analyst logged into Manusis4, exported the data and manually consolidated everything into an Excel spreadsheet. Monday afternoon, four managers met for two and a half hours to review each work order, one by one, and decide what would go into that week's execution queue. Once the meeting ended, the analyst went back into Manusis4 to manually update the status of every approved order, releasing the service scheduling. Rejected orders stayed in the spreadsheet and came back up for review in the following weeks.

This is exactly the kind of bottleneck that usually justifies a process automation project: qualified professionals stuck on a repetitive task, with no time for more strategic parts of hospital operations.

Diagnosis: time cost, manager variability and spreadsheet risk

The hospital's diagnosis showed the problem wasn't just meeting length. Preparation alone cost the planning analyst about 4 hours a week, and the meeting occupied all 4 managers for two and a half hours, adding up to 10 person-hours. In total, 14 hours of skilled work went by before a single maintenance order was actually executed. A second pattern emerged from the interviews: at the extremes of the priority scale, on what was clearly critical and what was clearly low priority, the managers agreed. Disagreement concentrated in the middle categories, and the cause was more human than technical: a manager with more day-to-day exposure to a given hospital area tended to rate a work order as more critical than a colleague without that exposure, even when looking at the same information.

The two-layer solution: automatic extraction and AI classification

The answer defined with the hospital split the solution into two layers. The first is systemic: it automates the extraction and consolidation of the data that currently comes out of Manusis4, a concrete case of CMMS automation with AI, without depending on the analyst opening the system every Monday. The second is cognitive: it analyzes each work order semantically and proposes a priority classification, mirroring the criteria the managers themselves use.

This design follows the principles of human in the loop AI in healthcare applied to any critical process, where the final decision can never rest with the model alone.

The methodology ran on two tracks. With the hospital's own team, Agence applied the empathy and definition phases of Design Thinking, with shadowing sessions and recorded interviews with analysts and managers. With the technical team, ideation, prototyping and testing ran in two-week Scrum sprints, with the best result of every cycle brought to a validation meeting with the hospital every three days.

Engineering decisions: why web automation, a local LLM and Playwright won

Every technical decision answered a specific need, and in nearly all of them the obvious alternative was ruled out for a concrete reason. Manusis4 is a SaaS product with no access to its source code, and its documentation offers no export API, which made an API integration a non-starter. The fallback was non-invasive web automation, simulating the navigation of a real user inside the platform itself.

The volume of historical prioritized work orders also couldn't support a conventional statistical model: the available ground truth totaled just 500 orders, not enough to train a decision tree or a traditional machine learning model. That limit, not the size of the hospital's equipment base, is what drove the choice of a language model with dedicated prompt engineering for classification. The result is a fully open stack, built on Python, Playwright, Pandas and Qwen2.5-14B, with no license cost and fully auditable, which makes both maintenance and third-party technical review easier.

Prompt engineering: how agreement with managers went from 38% to 72%

The hospital provided a ground truth of 500 maintenance work orders already prioritized by managers. Every time the prompt changed in a meaningful way, the technical team ran the full flow and compared the result against that ground truth with in-house scripts, which automatically generated the agreement percentage and a confusion matrix. The flow ran as often as once or twice a day, tracking gains, regressions and failure patterns with every iteration.

The jump from one version to the next didn't come from a bigger or more expensive model: it came from a more specific prompt. It's the same lesson seen in other artificial intelligence projects applied to business processes, where prompt engineering for classification tends to matter more than the choice of model itself.

Two numeric scores were enough because they are exactly the variables that feed the maintenance risk score designed with the hospital: patient risk and operational impact. Adding a third criterion would have required recalibrating the entire weight matrix, with no guarantee that the 500-order ground truth could support that extra granularity.

The risk score and the four layers against AI hallucination

The V3 response rests on a simple formula: maintenance risk score = (patient risk × 0.6) + (operational impact × 0.4). The team tested four different weight combinations, and this one best matched the managers' historical prioritization. The patient risk variable captures everything that threatens patient safety and regulatory requirements; the operational impact variable captures infrastructure and facility management.

• ✓Prompt self-sufficiency: every input the classification needs already lives inside the prompt itself, with no real-time external lookup.
• ✓Institution-specific context: the clearer the hospital's own rules are inside the prompt, the smaller the margin for the AI to invent its own criteria.
• ✓Format constraint: the response comes back as JSON, with fixed keys and types, which makes it possible to automatically detect any off-spec output and trigger a retry.
• ✓Human in the loop: final validation stays with the managers, the most important protection layer of all.

This validation discipline follows the same reasoning that guides any AI implementation project: test against a real problem before trusting the solution at scale.

In practice, layer three is what kicks in first whenever a response strays from expectations. If the model returns a JSON with a missing field or the wrong type, the system discards that response and automatically triggers a new attempt at the same request, before any malformed classification gets anywhere near the managers' spreadsheet.

Validation protocol: testing AI without confirmation bias

Before any reduction in effort could be promised, the solution had to prove it classified well without contaminating the managers' decisions. The pilot was designed with exactly that in mind.

1. 1Two weeks running in parallelThe automation ran alongside the full old process, processing 198 work orders, without replacing a single manual step yet.
2. 2Kept sealed until the meeting endedThe AI-generated prioritizations stayed sealed until each committee meeting wrapped up, preventing managers from deciding under the influence of the model's suggestion.
3. 3Comparison only afterwardOnly after the meeting were the AI's classifications compared against the human decisions. This design avoided confirmation bias, the central point of this validation protocol for AI in critical processes.
4. 4Pilot metricsClassification accuracy, sensitivity on critical orders, and average time for each automation step were the three indicators tracked over those two weeks.
5. 5Effort reduction measured afterwardOnly once the solution was in production, with the pre-classified spreadsheet as the starting point, did the time savings for managers get counted.

Results in production: fewer management hours, the same final human decision

With the solution in production, the full cycle now runs in 55 minutes: 20 minutes for extraction, mostly the time it takes to download the spreadsheets from Manusis4, 33 minutes for the AI prioritization flow, and 2 minutes for transformation, which already consolidates the data and generates the final spreadsheet in the legacy format the Power BI dashboards already used. The result is a healthcare facility management software approach that keeps the managers' decision intact and only cuts the repetitive work built around it.

The meeting stopped being about classifying every single order one by one and became about validating the few exceptions that actually require a human decision.

Frequently asked questions about hospital maintenance automation with AI

Prioritize critical maintenance with the rigor your operation demands

This case didn't come from a generic AI promise: it came from a real ground truth to measure agreement, from prompt engineering iterated until the numbers could support a real decision, and from a validation protocol built to avoid confirmation bias. Similar discipline underlies other operational fixes, like the call center handle time reduction we've documented elsewhere. If you're dealing with a manual, critical process in your own operation, it's worth talking to a specialist about where this same kind of pre-prioritization could apply, without giving up the final human decision.

Talk to a specialist