Testing Traffic Control Software With a Real Job: A Demo Script

A good traffic control software demo uses one of your real jobs, not the vendor's prepared tour. Bring last week's shift, ask the vendor to run it from booking to signed docket, then test the messy moments: a 4.30 am sick call, a fatigue breach, an expired ticket and a changed start time. Score every vendor on the same script.

Most demos are designed to show software at its best. That is fair enough, but it will not tell you whether the system survives a wet Monday with three no-shows and a client who has moved the job. This guide gives you a script you can hand to any vendor, the questions each person in your team should ask, and a score sheet so you compare vendors fairly. It is vendor-neutral. For a broader view of features, read traffic control software: what to look for first.

Before the demo: pick the job and the people

Choose a real job from the last few weeks that had a bit of everything. A good test job:

• runs over more than one shift, ideally with a night shift
• needs a mix of roles, such as controllers, an implementer and a supervisor
• uses a vehicle and equipment that need checking
• had at least one change, such as a crew swap or a time change
• needed a signed docket from the client's site contact

Send the vendor the job details a few days before, with personal details removed or replaced, and say you want it run live. Then bring the right people:

The demo script: run one real job end to end

Hand this to the vendor and ask them to follow it in order, on screen and on a phone.

1. Create the client and the site, including site contact, address and any access notes.
2. Take the booking. Ideally from the client's side too: can a client request a shift through a booking link, and what does the office see?
3. Attach the documents the crew needs: the traffic guidance scheme (TGS), permit and site notes.
4. Build the roster. Allocate the crew, the vehicle and the equipment for each shift.
5. Trigger a clash. Try to allocate a controller already working another job at the same time.
6. Trigger a fatigue check. Allocate a controller to a night shift that leaves too little rest before their next day shift, under your own configured limits.
7. Trigger an expired ticket. Allocate a controller whose card or induction has expired.
8. Offer the shift to the crew and accept it on a phone.
9. Run the shift on the phone: pre-start vehicle check, SWMS sign-on with signature, start time.
10. Complete the docket: times, breaks, crew, equipment, notes, and the client's sign-off on site.
11. Show it in the office: the live view of today's shifts, the approved docket, and what happens next for payroll and invoicing.
12. Export the records. Show what you can export, in what format.

Testing the messy moments

The script above is the easy path. Now test what happens when things go wrong, because that is where your allocator spends their day.

The 4.30 am sick call. A controller rings in sick for a 6 am start. Ask the vendor to show how the allocator finds a replacement with the right tickets, who is not on a fatigue breach and is near the site, and how the new controller is notified. Count the clicks. Our last-minute sick call playbook describes the process the software should support.

The client changes the start time. The client moves a night shift from 7 pm to 9 pm the afternoon before. Does the roster update, does each controller get notified, and does the fatigue check run again on the new times?

The equipment problem. A vehicle's registration or an inspection is due next week. Does the system remind you before it lapses, and can crew or office find the item quickly, for example by scanning a label?

The end of a long week. A controller has worked five long day shifts and is the only one with the right tickets for a Saturday night job. Ask the vendor to show what the allocator sees when they try to roster that person. A good system shows the warning against your own configured daily, weekly and rest-break limits, explains which limit is breached, and records who overrode it and why if your procedure allows an override at all. Fatigue limits are set by each company from its own risk assessment, so the software should let you set them rather than impose fixed numbers. Our fatigue-safe roster example shows the kind of fortnight the checks should handle.

The disputed docket. The client says the crew left at 2 pm, the docket says 3 pm. Ask what record exists, who signed, and when.

Example scenario: scoring two vendors on the same job

Here is how this plays out in a typical evaluation. A traffic control company with about 30 controllers is comparing two products. The operations manager chooses a real three-shift lane closure job from last month: two day shifts and one night shift, five controllers, a supervisor, one ute and a set of portable lights.

Vendor A runs the job smoothly but uses a prepared account. When asked to trigger a fatigue check, the presenter says limits can be set up "during onboarding" but cannot show it. The sick call takes several screens to resolve.

Vendor B runs the job in a fresh account. The clash and fatigue warnings appear when the allocator tries to double-book. The controller on the team completes the pre-start and docket on their own phone without help. Export is shown, but the payroll officer finds the export format needs manual work for their payroll process.

What the team records: each person fills in the score sheet below during the demo, not afterwards. The owner adds notes on pricing and contract terms. Neither vendor is perfect, so the team asks Vendor B for a trial with one crew for two weeks, and asks specifically how the export can be adjusted.

What goes wrong: the company nearly decides on Vendor A because its presentation was polished. The score sheet shows Vendor A scored lowest on the parts the allocator uses every morning.

A printable score sheet

Score each item from 0 (could not show) to 3 (showed it working with our job).

Questions to ask before you sign

• What does it cost per user, per month, and what is included? Are there setup fees?
• Can we export all of our data, at any time, in a usable format?
• Where is our data stored, and how is personal information protected? The Office of the Australian Information Commissioner explains privacy obligations.
• What happens to our records if we leave?
• How do updates work, and do we get notice of changes?
• What does onboarding look like, and who does the setup work?
• Can we configure our own fatigue limits, ticket types and docket fields?
• How do timesheet records support our obligations under the award? Check pay and record-keeping rules with the Fair Work Ombudsman.

After the demo: trial with a real crew

A demo shows what the software can do in expert hands. A trial shows what your team does with it. Run a short trial alongside your current system:

• choose one supervisor and a small crew who are open to trying it
• run real shifts, with dockets in both systems
• compare the records at the end of each week
• ask the crew what was hard, not just whether they liked it

Our guide to getting traffic controllers to use the crew app covers how to bring the rest of the crew across once you decide.

Next steps

Pick your test job, book demos with each vendor, and send them the same script. If you want to run the script yourself, TrafWise offers a free trial with an allocation board, crew app, digital dockets and fatigue checks you can test against your own job.