Executive Summary
Buyers lean on logo walls and case studies because they are quick, not because they are informative. Both are self-selected, unaudited, and say nothing about whether a platform will work for your operation. If a vendor genuinely white-labels, those signals are unavailable by definition — which is an opportunity to run the diligence you should have run anyway. This is a five-part evaluation: a trial on your own historical data, blind reference calls, a live deployment inspection, operational stress questions, and the contract terms that matter most.
1. Why the Logo Wall Was Never Good Evidence
Before replacing it, it is worth being clear about what a logo wall actually establishes — which is very little:
- It is self-selected. You see the customers who agreed to appear, which correlates with satisfaction only loosely and with commercial arrangements rather more.
- It has no time dimension. Logos frequently stay up long after the customer has left. Nothing on the page tells you who is still active.
- It says nothing about fit. A large enterprise logo tells you a vendor can serve a large enterprise with a dedicated implementation team. It tells you nothing about a 150-admission-per-month institute with eighteen counsellors.
- Named case studies are marketing artefacts. The numbers are chosen by the vendor, the timeframe is chosen by the vendor, and the failures are absent by construction.
- It is trivially inflated. Pilots, trials and long-churned accounts all look identical to a live production deployment on a logo grid.
None of this makes logos worthless — they are a weak positive signal. But they are a poor basis for a decision of this size, and their absence is not the red flag it is often treated as. What follows is stronger on every axis.
2. Test One: Trial on Your Own Historical Data
This is the single highest-value thing you can do, and it is the one most buyers skip because a demo environment is easier to arrange. Export two to three months of your real leads, calls, admissions, payments and learner records, and have the vendor load them into a fresh environment.
A demo tenant is built to show the product working. Your own data is built by your own operation, with all of its inconsistencies intact — and those inconsistencies are precisely what will break, or fail to break, in production.
- • Whether your duplicate records can actually be resolved
- • Whether outstanding balances reconcile to your own books
- • Whether reports answer questions you genuinely have
- • Whether counsellors recognise and trust what they see
- • How the vendor behaves when something does not import cleanly
- • Reluctance to load real data at all during evaluation
- • Import failures reported as your data being “too messy”
- • Records that import but silently lose their relationships
- • No exceptions list showing what was rejected and why
- • Demo-only access with a promise that migration “comes later”
You are sending real personal records to a third party during an evaluation, before any long-term agreement exists. Put a data-processing agreement in place first, prefer a masked or partial export where the test does not require exact contact details, agree in writing what happens to the trial environment if you do not proceed, and set a deletion date. A vendor who treats these requests as friction is telling you how they will handle your learners' data later.
3. Test Two: Reference Calls Without Public Names
Confidentiality about public branding does not prevent a vendor arranging a private conversation. It is entirely normal for an institute to decline a logo on a website while being willing to speak to a peer. If a vendor cannot produce a single reference of any kind, that is a real signal — and a different one from having no logo wall.
Ask for a reference comparable to you in size, sector and operating model, and steer the conversation away from features:
- “What broke in the first ninety days, and how long did it take to resolve?”
- “What did you have to change about how you work to fit the platform?”
- “Which part of the migration went worst?”
- “How long did it take before counsellors stopped keeping a parallel spreadsheet?”
- “What do you still do outside the system?”
- “If you were choosing again today, what would you check that you did not?”
A reference who answers all six without a single complaint has been over-prepared. Genuine references have specific grievances, and those grievances tell you more than the praise does.
4. Test Three: Inspect a Live Deployment
Ask for two or three live institute deployments you can look at as a member of the public. You do not need to know who they are — in fact the test is stronger if you cannot tell. Then verify the white-label claim from the outside:
- Check the domain and the certificate. Their own domain, or a subdomain of the vendor's?
- Find the app listing. Whose developer account is named as the seller?
- Read the terms and privacy policy. Which legal entity appears, and is the vendor named?
- Look at page source and asset URLs. Vendor branding hides in favicons, CDN paths and meta tags long after the visible design is clean.
- Trigger a transactional email where a public signup exists, and check the sender identity and footer.
If you cannot determine who built the software from the outside, the white-label claim is real. If you can, you now know exactly what your own learners would see.
5. Test Four: Operational Stress Questions
Feature checklists are answered “yes” by everyone. Ask questions where a vague answer is itself the finding:
- “What is your support response time, and what did it actually average last quarter?” The gap between the SLA and the measurement is the interesting part.
- “What happens when an OS release breaks the mobile app?” Who ships the fix, and within what window, in writing.
- “Show me an incident from the last year and what changed afterwards.” Every platform has incidents; only some learn from them publicly.
- “What is the largest single batch or concurrent live class you have run?” Ask for the number, not an adjective.
- “Which parts of my requirements are configuration, and which are custom development?” Get this split in writing before signing — it is where timelines and budgets actually go wrong.
- “Who owns the roadmap item I need, and what happens if it slips?”
6. Test Five: Read the Exit Before the Entry
The strongest signal a vendor can give is a clean exit clause. A company confident in its product does not need to trap you, and the terms below cost a good vendor nothing to agree:
- Data export in a usable format, on demand and at termination — including attachments and documents, not just database tables.
- Domain and developer account ownership resting with you, so your brand, your app listing and its accumulated ratings survive a switch.
- A defined transition period after termination during which the system remains readable while you migrate.
- Deletion obligations with a timeframe and confirmation, covering backups.
- Fixed pricing terms for the full duration, including whether white-labelling can be repriced at renewal.
- Clarity on who owns configuration and content you build inside the platform.
Run these five tests and you will know more about a vendor than any logo wall could have told you — including about vendors who have one.
We publish this checklist knowing it will be pointed at us, which is the intention. We do not have a customer logo wall, for reasons we have written about separately. We can load two to three months of your real historical data during evaluation, arrange reference conversations with comparable institutes, show you live deployments where you will not be able to tell who built the software, and put the ownership and exit terms above in the contract.
Start with test one
Export two to three months of real leads, calls, admissions and payments. We will load them into a fresh environment and let your own team judge it — data agreement and deletion date agreed up front.