Facility maintenance software
Make room readiness an accountable maintenance decision.
Organize buildings, floors and rooms; convert facility faults to work orders and verify readiness after repairs.
For hotels, properties, schools and shared facilities
No card required · plans from $29/month
Practical evaluation guide · Updated 7 September 2026
In this guide
Separate a repaired space from a ready space
Facilities work often ends in an operational handoff. A technician may finish a repair while the room still needs inspection or another open issue still prevents use. Define who can release a room, what evidence they review and where that decision is recorded.

AI-generated editorial illustration; not a customer photograph or product screenshot.
For a pilot, choose a building, a floor and two spaces. Use a room with an ordinary defect and a shared plant area that serves several rooms. This exposes whether location names are specific enough and whether a repair is being confused with a wider operational clearance.
A room-readiness acceptance test
Use an illustrative room, B-204. Raise a maintenance fault against that space, verify the linked work order and confirm the resulting out-of-service state. Assign and complete the repair through the work-order workflow. Then have the responsible manager review readiness and enter an inspection note.
Next, create two faults for the same room and complete only one. The remaining open work should prevent a premature ready decision. Finally, have two managers view the same state and attempt conflicting updates. The stale update should require a fresh review rather than silently overwriting a newer decision.
This tests a maintenance handoff, not a legal occupancy determination or a property-management-system synchronization. PreventiveHQ's readiness record does not update reservations or a housekeeping roster automatically.
Design the hierarchy around finding the fault
| Level | Example | Why it matters |
|---|---|---|
| Site | North property | Keeps permissions and reporting boundaries clear |
| Building | Block B | Distinguishes repeated room numbers |
| Floor | Level 2 | Helps locate the reported issue |
| Space | B-204 | Owns the room-level fault and readiness decision |
| Asset | Fan-coil FCU-B204 | Owns equipment-specific service history |
A space and an asset answer different questions. A damaged door can be a space-related problem, while a recurring fan-coil failure benefits from an equipment history. Agree on the convention before staff start creating competing location names.
Compare systems with the handoffs you actually have
Hotels may need reservation and housekeeping connections. Property operators may need tenant portals and accounting. Schools may need institution-specific approval and safeguarding processes. A product using the word “facilities” does not necessarily provide all of these.
List required external systems and ask for the exact supported workflow, including sync direction and failure handling. If the maintenance team can operate with a manual operational handoff, document its owner and frequency. If an automatic PMS connection is mandatory, treat it as a separate acceptance criterion rather than assuming it follows from room readiness.
Measure the pilot without overstating it
Track whether faults have precise locations, whether open work is visible and whether readiness reviews contain useful notes. Compare a defined sample of handoffs before and after the pilot. A smaller number of open faults could reflect missing reports rather than better maintenance, so review record completeness alongside the count.
Start with the hotel room checklist or property checklist, adapting the instructions to your actual site process.
Begin with the operational handoff, not a building list
Facility maintenance software should make the location, outstanding work and responsible decision clear to the people operating the site. A building list is useful setup information, but it does not establish that a reported fault reaches the right person or that a repaired room is ready for use.
Choose a recent handoff that caused confusion. Perhaps a room was described as repaired while another fault remained open, or two buildings shared the same room number and a technician attended the wrong place. Reconstruct the information available to each person at the time. Those gaps become the acceptance tests for the new workflow.
The purpose of the pilot is to make an ordinary operating decision dependable. A well-designed process identifies what maintenance work is complete and who is responsible for the separate operational release. The software should support that distinction without implying that a status field replaces the site's technical, safety or occupancy decisions.
Model buildings and spaces around how people report problems
A useful hierarchy reflects the language people use to find a location. Staff may think in sites, buildings, floors, rooms and common areas. Agree on a consistent naming convention, particularly where several buildings have a “Room 12” or every floor has a “Store.”

