Rolling Out New Course Evaluation Software: An Implementation and Change-Management Guide (2026)

You have run the RFP, scored the vendors, signed the contract, and agreed the data processing terms. The hard part is only just beginning. The single biggest predictor of whether a new course evaluation platform succeeds is not its feature list - it is whether academics trust it, students answer it, and committees act on it in the first two cycles. That is an implementation and change-management problem, not a software problem.

This guide covers the phase that begins after selection, and it is distinct from switching off a legacy tool. If you are still choosing, start with our RFP and requirements guide. If you are moving data and history off an incumbent system, read the migration guide. What follows assumes the decision is made and the question is: how do we go live without losing response rates, faculty goodwill, or accreditation evidence?

Three rollout models, compared

There is no universally correct rollout shape. The right one depends on institution size, political sensitivity, and how mature your current process is.

Rollout model	Scope of first cycle	Risk	Time to full value	Faculty buy-in	Best when
Pilot	1-3 volunteer departments	Low	Slow (2-4 cycles)	High - champions emerge	Culture is sceptical; the tool changes the method (e.g. moving to AI-moderated interviews)
Phased	Faculty-by-faculty or campus-by-campus	Medium	Medium (2-3 semesters)	Medium - momentum builds	Large multi-faculty universities; integration complexity is high
Big-bang	Whole institution at once	High	Fast (1 cycle)	Low if mishandled	A hard legacy-contract cut-off; strong central mandate; simple like-for-like replacement

A pilot buys evidence and advocates at the cost of speed. Big-bang buys speed at the cost of recoverability - if response rates crater in week one, they crater everywhere. Most European universities with more than a few thousand students land on phased, and reserve big-bang for cases where a legacy licence genuinely expires.

The five workstreams every rollout must run in parallel

A rollout is not one project; it is five that must be sequenced together.

1. Governance and policy sign-off. Before a single survey goes live, the instrument, cadence, confidentiality thresholds, and reporting lines need approval through your quality committee. If you do not yet have a written policy, build one now - accreditors increasingly expect a public course-evaluation policy, not just a set of scores. Getting sign-off early also pre-empts the "who authorised this?" objection from academics.

2. Technical integration and SSO. Roster feeds, single sign-on, and LMS delivery are where go-live dates slip. Agree the identity protocol (SAML 2.0 / OIDC), the roster source (SIS API, LTI Names and Role Provisioning, or SFTP), and deprovisioning (SCIM) before the first cycle. Our SSO, LMS and SIS integration security review is the checklist to run with your IT and information-security teams.

3. Communications and buy-in. More on this below - it is the workstream most often under-resourced.

4. Response-rate strategy. A new tool is the moment to reset expectations about participation. Decide in advance on in-class response time, reminder cadence, closing-the-loop messaging, and whether results are gated behind a response threshold before release.

5. Closing-the-loop. Design the action-tracking workflow before the first results arrive, not after. If academics see that the first round of feedback produced visible change, the second round answers itself. Compare how platforms handle this in our action-tracking comparison.

A T-minus rollout timeline

A workable first-cycle calendar for a phased rollout:

• T-minus 12 weeks: Governance sign-off of instrument, policy, and confidentiality rules. Name an executive sponsor and a project lead.
• T-minus 10 weeks: Kick off technical integration; provision SSO in a test tenant; agree the roster feed.
• T-minus 8 weeks: Configure surveys or interview briefs; localise into required languages; run an accessibility check (WCAG 2.1 AA / EN 301 549).
• T-minus 6 weeks: Train administrators and local coordinators; brief course reps and the students union.
• T-minus 4 weeks: Communications campaign to staff and students; publish the "what changes and why" note.
• T-minus 2 weeks: End-to-end dry run with real rosters on a dummy module; verify reports and anonymity thresholds.
• Go-live: Launch the pilot cohort; monitor response rates daily for the first week.
• T-plus 4 weeks: Publish the first "you said, we did" actions; review lessons; expand to the next phase.

