30 questions to put to every vendor on your shortlist, worded the same way each time

A rostering tool's whole job is to hold your rules and enforce them. Start there, not with the interface.

1. When one constraint changes, does the whole roster re-solve, or do you patch around the edges by hand afterwards?

   Why it matters A generator that cannot re-solve is a template with a calendar view attached, whatever it is marketed as.

2. Can you list the exact hard and soft constraints the system will check for our unit, in writing, before we see a demo?

   Why it matters A vendor who cannot name the rule set in advance has not actually configured it for you yet, demo or no demo.

3. When two rules conflict, does the system say which one lost and why, or does it publish something and leave us to spot the problem?

   Why it matters Explainability is what turns a rejected roster into a fixable one instead of a mystery.

4. Can we see a roster the tool rejected, and the reason it gave, not only one it accepted?

   Why it matters A system that always says yes has no rules worth trusting.

5. Do you publish a solve-time or performance benchmark? If so, on whose hardware, at what unit size, from a real production instance or a lab setup?

   Why it matters Most published benchmarks are a best case on cherry-picked conditions. Ask for the raw conditions before comparing numbers across vendors.

1. Can you name a live customer we can call, or is the proof a case study we can check against a primary, independent source?

   Why it matters A named reference with no checkable source is not more credible than an anonymous case study you can verify against a published document.

2. Is any published figure attributed to a third party, a regulator, a standards body, an independent audit, or is it entirely the vendor's own marketing copy?

   Why it matters Third-party attribution is the only kind of evidence you can check without simply trusting the vendor.

3. When a number is phrased as 'up to X per cent', what was actually measured, on what sample, versus what was modelled or extrapolated?

   Why it matters The gap between measured and extrapolated is usually where the real story lives, and where an honest vendor will slow down rather than repeat the headline.

4. Does the vendor publish a list of what the product does not do, and does it hold up when you test it?

   Why it matters A vendor with no stated limits either has none, which is unlikely, or has not looked closely enough to write them down.

1. Is authentication delegated to a standards-based identity protocol, OAuth2, OIDC, SAML, or is it a proprietary login scheme built in-house?

   Why it matters A standards-based protocol has been audited by far more people than any one vendor's own login code.

2. Can we federate login against our own identity provider, and is that a genuine protocol-level integration or a reskinned login page that still stores its own password?

   Why it matters Ask to see the actual redirect flow. A real federation never asks for a SkyRoster-specific password once it is configured.

3. Is our data isolated from other customers at the database level, or only by a tenant-id column inside one shared table?

   Why it matters A shared table with a tenant column is one bug away from a cross-tenant query. A separate database structurally cannot make that mistake.

4. Do internal, service-to-service calls in your own backend re-check the original user's permissions, or does an internal call bypass authorisation because it did not come from a browser?

   Why it matters A system with an unscoped internal bypass has a second, unaudited door into the same data.

5. Has the platform been independently security-tested, and are findings closed with a regression test that would catch the same gap reopening, or only a one-time patch?

   Why it matters A one-time patch tells you about the past. A regression test tells you about every release since.

1. Is permission granularity down to an individual business action, approve a swap versus delete a leave request, or only a coarse admin-versus-user split?

   Why it matters Coarse roles force organisations to over-grant access just to make one workflow possible, which is itself a security problem.

2. Are read access and write access independent settings, or does anyone who can edit a screen automatically see everything on it?

   Why it matters Independent axes let an organisation grant visibility without also granting the authority to change what it sees.

3. Is access enforced in the underlying data query, or only by hiding menu items in the interface? Ask to see what a restricted account gets back when it calls the API directly.

   Why it matters A UI-only restriction is cosmetic. The real test is what the API returns when the interface is bypassed entirely.

4. Can a permission be delegated temporarily, for holiday cover or a secondment, without a permanent role change, and does it expire automatically?

   Why it matters Without this, organisations either leave elevated access in place indefinitely or block cover arrangements that operations actually need.

1. Can the system run on our own infrastructure, not only the vendor's cloud, and is that the same codebase or a separate, lagging product?

   Why it matters A self-hosted option built as an afterthought is usually missing features the cloud version has, and falls further behind with every release.

2. If we need an environment reserved to us alone, is that a standard, already-practised deployment shape, or a bespoke one-off project quoted from scratch?

   Why it matters A vendor who has done this before can describe the exact mechanism. One who has not will describe intentions.

3. Where does our data physically reside, and does that follow the deployment option we choose, or is it fixed regardless of what we pick?

   Why it matters Some vendors advertise 'your choice of region' while every deployment still writes to the same shared infrastructure underneath.

4. How do releases reach a self-hosted or dedicated environment: manually by an engineer, or through a repeatable, auditable deployment pipeline?

   Why it matters A manual release process is where undocumented, unrepeatable changes creep into what should be identical, versioned software.

5. What is the actual decommissioning process if we leave: what happens to our data, our identity configuration, and our backups, in what order, confirmed how?

   Why it matters A one-line assurance is not a process. Ask for the runbook, or the fact that none exists.

1. Is there a field-level, before-and-after change log for configuration and staffing decisions, or only a generic 'last modified by' stamp?

   Why it matters A generic stamp tells you something changed. A field-level log tells you what it was, what it became, and who did it.

2. Are uploaded personal documents, IDs, licences, medical certificates, encrypted at rest, and is that the default or an option we would have to request and pay for?

   Why it matters Encryption offered as a paid add-on usually means most customers are not actually protected by it.

3. How long is our data retained, and is that a fixed vendor policy or a setting our organisation controls?

   Why it matters A fixed retention period that does not match your own legal obligations becomes your problem, not the vendor's, the day a regulator asks.

4. If an employee asks what data is held about them, can you describe the actual process for answering that, not just point to a policy document?

   Why it matters A policy document proves a policy exists. It does not prove anyone could execute it by Friday.

1. Is the price list published with the rule that derives each figure, and does the written offer reconcile to it line by line, or is the number assembled from scratch in the sales conversation?

   Why it matters A price you can rebuild yourself is a price that survives a second meeting. A number that appears only in a proposal is easy to undercut before signature and easy to walk back after it.

2. What is the support response commitment, in writing, and does it change depending on which deployment option we choose?

   Why it matters A verbal 'we're very responsive' is not a commitment. Ask for the number and the exceptions to it.

3. If the vendor is acquired, merges, or shuts down, what access do we retain to our own data and configuration, and through what specific mechanism?

   Why it matters A reassurance is not a mechanism. Ask what actually happens to the database, the source, and your export rights.