AI-generated editorial illustration; not a customer photograph or product screenshot.
Do not create unnecessary hierarchy for its own sake. A small property may need only a few clear levels, while a larger campus requires more context. The test is whether a person can identify the intended space from the record without asking the author. If a hierarchy is technically precise but unfamiliar to the people submitting requests, it may create avoidable friction.
Consider shared spaces and plant areas as well as occupied rooms. A fault in a plant room can affect several areas, while the repair itself still has a specific location. Decide how the team records that wider operating consequence without duplicating the same repair as unrelated jobs in several rooms.
Walk the site with a small sample of records. Compare the digital name with physical signs and the terminology used by operations. Correct inconsistent examples before importing or creating every space. A hierarchy that passes validation can still be operationally confusing.
Distinguish a space problem from equipment history
A room or common area can own a location-based maintenance issue. A particular piece of equipment can also need its own maintenance history. The two references help answer different questions: where the work affects operations and which physical asset has been inspected or repaired.
For an illustrative hotel room, a damaged door finish may be recorded against the space, while a recurring fan-coil problem benefits from an equipment identity and service history. The team should decide when an asset record is warranted. Creating a separate asset for every minor fixture can add administration without helping a maintenance decision.
Where an asset serves several spaces, avoid assuming that its current location fully describes its operational effect. A shared pump or air-handling unit can have a wider service role. Keep the approved technical and operational context available through the relevant procedure and site process.
Use the asset maintenance guide to establish stable identity, then test whether work can be understood from both the location and equipment perspective. The pilot should reveal whether staff can find the relevant history without maintaining competing informal lists.
Make fault intake precise enough to act on
A useful report identifies the location and describes what the reporter observed. It should not require the person to diagnose the technical cause. “Water visible below the basin in B-204” provides a different kind of evidence from “replace the pipe,” which already assumes the remedy.

AI-generated editorial illustration; not a customer photograph or product screenshot.
Decide who reviews new reports and how often. A request form should fit the team's actual response process. Avoid suggesting immediate attendance when the queue is reviewed only during staffed hours. Staff also need to know which situations use the site's urgent response route rather than an ordinary maintenance form.
Test the intended intake method with someone who is not a maintenance planner. Watch whether they can identify the space and describe the issue without assistance. Then have the reviewer decide whether the report contains enough information to create work. That handoff can reveal missing instructions more clearly than reviewing the form in isolation.
Consider duplicate reports. Several people may notice the same problem in a common area. Agree how the team recognizes related reports and avoids issuing competing repair jobs. Do not assume automatic duplicate detection unless it has been demonstrated in the product you are evaluating.
Keep the out-of-service decision understandable
A space can be unavailable for several reasons, and maintenance work may be only one part of the decision. Define how the organization communicates the current state and who is permitted to change it. The purpose of the software record is to make the supported maintenance evidence visible to those responsible people.
In PreventiveHQ's facilities workflow, raising a located fault creates corrective work and marks the space out of service. The manager reviews readiness after the relevant work is complete. Test that behavior with a controlled example before adopting it operationally. Staff should understand what the state means and what additional site process still applies.
A completed work order does not automatically prove that every condition for operational use has been satisfied. The readiness review is a separate handoff, and external operations systems may still require an update. Keep those responsibilities explicit so that a software status is not interpreted more broadly than intended.
Use a trial room with two open faults. Complete only one and attempt the ready decision. The remaining open work should remain visible and prevent a premature release through the supported workflow. This is a more useful test than demonstrating only a room with one uncomplicated repair.
Record repair evidence that supports a later review
The work record should explain the observation, finding, action and verification. A location-linked job that closes with “done” leaves the next person with little basis for understanding what changed. Keep the note concise but specific enough to support the readiness review.
Use the appropriate fields for time, parts and verification where supported. Technical instructions and acceptance criteria should come from the approved site or equipment procedure. The software can organize the record, but it should not invent a technical standard merely to make an inspection form appear complete.
During the pilot, have a manager review the completed record without speaking to the technician. Ask whether the manager can understand the maintenance evidence and identify any remaining operational decision. If clarification is routinely required, improve the procedure or closeout expectations before expanding the rollout.
When a fault recurs, inspect the earlier record before treating the new report as an unrelated problem. Repeated observations can justify investigation, but the history alone does not establish root cause. Preserve enough context to support that investigation rather than compressing every repair into the same generic closure note.
Design room-readiness ownership across teams
Facilities work often crosses engineering, housekeeping, front-office or property operations. Each team may use a different system and interpret “ready” differently. Agree on a shared maintenance meaning and identify who performs each handoff.

