The procurement process for accessibility software at a university is usually some mix of the accessibility office, IT, a security review, a privacy review, legal, and whichever department will own the budget line. By the time a text-to-speech tool gets to a contract signature, it has typically been reviewed by four or five different stakeholders, each asking different questions, often in sequence, sometimes in parallel.
We have been on both sides of this process. Below is a procurement checklist that an accessibility coordinator or IT buyer can use to run a TTS evaluation efficiently without missing a question that would surface later in the process. It is organized by the stakeholder most likely to care about each item, because in practice that is how these questions actually get asked.
For each item, we will state the question, explain why it matters, and note what a good answer looks like.
1. What exactly will the tool be used for?
The question sounds obvious and is the one most often skipped. Before any vendor conversation, the buyer should have a one-paragraph description of the intended use. Is this a tool for the accessibility office to convert documents for specific students with accommodations? Is it for faculty to create audio versions of course materials for whole classes? Is it for students to self-serve audio versions of readings? Is it for language learners? Is it for all of the above?
Why it matters: the answer changes every downstream evaluation criterion. A tool optimized for accessibility-office workflows looks different from a tool optimized for student self-service. A good evaluation starts with a specific primary use case and a clear list of secondary ones, not a generic "we need TTS."
2. Does the tool support your actual document types?
Course materials come in PDF, DOCX, PPTX, HTML, and increasingly in native LMS formats. Research materials come with additional complexity: dense technical content, foreign-language passages, mathematical notation. Before an evaluation begins, gather representative samples from three or four real courses — not the cleanest examples, but the actual files that students and faculty are working with.
Run those samples through each candidate tool during the trial. A tool that handles a well-structured Word document perfectly may fail on a legacy PDF exported from a decade-old Word file with manual formatting. The question is not "can this tool read PDFs" but "can this tool read our PDFs."
What good looks like: the vendor welcomes document-upload testing during trial and does not gate it behind the most expensive tier. If document handling is locked to paid plans only, you cannot evaluate the thing that matters most.
3. How many and which languages are supported, and at what quality?
For a US high school, English is probably enough. For a large university with international students, 20+ languages is table stakes, with special attention to the languages most common in your student body. For an institution that serves a specific region's language needs — Spanish for Latin American partnerships, Arabic for Middle Eastern ones, Ukrainian for recent student populations — the question is not just "does it support this language" but "how does it handle the language at native-speaker quality."
Test the languages that matter to you with a native speaker on the evaluation team. If you do not have a native speaker for a language you plan to support, assume the quality is worse than the vendor claims. Every vendor will say their French is excellent; not every vendor's French is.
4. What does the voice catalog actually sound like?
Voice quality has bifurcated sharply in the last three years. Cloud-provider voices (the ones shipping in Amazon Polly, Microsoft Azure, Google Cloud) are consistent and neutral but not especially warm. Neural voices from OpenAI, ElevenLabs, and newer entrants are markedly more natural but vary more between samples. Older commercial TTS vendors have voices that reflect the technology of 5+ years ago.
For an audio-pre-read workflow, neutral and clear beats expressive and cinematic. Students want to listen through a syllabus without being distracted by an aggressively warm narrator voice. For language learning, a voice that pronounces words the way they would actually be spoken by a native speaker is more important than overall "naturalness."
Do the listening test yourself. Generate a 60-second sample from a realistic document in each vendor's tool, play them back in a quiet room, and see which one you would actually tolerate listening to for ten minutes.
5. What is the institution's privacy and data-handling exposure?
This is usually where procurement gets serious. The relevant questions:
- Where is the data hosted — US, EU, or configurable?
- Is customer content used to train the vendor's AI models? (The answer should be "no" for any tool used in an educational setting.)
- How long are uploaded documents and generated audio retained? Can the retention be configured?
- Does the vendor offer a Data Processing Agreement (DPA)? Is it signable without significant redlines?
- For US institutions: does the vendor's posture support FERPA-relevant workflows?
- For EU institutions: is the vendor GDPR-compliant as a processor? Where are subprocessors located?
- For Canadian institutions: does the vendor respect PIPEDA and relevant provincial privacy laws?
- Is there an option for EU or Canadian data residency for institutions that need it?
What good looks like: the vendor has clear, written answers to these questions available before the first call, not after the sixth. Vague responses here are usually a sign that the vendor is newer, smaller, or has not taken institutional procurement seriously as a sales motion.
6. What authentication and identity-integration is available?
A tool used by five people can get away with individual logins. A tool used across a campus of 15,000 needs to integrate with the institution's identity provider. The specific questions:
- Is SSO supported? Via SAML 2.0, OpenID Connect, or both?
- Which identity providers has the vendor deployed with before — Azure AD, Okta, Google Workspace, Shibboleth?
- Is SCIM provisioning available for automated user lifecycle management? This matters for institutions that want access revoked automatically when students graduate or faculty leave.
- Is there LMS integration via LTI 1.3? Which LMS platforms does the vendor support — Canvas, Moodle, Blackboard, D2L Brightspace?
For smaller deployments, some of these are overkill. For a campus-wide rollout, they are not negotiable. Expect integration features to be gated behind the vendor's higher-tier plans, and make sure your quote includes them.
7. How is administrative visibility handled?
The accessibility office or IT team that owns the tool needs visibility into who is using it, how much, and for what. The specific questions:
- Is there an admin dashboard showing usage by user, by time period, by document type?
- Can administrators pull usage reports for internal reporting — accessibility office annual reviews, budget justifications, accreditation reporting?
- Is there visibility into plan limits and quota consumption, or do administrators find out they are over quota when users start getting errors?
- Can admins revoke access for a specific user or reset a user's workspace?
What good looks like: admin analytics are available on the plan you are actually buying, not gated behind an enterprise upsell that makes the effective cost 3x what you budgeted.
8. What is the pricing model and how does it scale with real use?
Vendor pricing models vary widely:
- Per-seat licensing — predictable, but expensive if usage is uneven (most users rarely touch it, a few users generate 80% of the volume).
- Character-based quotas — predictable unit economics, but requires monitoring to avoid quota-exceeded errors mid-semester.
- Unlimited-use flat pricing — simple, but typically reserved for the highest tier.
- Hybrid models — a seat count plus a character pool shared across seats.
Get pricing in writing with all relevant taxes, add-on costs (SSO, SCIM, LMS integration, priority support), and multi-year discount options. For enterprise contracts, annual billing with invoice or purchase-order payment is usually available. For small-team contracts, monthly or annual subscription via credit card is the norm.
A common trap: the tool that is cheapest for 10 seats is not the same tool that is cheapest at 1,000 seats. Evaluate at the seat count you expect to grow into, not the one you are starting with.
9. What does the support relationship look like?
Support varies wildly by tier and by vendor. The questions:
- What is the response time for support tickets? Is there an SLA, and at what tier does it kick in?
- Is there a named account manager on the plan you are buying, or only on the most expensive enterprise tier?
- Does onboarding include a live session with your staff, or is it self-serve documentation?
- Is there community support (a forum, a Discord, an active help center)?
For an accessibility office running a procurement process, the most important support-related question is often: "Who do I contact when I have a specific student's document and a specific pronunciation issue that needs to be fixed this afternoon?" If the answer is "open a ticket and wait three business days," the tool may not fit your operational tempo.
10. What is the trial or pilot path?
A procurement decision made without hands-on evaluation is a procurement decision that the office will regret. The questions:
- Is there a free trial? How long and with what limits?
- Is there a structured pilot program designed for institutional evaluation, with multiple seats and enough volume to run a real test?
- Is there an evaluation license with admin analytics so the office can see what usage across a test group actually looks like?
What good looks like: a trial that gives you enough time (14+ days, ideally 21+) and enough seats (at least 3, so multiple stakeholders can evaluate together) to run a realistic pilot, not a 7-day individual trial that ends before the procurement review even gets scheduled.
11. How stable is the vendor, and what is their roadmap?
TTS is a category where vendors come and go. An institution signing a three-year contract is betting that the vendor is still around in three years. The signals:
- How long has the vendor been operating? How is the company funded?
- Are they shipping features regularly, or has the product gone quiet?
- Who are their existing education customers? Can they provide references?
- What is the roadmap for the next 12 months? Does it align with your needs, or does it look like the vendor is pivoting toward a different market?
A smaller vendor can be a great partner for an institution — often more responsive, more willing to customize, better pricing — but the stability question needs an honest answer.
12. What is the exit path?
Every procurement should plan for the end of the relationship from the beginning. The questions:
- Can audio files and user data be exported in standard formats (MP3, CSV)?
- What happens to usage data when the contract ends? Is there a defined deletion timeline?
- Are there contract terms requiring a minimum commitment, or can the institution exit on 30 or 60 days' notice after year one?
- If the vendor is acquired or sunsets the product, what happens to your data?
A vendor that has thought about these questions and has clean answers is a vendor that respects institutional buyers. A vendor that dodges them is one you should be cautious about.
Putting the checklist to work
The usual shape of a TTS procurement from this list looks roughly like this:
The accessibility office drafts answers to questions 1, 2, 3, 4, and 10 — the "does this tool do the job we need" questions — based on trial usage.
IT and security drafts answers to questions 5, 6, and 11 — the integration, privacy, and vendor-risk questions — based on vendor documentation and a security review.
Procurement handles questions 8 and 12 — pricing structure and contract exit — as part of contract negotiation.
The accessibility office and IT together handle questions 7 and 9 — admin visibility and support relationship.
Running this checklist systematically takes 3 to 6 weeks for a mid-size deployment, including a 14 to 21-day pilot period. Running it shortcut-style by skipping steps usually results in a contract that works for the first semester and then produces friction in the second one.
How NaturalTTS approaches each item
We will not pretend this is unbiased — we built NaturalTTS and we think it is a strong fit for education teams. That said, we built it specifically to pass this kind of checklist:
The EDU Pilot is 21 days, 3 seats, and 50,000 characters — designed exactly for question 10. It includes shared workspace, admin analytics, and optional demo calls, so multiple stakeholders can run the evaluation together.
Document handling — PDF, DOCX, and plain text — is core to the product, not an add-on, which addresses question 2.
20 languages with OpenAI and premium ElevenLabs voices available on paid plans address questions 3 and 4.
For questions 5 through 7, our enterprise tier supports SSO, SCIM, LTI 1.3, and admin analytics, and we are happy to walk through the specifics on a scoping call.
If you are running an evaluation and want to compare us head-to-head with the incumbent in your space, the comparison pages walk through exactly how we line up against NaturalReader, ReadSpeaker, Speechify, and ElevenLabs for education workflows.
The checklist applies regardless of which tool you end up with. Running it properly is worth the few weeks of procurement time it adds. The institutions that run a structured evaluation end up with tools that work. The institutions that buy on a single demo and a sales pitch end up switching vendors two years later — which is its own procurement cost, just deferred.