Winning faculty and student buy-in

Resistance to new evaluation software is rarely about the software. Academics fear three things: that scores will be used punitively, that the tool adds workload, and that student comments will turn abusive without recourse. Address each explicitly.

• Frame the purpose. State in writing that evaluation is formative and developmental first, and where results feed personnel decisions, say so honestly. Ambiguity breeds distrust.
• Reduce workload, visibly. Show that integration means no manual roster uploads and no hand-coding of open text. If the platform analyses qualitative responses automatically, demonstrate it on a real (anonymised) dataset in a staff session.
• Protect staff. Confirm the moderation and duty-of-care workflow for harmful comments before launch, and point staff to it.

For students, the single most powerful lever is proof that answering changes something. Recruit course representatives as messengers - the QAA UK Quality Code expects providers to support and train student representative systems precisely so this dialogue happens at course level. Students who see last cycle actions before this cycle survey respond at materially higher rates.

Where each approach fits, and when to use vendor professional services

Be honest about your own capacity. A lean quality office rolling out across forty departments should not attempt a self-service big-bang. Most enterprise vendors offer implementation help: Explorance, for example, sells Blue Professional Services for exactly this - one US institution publicly selected Blue together with Explorance Professional Services to run its course-evaluation implementation end to end. Paying for guided onboarding is often cheaper than a failed first cycle that poisons faculty trust for years.

A competitor may be the better fit if your requirement is a like-for-like replacement of a mature paper-scanning process and your culture is hostile to changing the method. In that case a phased swap to an established Likert-survey platform such as EvaSys or Explorance Blue minimises disruption. If, however, the goal is to fix the things static surveys cannot - low response rates, shallow open text, no probing - then the rollout is also a method change, and a pilot with visible champions beats a quiet swap.

How Koji shortens the rollout

Koji is AI-native: instead of a static Likert form, students have a short, adaptive AI-moderated interview that probes their answers and produces analysed themes automatically. That changes the rollout maths in three ways. There is no open-text backlog to hand-code, so the closing-the-loop workstream produces visible actions within days, not months. Standardised, bias-aware moderation means every cohort is asked in a comparable way, which reassures academics worried about fairness. And because it runs on EU-hosted infrastructure under a GDPR Article 28 data processing agreement, the compliance workstream is a review, not a rebuild. The shared AI interview engine also powers general user and customer research on koji.so, so the underlying technology is proven well beyond education.

None of this removes the human work of governance, communication, and committee action - but it removes the parts of a rollout that usually stall.

Frequently asked questions

How long does it take to implement course evaluation software?

For a phased rollout at a mid-sized European university, plan roughly 10-12 weeks from contract to first go-live cycle, dominated by governance sign-off and technical integration rather than software configuration. A single-department pilot can launch faster; an institution-wide big-bang needs more, not less, lead time.

What is the difference between the RFP, migration, and implementation phases?

Selection (the RFP) decides which tool; migration moves data and history off a legacy system; implementation is the change-management work of going live - governance, integration, buy-in, and the first closing-the-loop cycle. They are sequential and each has its own risks.

Should we pilot or roll out to everyone at once?

Pilot when the tool changes the evaluation method or your culture is sceptical; phase when you are large and integration is complex; use big-bang only when a legacy licence expires or you have a strong central mandate and a simple like-for-like swap.

How do we protect faculty from abusive student comments during rollout?

Agree a moderation and duty-of-care workflow before launch: automated flagging of harmful content, a defined escalation route, and a stated policy that abusive comments are removed from reports. Communicate it to staff before the first survey opens.

How do we stop response rates falling with a new system?

Publish visible actions from the previous cycle before opening the new one, recruit trained course representatives as messengers, protect in-class response time, and consider releasing results only once a response threshold is met.

Do we need the vendor professional services?

If your quality office is small relative to the rollout scope, guided onboarding usually costs less than a failed first cycle. Larger central teams with prior survey-platform experience can often self-serve a phased rollout.