×
powered by cludo

What questions should universities ask CMS vendors?

Universities should ask CMS vendors questions that reveal how the platform will help achieve institutional outcomes, how it will work in your actual environment, and what the vendor will be like as a long-term partner.

Many evaluations focus on questions that are easy for vendors to answer: Does it have workflows? Does it support structured content? Does it integrate with our systems? Does it have an accessibility checker? Those questions confirm that capabilities exist. They don't tell you whether those capabilities will work for a decentralized institution with hundreds of contributors. The best questions require vendors to explain, demonstrate, and prove.

Ask the Vendor to Explain Your Needs First

Before letting vendors describe their products, find out whether they understand your institution. Start with:

  • "Tell us your understanding of the outcomes we're trying to achieve with this CMS investment."

Then listen. Do they repeat your list of technical requirements, or can they articulate the institutional problems behind them? Follow up with:

  • "Which of those outcomes can your platform materially help us achieve, and how?"
  • "Where would technology alone not solve the problem?"
  • "Based on what you've learned about us, what will be our biggest implementation or adoption challenge?"

A vendor that has listened carefully should be able to talk about your institution before talking about itself.

Ask for Outcome-Based Demonstrations, Not Feature Tours

Once the vendor understands your goals, ask them to show how the platform supports them:

  • "Show us how you'd help us govern hundreds of distributed contributors without making our central web team a bottleneck."
  • "Show us how contributors prevent accessibility problems before content is published."
  • "Show us how we'd maintain authoritative information once and reuse it across multiple sites and experiences."
  • "Show us how our team would find outdated, unowned, inaccessible, or otherwise problematic content across thousands of pages."
  • "Show us how the platform makes institutional content understandable to search engines and AI-powered discovery tools."

These questions make it harder to substitute a polished feature tour for evidence that the platform can solve your problems.

Give Vendors One of Your Actual Pages

Don't evaluate every CMS using the vendor's perfectly constructed demo site. Hand them a real page from your website and ask:

  • "Show us how you'd model this content in your CMS."

Ask to see the fields, components, structured content, relationships, and editing experience they would create. Then push further:

  • "Show us exactly how each type of contributor would maintain this page."

What does an occasional departmental editor see? What does a site manager see? What can each person change, and what can't they? What happens when someone introduces an accessibility problem? What requires approval? This reveals far more than watching someone edit a vendor-created sample page.

Clarify What "Migration" Actually Includes

Nearly every vendor offers migration services. That doesn't mean they're offering the same thing. Start here:

  • "When you migrate our content, do you migrate it into the appropriate content types, fields, regions, and components, or drop existing page content into a large WYSIWYG field?"

Then go deeper:

  • "Who determines the mapping between our existing content and the new content model?"
  • "Which content is migrated automatically, and which requires manual intervention?"
  • "How are reusable and structured content identified during migration?"
  • "What happens when existing content doesn't fit the new design or content model?"
  • "Who is responsible for validating migrated content?"
  • "How do you handle redirects, metadata, links, documents, images, and accessibility issues?"

A migration that reproduces the old website inside a new CMS may be technically complete while eliminating much of the value the new platform was supposed to deliver.

Request a Detailed Implementation Plan

Don't settle for "implementation typically takes four to six months." Ask:

  • "Give us an implementation timeline based on our project, not a generic one."

Then request a Statement of Work that clearly identifies:

  • What the vendor will deliver
  • What your institution must deliver
  • Who owns each activity
  • Content migration responsibilities
  • Content modeling
  • Template and component development
  • Integrations
  • Accessibility responsibilities
  • Testing, training, and launch preparation
  • Post-launch support

Most importantly, ask the vendor to show how each user type will create and maintain content once implementation is finished. That makes it harder to discover late in the project that the editing model your contributors expected isn't the one being built.

Understand the Ongoing Operational Burden

Features don't operate themselves. Ask:

  • "What ongoing work will our team need to perform to get the value you're demonstrating?"

Then get specific by capability:

  • Personalization: Who creates and maintains the rules?
  • Governance: Who configures workflows and monitors them?
  • Accessibility: What does the system prevent automatically, and what still requires human review?
  • Structured content and search readiness: Who creates and maintains the content models?
  • Integrations: Who builds and maintains them?

Understanding the operational cost of a capability matters just as much as knowing it exists.

Ask About Training and Contributor Adoption

Universities often have hundreds of people who use the CMS only occasionally. Ask:

  • "How do you train different types of CMS users?"
  • "What does onboarding look like when a new contributor joins two years after implementation?"
  • "What resources are available without purchasing additional services?"
  • "How does the CMS help contributors improve their skills while they work?"
  • "How do you help institutions drive adoption across distributed teams?"

