Each case describes the important inputs and the behavior being tested. A successful test shows that behavior in that case; it does not prove that every organization will get the same result.
Use fictional teams, not customer records
The published examples use fictional employees, shifts, locations, and rules. That lets readers see the scenario without exposing a customer's workforce data.
Explain what went into the test
We describe the employee count, shifts, dates, staffing needs, leave, work patterns, hour limits, locations, or other details that materially affect the result.
A software test is not a customer result
A test can check whether a scheduling rule behaves as expected. It does not show how much time or money a customer will save, or whether the same schedule will work for another team.
Keep each result in context
If one test fills every shift, that describes only that team's inputs. Different staffing needs, rules, or employee availability can produce a different result.
Review the explanation when the product changes
We review these pages when scheduling behavior changes so the public explanation continues to match the current product.
Continue exploring