Most AI training vendor pitches focus on what the platform can do. These questions focus on what happens when it breaks, who carries the work, and what leaving looks like. Ask them before you sign, not after.
The short answer
Before signing with any AI training vendor, ask about content ownership and IP, what happens when a model update breaks your configuration, support SLAs and escalation, how success is measured and auditable, what your team ends up carrying, and what the exit terms look like. The demo tells you what it can do. These questions tell you what it will cost to run.
AI training platforms are sold on demos. The demo shows the best case: a well-configured simulation, a carefully chosen scenario, a smooth user experience. What the demo does not show is what happens when an AI model update silently changes the simulation's behaviour three months after you went live. Or what your team is expected to do when a campaign changes and the whole configuration needs rebuilding. Or who carries that work — and who pays for it.
These are procurement questions, not technical questions. You do not need to understand how a large language model works to ask them. You just need to ask before you sign.
This checklist names nobody. It is framed entirely as practical buying guidance — questions that any business evaluating any AI training platform should ask. Use it as a starting framework, not a complete due-diligence process.
Who owns the training scenarios, QA frameworks and call recordings we upload? Do we retain full IP?
Can our content be used — in any form — to train other clients' models?
If we leave, do we get our content back in a usable format, or does it disappear with the subscription?
When an AI model update changes behaviour and breaks our carefully built simulation scenarios, who is responsible for fixing them?
Do you rebuild our configuration at your cost, or do we carry that work?
What is your track record of breaking client configurations on model updates? Can we speak to a client this happened to?
What is the P1 SLA when the platform is down during a live induction cohort?
Is support handled locally or offshore? What are the support hours in SAST?
Do we get a named technical contact, or a shared inbox? What is the escalation path?
How do you define success? Completion certificates, simulation scores, or on-floor performance?
Do we get access to the raw data, or only a dashboard you control?
What happens — contractually and practically — if the platform does not deliver the promised improvement in time-to-competency?
When we launch a new campaign or change our QA scorecard, how quickly can the simulation be updated?
Is that update work done by your team, or do we carry it ourselves?
How many configuration updates have clients requested in the past six months, and what was the average turnaround?
Beyond the licence fee, what internal resource does this platform require — L&D, IT, QA, operations?
Who maintains the simulation content when our campaigns change?
What does onboarding and training our own trainers look like, and how long does it take before we can run independently?
Can the simulations be built from our actual call recordings and QA scorecards — not generic scripts?
Do the simulations reflect our compliance requirements, or a generic framework?
If our calls are used to train the system, what data protection and POPIA obligations does that create for you and for us?
What is the minimum contract term, and what are the exit clauses?
If we leave mid-contract due to non-performance, what are our obligations?
What is the data deletion process, and do we get written confirmation that our data is gone?
Get this checklist by email
We'll send you a link to this page so you can share it or come back to it during vendor conversations.
Most vendors will answer the easy questions fluently — ownership, SLA, data protection — because they have rehearsed those. The revealing answers come from the harder questions: what happens when a model update breaks our configuration? Can we speak to a client it happened to?
A vendor who deflects, who cannot name a specific escalation contact, or who cannot give you SLA breach data from the past twelve months is telling you something useful. That information is available if the vendor is running the platform reliably. If they cannot provide it, ask why.
Red flags to watch for
You should not need to. A reputable vendor will share enough about their platform architecture, support model and pricing structure without requiring you to sign anything first. If a vendor insists on an NDA before showing you a demo or sharing a pricing range, that is itself a red flag worth noting.
Minimum six to eight weeks on a live cohort. You need enough time to see new-hire performance on the floor against a comparable non-AI control group. A two-week demo with synthetic data tells you almost nothing about real readiness outcomes.
For a production system used in induction, any outage directly delays new hires going live. You should expect a four-hour response SLA for P1 incidents and a defined escalation path to a named technical contact — not a shared support inbox. Ask for SLA breach data from the past twelve months.
You do — or you should. Any contract that gives the vendor rights to your training scenarios, QA frameworks, or call recordings is a significant risk. Insist on explicit IP ownership clauses that confirm your materials are yours, cannot be used to train other clients' models, and are returned or deleted on termination.
The ShiftMate Gen 3 platform is built on your own campaigns and QA standards — not generic scripts. If you want to see how a Gen 3 AI agent handles a real conversation before asking any of the questions above, the live demo is open.