Fixing a training portal's 26 system emails and restoring the survey link

The situation

After the portal moved to a new LMSLMS (learning management system): Software that runs online courses and training: who can see what, who has enrolled and who has finished.Glossary, fewer participants were completing the post-session survey. One reason: the old booking confirmation carried the survey link, and the new one didn't.

The new platform's email templates also needed work. Some fields mapped to the wrong data, some links were broken, and some layouts fell apart on phones. Participants had also asked for a simple way to add sessions to their calendar.

My role

I owned the email set from review to release. The partner owned the wording and signed it off. The vendor wired the templates into the platform. I reviewed, rewrote and tested, packaged the handover, and checked the release on live.

What I did

Reviewed every email against the spec

I went through all 26 emails word by word and logged 48 changes. I restored the survey link, added an add-to-calendar link with a small PHP helper, and switched greetings to the participant's first name, with a safe fallback when it's missing. The partner's rewrites went into one tracked-changes document, so sign-off happened in a single pass.

Made the handover hard to get wrong

I rendered every template with sample, long and missing data, across three template engines and at three screen widths, and fixed what broke. The handover was one folder of finished templates, a screenshot of every email, and short developer notes. The developers only had to copy the folder and map three variables.

Got the release moving

The emails were due in the same release as two tools still awaiting approval. With the director, I agreed a release that included the checked emails and kept the unapproved tools switched off. I tested that build on staging across three roles before giving the OK.

Checked live before anything reached users

Before the release, I checked the live site's background jobs and found about 3,200 old sign-in notifications waiting in the queue. Switching the jobs on as planned would have sent them all to real users. I flagged it in writing, with the steps to clear the queue first. None of those messages went out.

During the late-night deployment I redirected all live email to myself. The next day I checked about 200 live pages using five role accounts, and triggered every immediate email to confirm it arrived correctly. What I found became 10 tracked items.

What I'd do differently

• Write each email's trigger into the spec. Who receives it, what triggers it and when it sends should be agreed before anyone writes a template. Several triggers had to be clarified late.
• Put queued messages on the go-live checklist. Checking scheduled tasks and the message queue should be a standard go-live step, not something found during release checks.

Tools and skills

• Email: Moodle email templates (Mustache, HTML/CSS), responsive email layout, calendar (.ics) links
• Delivery: tracked-changes sign-off, developer handover packs, staged release planning
• Quality: render testing at several screen widths, release checks with role accounts on live
• AIAI (artificial intelligence): Here, AI assistants such as Claude that help with drafting, scripts and checks.Glossary: an AI assistant (Claude) for render testing and drafting, with every result checked by me