A platform that shines in a vendor demo but intimidates occasional contributors invites workarounds and governance problems after launch.

Ask About Customer Success

Customer success should mean more than an occasional email asking how things are going. Ask:

  • "What does your customer success program actually include?"

Then get concrete:

  • "Will we have a dedicated customer success contact?"
  • "How often will we meet, and what happens during those meetings?"
  • "How will you learn about our changing priorities?"
  • "How do you help customers increase adoption of capabilities they already own?"
  • "How do you identify customers who aren't getting enough value from the platform?"
  • "What happens after launch when we want advice rather than technical support?"

You're trying to learn whether the vendor actively helps customers succeed or mainly appears when something breaks.

Ask Exactly What Support Includes

Don't evaluate support based only on the highest tier a vendor offers. Anchor the question to your proposal:

  • "What level of support will we receive at the price you've quoted us?"

Then ask:

  • "What are your standard support hours?"
  • "What are your actual response times?"
  • "Who answers support requests?"
  • "Can we speak directly with someone who understands the product?"
  • "Which support capabilities require an additional fee?"
  • "What happens when an issue is urgent, and can you share your SLA?"

For a lean web team, best-in-class support is a core capability, not a nice-to-have. A promise of exceptional service means little if it depends on a premium package that isn't in your quote.

Ask How Customers Influence the Roadmap

You shouldn't expect to control a vendor's roadmap, but you should know whether customers have a meaningful voice in it. Ask:

  • "How do customers influence your product roadmap?"
  • "How do you collect and prioritize product feedback?"
  • "Can customers see or discuss roadmap priorities?"
  • "Give us examples of capabilities you've added because customers identified a need."

And the most revealing question of all:

  • "Can we talk to long-term customers about how the product has evolved since they purchased it?"

A roadmap tells you what a vendor intends to do. Long-term customers tell you what actually happened.

Ask About Product Investment and Future Readiness

Ask:

  • "Show us the most significant improvements you've made to the product in the last three to five years."

Then ask how existing customers received those improvements. Did they arrive automatically? Did customers have to rebuild templates or migrate to another version? Were major capabilities included or sold as separate products? Continue with:

  • "How does your architecture let us integrate with technologies that don't exist today?"
  • "How can structured content be delivered to channels beyond our primary website?"
  • "How are your APIs supported and documented?"

You're not asking the vendor to predict the future. You're determining how expensive it will be for your institution to adapt to it.

Ask for Evidence

When vendors make claims, ask them to substantiate them:

  • If they say customers become more productive: "How do you know?"
  • If they say the platform scales: "Show us an institution operating at a scale similar to ours."
  • If they say their customers are happy: "What is your customer retention rate?"
  • If they say support is exceptional: "What are your actual support response and satisfaction metrics?"
  • If they say higher education is strategically important: "What percentage of your customers are colleges and universities, and how does that shape your product strategy?"

Evidence doesn't have to be perfect, but important claims should rest on something beyond a sales presentation.

Ask to Use the CMS Yourself

A polished demonstration tells you how well the salesperson can use the CMS. It doesn't tell you how well your team can. Ask:

  • "Can we have access to a sandbox?"

Then give several people realistic tasks to complete without extensive vendor coaching:

  • Have an experienced web professional build a page.
  • Have an occasional contributor update one.
  • Have an administrator change permissions.
  • Have someone submit content through a workflow.
  • Have an accessibility specialist deliberately introduce a problem and see what the system does.

Document where people succeed, where they struggle, and how much instruction they need. This is often the single most honest signal in the entire evaluation.

Ask What You Haven't Asked

Near the end of the process, give vendors a chance to identify gaps in your evaluation:

  • "Based on what you know about our institution, what should we be asking that we haven't?"
  • "What do institutions like ours most commonly underestimate when implementing a new CMS?"

A thoughtful answer reveals both the vendor's higher education experience and its willingness to discuss real challenges rather than sell around them.

The Bottom Line

The most useful CMS vendor questions don't produce yes-or-no answers. They require vendors to explain, show, and prove.

Ask vendors to explain your desired outcomes. Give them your real content and realistic scenarios. Make them show how different contributors will work. Understand exactly what implementation and migration include. Investigate support and customer success. Learn how customers influence the roadmap. Ask for evidence. And spend time using the CMS yourselves.

You're not only evaluating what the software can do during a demonstration. You're determining what it will be like to implement, use, govern, support, and evolve that platform for the next five to ten years.

Back to Part 9: Choosing a CMS for outcomes

Back to the Guide