What to Ask an Esports Platform Vendor Before You Buy

By the time an institution reaches a demo, the decision is usually half made. Someone has a problem, someone else has a product, and the meeting is arranged to confirm a fit that both sides already assume. That is a weak basis for a contract that will hold student data for several years.

This article is a procurement checklist. It sets out what to ask an esports platform vendor before you commit, grouped by the areas where the answers actually differ between products. It is written for schools, universities and federations, and it is deliberately vendor neutral. If you are still working out what this category of software does at all, our explainer on what an esports management platform is covers that ground first.

Why the demo is the wrong place to decide

A demo shows you a product working under conditions the vendor controls. Clean data, one term, a roster of ten, no parent complaint, no staff turnover, no fixture cancelled at two days notice.

Your programme will not run under those conditions. The questions below are designed to surface how a platform behaves in the conditions you will actually meet, which is the only thing worth knowing before you sign.

Send them in writing, in advance. A vendor who answers well in writing will answer well in a meeting. The reverse is not reliably true.

What to ask an esports platform vendor about student data

This is the section your data protection lead cares about, and it is the section most likely to end a procurement quietly if it is left until late.

Where is student data physically stored, and in which jurisdiction. Who is the data controller and who is the processor under our arrangement. What is the retention period, and what triggers deletion. Can we delete an individual student record on request, and how long does that take. What data is shared with any third party, including analytics and hosting providers. Is any student data used to train models or to improve the product for other customers.

Then the age questions. What is the minimum age the platform supports. How is parental consent captured, stored and evidenced. What happens when a student turns eighteen partway through a season.

Ask for the answers to be reflected in the contract rather than in a support article. Support articles change without notice.

Questions about roles and permissions

Most institutional software failures are permission failures. Someone saw something they should not have seen, or could not see something they needed.

Which roles exist as standard, and can we create our own. What exactly can a coach see that an administrator cannot, and the reverse. Can a parent hold an account, and what is visible to them. Can we restrict a coach to their own squad. What is the audit trail when someone changes a roster, a fixture or a permission.

Ask for a permissions matrix. If a vendor cannot produce one, the model is probably informal, and informal permission models do not survive contact with a safeguarding query.

Questions about supervision and duty of care

Every institution running a youth programme carries a duty of care, and a platform either supports that duty or quietly undermines it.

Where do students communicate, and can staff see it. Are direct messages between students possible, and can we switch them off. Is communication retained, and for how long. How does a student raise a concern, and where does that report go. Can we export a communication history if we are investigating something.

Ask specifically what happens outside the platform. If your students end up organising on a consumer chat service because the platform is inconvenient, you have bought software and kept the risk.

Questions about wellness data

If a platform offers anything in this area, treat it as the most sensitive data it holds, because it is.

What exactly does the check-in ask, and who wrote the questions. Is it built on an established framework, and which one. Who can see an individual response, and who can see only an aggregate. Can a student see their own history. How long is it retained, and can it be separated from the rest of the record if a family asks for it to be removed.

Then the claims question, which matters more than any feature. Ask what the vendor says the data does and does not tell you. A credible answer sounds like this. Daily check-ins based on established frameworks like the Hooper Index let an institution track wellness trends over time, and a sustained trend helps coaches identify potential burnout and start a conversation with a student. An answer that reaches beyond that, into clinical or medical territory, is a warning about the vendor rather than a strength of the product. This data exists to support a human judgement. It does not replace one, and it is not a diagnosis.

Questions about proof

You will be asked to justify this programme, probably within a year. Find out now whether the platform will help you do it.

What reporting exists as standard, and can we see a real example rather than a mockup. Which figures can we pull ourselves without raising a support ticket. Can we export raw data, in what format, and is the export complete. Can we produce something a board or a parent body will accept without rebuilding it by hand. Does the platform keep historic seasons, so we can show change over time rather than a snapshot.

The last one matters more than it looks. A platform that resets each season hands you a series of unrelated photographs when what you need is a line.

Questions about onboarding, support and the academic calendar

Institutional software is bought once and lived with for years, and the second year is where the differences show.

Who does the initial setup, and what is expected of our staff during it. How long does onboarding take in practice for a programme of our size. What happens when our programme coordinator leaves and someone new inherits the account. What are the support hours, and in which time zone. Is support included or charged separately.

Ask about the calendar specifically. Institutional years have a shape that consumer software ignores. What happens at the end of an academic year. How do we roll a cohort forward, archive a season and start again without losing history. If the answer involves a spreadsheet, you have found the edge of the product.

Questions about leaving

The best time to ask about the exit is before you sign, because it is the only point at which you have any real bargaining power.

What is the contract term, and what is the notice period. What happens to our data if we do not renew, and in what format do we get it back. How long is it retained after termination, and how is deletion confirmed. Are there charges attached to export or migration. If the vendor is acquired or ceases trading, what happens to our data and our access.

A vendor confident in the product answers this section without hesitation. Hesitation here is itself information.

The answers that should give you pause

A few patterns recur often enough to be worth naming.

A vendor who cannot say where data is stored. A vendor who describes wellness features in clinical language. A vendor who answers a permissions question with a promise to build it for you. A vendor who will not put a data commitment into the contract. A vendor whose pricing moves materially once you mention the size of your institution. And a vendor with no answer for the end of the academic year, which usually means the product was built for teams and adapted for institutions afterwards.

None of these is automatically disqualifying. All of them deserve a follow up question and a written answer.

Using the list

You do not need every answer to be perfect. You need to know which compromises you are making, and to have made them deliberately rather than discovering them in year two.

So send the list, read what comes back, and notice which vendor treats it as a reasonable request rather than an obstacle. That reaction tells you almost as much as the answers do. Knowing what to ask an esports platform vendor is most of the work. The rest is refusing to sign until the answers arrive in writing.

Global Gaming is built for institutions, with student data handling, role based permissions and season reporting designed around how schools, universities and federations actually run. We are happy to answer every question on this list in writing.