Ask every workforce management vendor to configure one of your own rules in the demo, through the screens your team will use after go-live. On that one rule, ask for five things. Show who is qualified for a shift, build the rule without a script, date a change, schedule a shift that crosses it, and simulate the result before payroll. Who does that work in the demo is who will do it every time your agreement changes.
A typical demo runs on a sample company with rules set up in advance. That shows the product works. It does not show who will change your rules once the system is yours.
The five requests below close that gap with one rule from your own agreement. They answer the question a feature list cannot.
In this post:
- Why ask the vendor to configure your own rule in the demo
- The five things to ask a vendor to configure
- What a weak answer sounds like
- Who should be in the room
- How WorkAxle handles the five requests
- What to do before your next demo
Why ask the vendor to configure your own rule in the demo?
"Configurable" can mean a screen your team uses, a script someone writes, or a request to the vendor. Watching your own rule get built in the demo tells you which of the three you are buying. The difference shows up later, every time a clause changes and someone has to change the rule.
Mat Diab, Founder of WorkAxle, made the same point in one of his videos. "The best way to identify a modern WFM and to not be fooled by fancy marketing or people saying that their solution's modern when in fact it isn't, is to see how configurable is the solution directly through the front end," he says.[1]
Then he narrows it to the case that counts: "And I'm not talking about for a standard set up, I'm talking about for things that are truly complex."[1] Your own rules are that case, and they are what the system will hold for years.
The strongest demo test is one of your own rules, built through the front end. In WorkAxle, rules are configured in a no-code builder, and a shift that crosses one is flagged while the schedule is built, with the rule named.
What five things should you ask a vendor to configure in the demo?
Ask the presenter to do five things with one rule from your own agreement. Show who is qualified for the shift, build the rule without a script, date a change, schedule a shift that crosses it, and simulate the result before payroll. The order follows the rule from the first screen to the pay run.
The examples below use daily overtime, where hours over eight in a day are paid as overtime. Swap in your own. Diab's checklist in the same recording covers the same ground: "different qualifications, certifications, effective periods, different compliance rules, different shift validation rules."[1]
1. Who is qualified for the shift?
Start with the people. Pick a post that needs a certification, such as first aid, and ask the vendor to add the requirement. Then ask who the system offers for that shift. A strong answer builds the list from what each profile holds. A requirement kept in a notes field is the weak version, because someone has to remember to read it.
2. Can the rule be built without a script?
Next, ask the presenter to build your overtime rule from the screens, not in a script editor or as a note for the implementation team. Diab's question for any vendor: "Can you handle union rule configuration directly through the tooling?"[1] Then ask them to read the finished rule back to you. If it reads like the clause in your agreement, the people who own that clause can check it.
3. Can the change start on a future date?
Now change the rule. Ask for the daily threshold to move from eight hours to ten, dated to start on the first of next month. This is effective dating: the change is made today and applies from the date it names. Diab calls it the step where you "effective date it."[2] If the only way to time a change is to make it the night before, the timing depends on someone's calendar reminder.
4. What happens when a shift crosses the rule?
Then assign a nine-hour shift on a day the eight-hour threshold still applies. This is shift validation: checking each shift against the rules as it is scheduled. A useful screen says so in a scheduler's words, naming the rule, the threshold and the shift. Move the same shift into next month, and under the ten-hour threshold it should pass clean. Next, ask what happens when a manager has a reason to go ahead. Look for a system where the decision stays with that person and the record writes itself: who decided, and when.
5. Can you see the result before payroll does?
Last, ask to run the changed rule against a real week of shifts and see the hours it produces as regular time and overtime. Diab describes the moment you "simulate it to get the appropriate results."[2] Without that step, the first pay run is where the change gets tested.
Each request also has weak answers, and they are worth knowing before the demo starts.
What does a weak answer sound like?
A weak answer moves the work out of the demo. The vendor will configure it after signature, the rule needs a custom script, or every rule change has to go through the services team. Each answer is polite, and each tells you who will be making the change two years from now.
Scripting is the one Diab singles out, where complex rules are written as code inside the tool. "But the problem with this," he says, "is that people who buy the solution end up lacking a bit of agency."[1] He adds: "If you have to make modifications to rules or modifications to the configuration, you don't want to have to deal with an external vendor who has eight months of training on how to configure this."[1]
The other tell sits on a shelf. In another video, Diab holds up a software manual: "Properly built software and modern day tooling shouldn't need a manual that's as thick as holy scriptures."[3] Ask each vendor what training a new scheduler needs before they can change a rule.
Who should be in the room for the demo?
Bring the people who will check every rule change after go-live: whoever owns the collective agreement, and whoever signs off payroll. Diab's own list is close: once a change is simulated, you "pass that on to your payroll people, to your compliance people, or to whoever should do the validation."[2] Watching the five requests being built is how they judge whether they could check a change in that system.
How does WorkAxle handle the five requests?
The five requests follow one rule from the first screen to payroll. In WorkAxle, the rule lives in a no-code builder, and WorkAxle encodes your agreements at the start. After go-live, rule changes are made in the same builder, by your team once trained or by WorkAxle under your support plan. Here is where each request lands.
- Who is qualified. Employees are assigned on their skills, certifications, availability and labor rules.
- Building the rule. Rest, consecutive-shift and day-off rules come from drag-and-drop templates. Custom thresholds, such as overtime, are configurable through the no-code rule builder.
- Dating the change. Rules are effective-dated, so a new clause is staged with the date it takes effect.
- Crossing the rule. As the schedule is built, a shift that crosses a rule surfaces as a warning that names the rule. The person scheduling makes the call, and an override is logged with who made it and when.
- Seeing the result first. The rule builder includes shift-validation and time-evaluation simulation modes, so you test the change, then publish it.
Every change to a rule is tracked as well: who changed which rule, and when.
What can you do before your next demo?
Write down one rule from your agreement exactly as the clause reads, with the date its next change would start. Send it to every vendor on your shortlist with the five requests, ahead of each demo. Then score each demo on what was built in front of you rather than on what you were told. For the rest of the evaluation, such as integration and how a platform handles change, start with the five questions to ask before buying.
The strongest demo test is one of your own rules, built through the front end. In WorkAxle, rules are configured in a no-code builder, and a shift that crosses one is flagged while the schedule is built, with the rule named.