Practical evaluation guide · Updated 7 September 2026
In this guide
A practical engagement to evaluate together
This pilot is for consultants, equipment service companies and facility-management providers helping a client establish a usable asset register and repeatable maintenance process. Start with one client, one site and a defined outcome. Examples include importing a clean register, replacing a shared work-order spreadsheet or verifying room defects before release.
Define the responsibility before setup
The client should own its workspace and decide who receives access. The consultant agrees its professional scope directly with the client. Identify the person who approves procedures, maintenance intervals and safety decisions. PreventiveHQ supplies software; it does not certify a maintenance program or replace qualified engineering judgment.
Use a repeatable pilot handover
Record the initial problem, source files, intended users and success criteria. Prepare the asset CSV, review a checklist with the client and complete one real job with an accountable technician. At handover, confirm who owns billing, administration, backups of exports and ongoing procedure changes. Remove consultant access when the engagement ends unless the client explicitly wants it retained.
Request a fit review
Use the workflow-review form and begin your description with Partner pilot. Include your service area, client type, expected workflow and whether the client has agreed to an evaluation. Avoid sending confidential client files in the initial request. Referral fees, co-branding, managed-account access and support commitments require a separate agreement; none are automatically included or promised.
Choose a client problem that a small pilot can resolve
A maintenance consultant can help a client adopt software by making the operating process explicit: which equipment matters, who owns the records and how a maintenance task moves from identification to verified completion. The software is one part of that engagement. A useful pilot starts with a problem the client recognizes and a result that can be checked without relying on a broad transformation promise.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Examples include reconciling a fragmented asset register, replacing an unowned request inbox or establishing a consistent completion record for one recurring procedure. Choose one of these outcomes rather than attempting to redesign every maintenance practice at once. A narrow pilot gives the client a clearer basis for deciding whether to expand the work.
Ask the client to provide representative examples of the current problem. A duplicate asset row, an unclear work order or a request with no location can become an acceptance-test case. Preserve those examples appropriately and agree how they may be used in the engagement. They should not become public marketing material without the client's explicit authorization.
Define the professional scope separately from the software subscription
The consultant's scope should state what services they will provide, what the client will decide and what depends on the software's available capabilities. Data cleanup, workflow design, procedure review and staff orientation are different activities. Grouping them under a vague “implementation” label makes it difficult to understand responsibility when a gap appears.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Identify the qualified owner of technical procedures and maintenance intervals. A consultant may assist with organization and documentation, but the appropriate engineering and operational decisions remain governed by the agreed professional scope and the client's responsibilities. PreventiveHQ does not certify that a maintenance program is technically suitable simply because its records are stored in the application.
Keep commercial expectations explicit. Referral fees, co-branding, managed-account facilities and support commitments are not automatically included in a partner pilot. Discuss any required arrangement separately before representing it to a client. The publicly described pilot is an opportunity to evaluate fit, not a promise of an established reseller entitlement.
Let the client retain control of the workspace
The client should own the workspace and decide who receives access. Establish the administrative and billing owner at the start, rather than leaving those decisions until the consultant finishes configuration. The client needs a practical way to continue operating the system when the engagement ends or the assigned consultant changes.
Use individual accounts and appropriate roles for the work being performed. Avoid shared credentials as a shortcut for collaboration. The person authorized to clean a register may not need the same access as the person responsible for billing or system administration. Test the relevant permissions with the client before importing operational data.
Agree when consultant access will be reviewed or removed. An ongoing support arrangement may justify continued access, but that should be a deliberate client decision. Include the access review in the handover checklist so that it is not forgotten after the first successful demonstration.
Map the current handoff with the people who perform it
Interview or observe the people involved in the chosen workflow. Ask how work enters the process, where it waits, who decides priority and what evidence is required for completion. The answers from a manager, planner and technician may differ, and those differences often explain why the current system feels unreliable.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Use a recent example to walk through the actual sequence. Avoid relying only on an ideal procedure document. A work order may officially require a closeout note while real jobs are routinely completed through a phone call. Understanding that gap helps the consultant design a realistic adoption step rather than configure a process that exists only on paper.
Document the smallest changes needed for the pilot. A clear owner, a stable asset reference and a consistent closeout structure may resolve the immediate problem without a large configuration exercise. Keep additional opportunities in a separate backlog so they do not prevent the first workflow from becoming usable.
Prepare a source-data inventory before importing
List the files and records the pilot needs. An asset workbook, historical service folder and recurring maintenance list may each require a different preparation process. Identify their owners, versions and known limitations. The consultant should be able to explain which source is authoritative when two files disagree.
Keep an unchanged copy and work from a preparation version. Record transformations such as asset-code reconciliation, site mapping and status translation. This creates a reviewable trail of decisions and gives the client a way to understand the imported register without depending on the consultant's memory.
Use the Excel-to-CMMS guide for the supported asset workflow. Schedules and completed work history use separate imports. Attachments and original user identities are not silently transferred by the asset CSV, so include their handling in the scope if the client requires them.
Make the pilot acceptance criteria observable
Acceptance criteria should describe something a person can demonstrate or verify. “Improve maintenance visibility” is a useful ambition but a weak acceptance test. “A planner can find the correct asset, assign the sample job and review its completed evidence” is much easier for the client to assess.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Use a small set of criteria covering data, execution and handover. For data, check identifiers and site context. For execution, follow a real task and an exception. For handover, ask the client to repeat the workflow independently. These checks establish whether the pilot produced a usable operating process.
Keep outcome claims proportional to the observation period. A short pilot may show reduced lookup effort or fewer clarification questions. It generally cannot establish a reliable long-term reduction in failure rates. Record the evidence and limitations so that the client can distinguish an observed improvement from a hypothesis for later measurement.
Configure only the workflow the client is ready to own
It can be tempting to populate every feature during setup. That may make the workspace look complete while creating maintenance responsibilities the client has not agreed to perform. Start with the records, roles and recurring work needed for the pilot. Each configured element should have an owner and a reason to exist.
Review imported schedules before activation. PreventiveHQ's schedule import creates paused plans, giving the team a chance to check intervals, triggers and workload. Use that boundary deliberately. Activating an unreviewed library can create a large due-work queue before staff understand the new process.
Likewise, avoid installing a large template collection without technical review. A generic checklist can help organize documentation, but the client must establish suitability for the equipment and task. The consultant's contribution is to make that review manageable and explicit, not to replace it with a bulk setup operation.
Test ordinary work and one realistic exception
A successful ideal-path demonstration is necessary but incomplete. Include an exception that reflects the client's actual experience: a missing asset detail, a duplicate request, a parts delay or an inspection finding requiring follow-up. Observe how the team handles it using the proposed workflow.
Keep the test safe and bounded. Use an appropriate sample or authorized real task, and avoid creating operational confusion solely to demonstrate a feature. The client should understand what is being tested and how the result will be recorded. The purpose is to expose a handoff weakness before wider rollout.
After the exception, ask the next person in the process to explain what happened and what they must do. If that requires the consultant to narrate missing context, improve the record or responsibility assignment. The workflow should carry enough information to function after the consultant leaves the room.
Train through role-specific tasks
Training is more useful when each person performs the tasks they will own. A technician needs to find assigned work, understand the procedure and record completion. A planner needs to review incoming work, resolve ambiguity and assign responsibility. An administrator needs to manage the workspace's ongoing access and configuration.
Use the pilot's actual terminology and records. Generic demonstrations can hide confusing names or location structures that become obvious in the client's data. Have participants complete the task themselves and note where they hesitate. Those observations can reveal configuration problems as well as training needs.
Keep a short reference for the recurring actions and escalation points. It should explain what the user does when information is missing or the expected workflow does not fit. A useful handover includes how to handle uncertainty, not only the sequence of clicks in a perfect example.
Separate product gaps from process gaps
When a pilot stalls, identify the type of problem before proposing a remedy. A missing field or unsupported integration may be a product gap. An unreviewed procedure or unclear owner may be a process gap. A user who cannot interpret a location name may reveal a data or usability issue. These require different next steps.
Document the observed behavior and the requirement it fails to meet. Avoid describing a desired capability as available because it appears on a future plan or seems technically straightforward. The client needs an accurate basis for deciding whether the current product fits the engagement.
If a manual step remains, include its effort and owner in the acceptance decision. A limited manual handoff may be acceptable for a small team, while the same step may be impractical at a larger scale. The consultant should help the client evaluate that tradeoff with actual examples rather than hide it behind a broad automation claim.
Build a handover pack the client can use
The handover pack should identify the workspace owner, configured scope, source files, mapping decisions and remaining actions. Include the acceptance evidence and the agreed operating conventions. Keep it concise enough to use while preserving the information needed to maintain the setup.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Document recurring responsibilities such as reviewing requests, updating asset records, checking integration exceptions and approving procedure changes. Assign them to client roles or named owners according to the engagement. An implementation that works only while the consultant monitors every queue is not yet an independent client process.
Include access and data-export arrangements. Confirm who can obtain operational exports, where those files are stored and how consultant access will be handled after completion. The client should be able to retrieve its information and understand the configured workflow without reconstructing the engagement from email conversations.
Review whether the client can operate independently
Use an independent walkthrough near the end of the pilot. Ask a client user to perform the core task while the consultant observes without guiding every step. Then ask another person to review the resulting record. This checks both execution and interpretation.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Record the remaining questions and decide whether they require training, data cleanup or a product change. Do not classify every difficulty as user resistance. A confusing form, an unclear asset name or an incomplete procedure can make an otherwise willing person struggle. The observation should lead to a specific improvement.
Repeat only the affected task after making the change. The goal is a stable handover, not endless demonstration. Once the client can complete and review the workflow reliably, document the result and agree the next scope rather than extending the pilot indefinitely.
Evaluate expansion with evidence from the first site
Expansion should follow the problems and results observed in the pilot. A second site may introduce different equipment, language, reporting practices or connectivity. Use the first site's method as a starting point, but verify the assumptions that change. Copying configuration does not automatically copy operational readiness.
Keep a reusable checklist for the consultant's own delivery process: discovery, source review, mapping, pilot configuration, exception test and handover. Separate that delivery method from the client's technical maintenance procedures. The repeatable service is the implementation discipline, while the maintenance content still requires client-specific review.
Discuss the next engagement in concrete terms. Identify the additional asset group, workflow or integration, the expected effort and the evidence needed for acceptance. This gives the client a clearer purchasing decision than an open-ended promise to digitize the whole operation.
Request a PreventiveHQ fit review with a bounded brief
Use the workflow-review contact form and begin the description with “Partner pilot.” Include the service area, client type, proposed workflow and whether the client has agreed to an evaluation. A short, concrete brief makes it easier to assess whether the available product matches the engagement.
Do not send confidential client files in the initial inquiry. Describe the data shape and known requirements first, then agree an appropriate way to handle any detailed information if it becomes necessary. Keep the client's authorization and professional scope clear throughout the process.
A useful first discussion ends with a bounded test, an accurate capability boundary and identifiable responsibilities. Use the maintenance evidence method to define the result and the integration guide to assess external data needs. The aim is a client-owned workflow that remains useful after the pilot ends.
An example of a bounded pilot brief
A useful brief might describe one workshop with a fragmented equipment register and inconsistent closeout notes. The proposed pilot could reconcile a small asset group, configure one reviewed recurring procedure and have two client users complete and review a maintenance job. Acceptance would require correct identities, understandable completion evidence and an independent client walkthrough. The brief should also identify excluded work, such as historical attachments or an unsupported external system.
That example is a planning structure, not a packaged service commitment or a promised delivery timetable. The consultant and client still need to agree effort, professional responsibilities and commercial terms. PreventiveHQ fit review establishes whether the available software can support the proposed workflow.
What evidence belongs in the handover meeting?
Bring the reviewed source mapping, the completed pilot record, the exception decision and the list of ongoing owners. Ask the client to demonstrate a routine task and explain where to find supporting evidence. Record unresolved items with a next action and owner. This makes the handover a practical acceptance decision rather than a presentation that ends without confirming operational independence.