AI-generated editorial illustration; not a customer photograph or product screenshot.
For a hotel, maintenance completion may be followed by a housekeeping check and a reservation-system decision. For a school, a repaired space may still require an institutional review before normal use. For a property operator, a maintenance record may need to be communicated through the established tenant or building-management process. These are operating requirements to define, not capabilities to assume from a generic facilities label.
PreventiveHQ's current readiness workflow does not automatically synchronize reservations, housekeeping rosters or tenant accounting. If a PMS or another external system must update automatically, specify the exact product and transaction as a separate integration requirement. A manual handoff may be suitable for a pilot when its owner and timing are clear.
Test a shift change. Have a person who did not attend the repair review the state and explain the next action. A process that only works while the original manager is available remains dependent on memory, even if every action happened in an application.
Handle shared-area and repeated-location work consistently
Common areas can generate less precise reports than numbered rooms. Staff may describe “the corridor light” or “the outside gate” without distinguishing several similar locations. Use clear names and physical references that make sense to both reporters and technicians.
For repeated fixtures, decide whether the location reference is sufficient or whether a separate asset identity would help. The answer may differ between a simple fitting and equipment with substantial service history. Apply the convention consistently and retain useful exceptions where there is a real maintenance reason.
Avoid multiplying one underlying fault into several disconnected work records solely because it affects several spaces. Establish how the team identifies the shared repair and communicates its effect. If the product does not model the relationship automatically, document the supported manual coordination process rather than allowing staff to infer it from similar titles.
Include a common-area fault in the pilot. Have someone unfamiliar with the record locate the intended issue, then review how its completion is communicated. This exposes weaknesses that a perfectly numbered demonstration room can hide.
Use planned maintenance without creating an unreviewed checklist library
Recurring procedures can help structure room and facility maintenance, but a large template library is not a substitute for reviewed instructions. Select the work that the site is authorized to perform and confirm its applicable interval and acceptance criteria.
Start with one checklist and have two staff interpret it independently. If a step such as “check equipment” produces different actions, rewrite the record structure and reference the approved instruction. Preserve the distinction between an acceptable observation, an exception and a step that could not be completed.
A generic hotel or property template should be edited to match the actual site. It does not establish regulatory compliance or technical suitability for every building. Keep responsibility for procedure approval with the organization and the qualified people who own that work.
Use the maintenance scheduling guide to test how approved recurring work becomes a job. The relevant acceptance test covers instructions, assignment and closeout, not only the ability to create a recurring date.
Measure facility performance with a stable definition
A lower count of reported faults can mean fewer problems, reduced reporting or a changed operating population. Review record completeness alongside the count. A pilot that makes previously informal issues visible may initially show more work, which can be an improvement in information rather than a deterioration in the building.

AI-generated editorial illustration; not a customer photograph or product screenshot.
For response time, define when the clock starts and what ends it. First review, technician attendance and completed repair are different milestones. Use the same definition across periods and report the working-hours assumption where it matters.
For room availability, distinguish the maintenance state from the wider operational state. If the property uses another application to control occupancy or reservations, reconcile the meanings before comparing metrics. Do not assume a maintenance-ready timestamp is the same as a room becoming available for sale or use.
The first useful pilot measures often concern handoff quality: precise locations, work with owners, useful closeouts and readiness notes that a second person can interpret. Claims about reduced downtime or improved revenue require a longer and more carefully defined evaluation than a setup demonstration.
Compare facilities software against your real boundaries
Prepare a room fault, a common-area issue and a shared-equipment problem for vendor demonstrations. Include two open faults against one space and a manager shift change. Ask to see how the next person understands the remaining work and release decision.
| Requirement | Demonstration to request |
|---|---|
| Clear location | Identify a room whose number repeats in another building |
| Fault-to-work handoff | Preserve the original observation and create accountable work |
| Multiple open faults | Prevent an incomplete maintenance-readiness decision |
| Cross-team review | Interpret the state as a manager who did not attend the repair |
| Procedure fit | Use the site's actual approved checklist and exception process |
| External system | Show the exact supported PMS or operational handoff |
| Permission boundary | Compare a reporter's access with a maintenance manager's access |
Classify the results as demonstrated, requiring an acceptable manual process or unmet. A product can fit maintenance execution while leaving appropriate property operations elsewhere. The purchasing decision should include that remaining work, the current plan limits and the effort needed to train the team.
A practical first-site rollout
Select a small set of spaces and their relevant equipment. Agree on names, report ownership and readiness responsibility before inviting a wider group. Run the controlled fault and multiple-open-work tests, then review ordinary live work with the team.

AI-generated editorial illustration; not a customer photograph or product screenshot.
At the end of the pilot, have someone outside the setup group reconstruct a repair and its readiness decision from the records. Document what remains unclear and whether the issue is a process choice, training need or missing capability. Resolve the important gaps before replicating the configuration across more buildings.
Begin with the room checklist, the request workflow and a trial workspace. The useful outcome is a maintenance handoff that the next shift can understand and act on confidently.