How to evaluate permit-to-work software for an Australian project

Before a demonstration, prepare a short brief: the work types you need to manage, the roles involved, the records they rely on and the points where work cannot move forward without a decision. Use fictional data or a document your organisation has authorised you to share.

For each decision, ask who can make it and what they need to see. A useful example is a permit request that needs a correction. Show who returns it, how the reason is recorded, who can amend it and what must be reviewed again.

Ask the supplier to identify which parts are standard configuration, which require development and which the system cannot support. Record those distinctions in the proposal. A feature mentioned in a sales conversation needs a clear place in the agreed scope.

If you need a starting point for that brief, the Permit-to-Work Readiness Checklist can help structure a review of your current process. The checklist page asks for work details to access the resource.

Ask to see a request move through the review and issue stages relevant to your procedure. Then introduce a deliberate exception in the demonstration: an incomplete required field, a user without the necessary permission or a change after review.

Watch the resulting behaviour. Does the system explain why the action cannot proceed? Can the right person resolve it? Can someone later understand what happened without relying on the demonstrator's explanation?

Compare the state names with your own procedure. Make the distinction between ending a shift, returning control, resuming valid work and permanently closing the job explicit. If your procedure uses relinquishment, ask how that differs from final close-out and what must happen before any later reissue.

Capture the tested role and software version alongside the result. A demonstration using an administrator's account does not answer every question about the permissions ordinary users will have.

Where isolation forms part of the job, ask how the permit references the relevant isolation plan or Equipment Isolation List, and how users identify its current revision. Have the supplier show the relationship from both records.

The model plant Code of Practice discusses hazardous energy, isolation points and stored energy in section 4.5. For software evaluation, that is a reason to examine the supporting records carefully; a displayed status cannot establish the physical condition of equipment. Isolation methods and verification remain matters for the site's procedure and competent people. Source: Safe Work Australia, November 2024 model Code, section 4.5.

Use two fictional work groups that depend on the same isolation. Ask how the records show both dependencies when one group finishes and the other remains attached. Where your procedure uses group lockboxes or cross-locking, ask the supplier to demonstrate how those relationships are represented and reconciled.

Do not use the software demonstration to decide lock placement or an isolation design. The useful buying question is whether the records and permitted actions accurately express the process your authorised team has specified.

Continue the same fictional job into a handover. Ask the incoming role to establish the work status, current documents, outstanding decisions and dependencies using the information available to them. Notice where the demonstrator has to provide information that the incoming person could not otherwise find.

Next, change one part of the fictional scope. Ask which records need review, who is notified and how the earlier decision remains traceable. Check whether an older printed copy is visibly distinguishable from the current revision.

These are established review themes: WorkSafe WA's January 2018 mining isolation audit guide includes shift handover, change management and linked permits in items 4.7, 4.8 and 4.10. The document references an older mining legislative framework; use it as background for evaluation questions and check current site and regulatory requirements separately. Source: WorkSafe WA, isolation audit guide.

For construction and commissioning projects, add a nearby work group or a changed area boundary to the fictional scenario. Ask how the people affected find the current information and how the appropriate authority's decision is recorded.

Check the relationship between the work description, site drawing, area status and any relevant notice. Ask what happens when one of those references changes. If a supplier uses a map, open the actual record behind a marker and check its revision and scope.

For projects with high-voltage (HV) work, include a separate review by the relevant competent authority. A general permit role or a coloured area on a screen should not be assumed to establish HV authority. Ask the supplier to demonstrate your required separation of responsibilities using the agreed test roles.

Choose a completed step from the demonstration and ask for its record. Can you identify the actor, time, decision, associated revision and any stated reason for change? Check what the record looks like when exported or printed, including attachments and linked references your process requires.

Try the documents on the devices and paper sizes your team expects to use. A document that looks clear on a large screen may need a different layout at the workface. Check legibility, page breaks, revision identifiers and how someone finds the related record.

Ask the supplier to demonstrate the agreed response to a lost connection or unavailable service. Clarify what remains accessible, which actions are unavailable and how the site's approved continuity process would operate. If offline use is offered, test its boundaries and reconciliation behaviour explicitly.

Keep the resulting sample records with your evaluation. They are useful evidence for the people who could not attend the demonstration.

Operational fit is one part of the decision. Give your IT or security reviewer a separate set of questions and ask for written answers relevant to the proposed package and deployment.

• How are users invited, authenticated and removed, and what access can each role receive?
• How is access separated between organisations and sites, and how will that separation be tested?
• Where are data and backups held, and what evidence is available for recovery arrangements?
• What activity can be audited, exported and retained, including after the contract ends?
• Which integrations are available now, which require additional work and who supports them?
• How are incidents, service interruptions and support requests handled?

Ask for evidence behind specific certifications, hosting claims or service commitments. Record unanswered questions with an owner and a due date. Their importance depends on your procurement and operational requirements; an attractive demonstration does not resolve them.

Turn the requirements into a small set of observable tests before starting a pilot. Name the configuration, roles, sample records and expected outcomes. Include ordinary work, an exception, a handover and a retrieval of the final evidence.

For example: “Using the fictional maintenance job, show that the incoming permit-office role can identify the current permit revision, dependent work groups and outstanding decisions, then retrieve the recorded handover.” Your procedure owner should define what constitutes an acceptable result.

For each requirement, record one of four outcomes: demonstrated; demonstrated with a documented limitation; not demonstrated; or not applicable with an agreed reason. Do not average away a failed essential control inside an overall score.

Agree the commercial scope as well: software access, configuration, training, implementation support, optional hardware, integrations and exit assistance. Ask who owns each task and which costs recur. A useful pilot ends with a clear list of accepted requirements, unresolved gaps and the decision owner.

Copy this table into your evaluation notes. Add a row for each important requirement in your approved procedure or procurement brief.

Scroll sideways to compare all columns.

A blank evidence cell is a follow-up item. It is not a completed test.

Read the PermitSync platform overview, then request a demo focused on your workflow. Bring the evaluation questions that matter to your team and ask which requirements can be demonstrated for your proposed scope.