Expanding what our emails can do.

We give departments templates to start from and we have custom branded components saved in Emma’s main account. The problem is that Emma restricts subaccounts from accessing those saved rows. Emma’s built-in editor is BeeFree (now called RGE Studio), a drag-and-drop block picker. When a department needs something their template doesn’t cover, the only options it gives them are the default unstyled blocks. Those create rework in approval.

The toolkit gives them 40 branded modules they can fill out, preview, and paste in when the template doesn’t cover what they need.

I came up with the idea, used Claude to help generate and explore module options, then edited and selected which ideas had potential. I built the tool with help from Claude Code. This was a solo project.

Each module has a form. You edit the content, watch the preview update, and copy the HTML. Longer lists like contacts, agendas, or schedules can be uploaded as a CSV from a template. You paste the result into the email you’re already building in Emma. Nobody has to learn a new platform.

The Emma subaccount restriction still exists, but departments now have branded options for what the template doesn’t cover. They don’t have to reach for unstyled defaults that would get flagged in approval or come back to the main account every time they need something custom. 40 modules, ready to drop in. Outlook desktop testing is the last step before it ships.

This is a recent shift. Marketing used to design most emails centrally. Now departments build their own using templates we give them. Not every department uses Emma, and a few manage their own emails with a different client entirely, but most do. Emma’s built-in editor is BeeFree, now called RGE Studio, a drag-and-drop block picker. We have custom branded components saved as rows in Emma’s main account, but Emma restricts subaccounts from accessing those. When a department needs something beyond their template, the only options the editor gives them are the default unstyled blocks. Those create rework in approval.

Someone who isn’t a designer is looking at a block picker and those are all the options. Every email starts looking alike not because anyone chose that, but because the editor made it the path of least resistance.

University emails go to anywhere from a few dozen people to tens of thousands. I think they can be better than the editor allows. Better emails should get more clicks.

Modern layout techniques don’t work reliably in email. CSS Grid, Flexbox, absolute positioning: things that are standard on the web either don’t render or behave inconsistently across clients. Every module is built on tables and inline styles.

Old Outlook desktop is the hardest case. It renders differently from every other client and breaks layouts that look fine everywhere else. The timelines avoid absolute positioning specifically because of this. Known fixes for Outlook travel with the modules: removing BeeFree’s default 30px padding, keeping the format-detection meta tag so iOS doesn’t recolour dates and phone numbers.

The other constraint that shaped the design: the people using this aren’t developers. If filling out a module requires understanding HTML, it won’t get used. That’s why every module has a form with a live preview instead of an editable code block.

Forms, not code

Each module has a form. You edit the content, watch the preview update, and copy the HTML. Longer lists like contacts, agendas, or schedules can be uploaded as a CSV from a template. The goal is that the hardest part should be deciding what to say, not figuring out how to format it.

A separate tool, not a new editor

The toolkit lives on its own, outside Emma. You build a module there, copy the HTML, and paste it into the email you’re already working on. Nobody has to learn a new platform or rebuild emails that already work. The existing workflow stays intact.

A short list of colors, not a color picker

Every module offers a few approved backgrounds: white, tint, forest, and a few others. People get choices without drifting off-brand. A free color picker would produce a hundred different backgrounds by the end of the first semester.

Built for Outlook first

If it works in old Outlook desktop, it works everywhere. Known fixes are baked in. The timelines avoid absolute positioning. BeeFree’s default padding is overridden. Format detection is handled. Every module holds up before anyone sends it to tens of thousands of people.

The toolkit is built. Departments now have branded options for what their templates don’t cover. They don’t have to reach for unstyled defaults and create rework in approval, and they don’t have to wait on the main account every time they want something custom. 40 Missouri S&T-branded modules, form fields, live preview, Copy HTML.

Outlook desktop testing is the last step. Once it clears, I’ll measure click rates against the same departments’ earlier sends. Emma reports that data, so there will be real numbers rather than assumptions about whether better-looking emails actually perform better.

This is a recent shift. Marketing used to design most emails centrally. Now departments build their own using templates we give them. Not every department uses Emma, and a few manage their own emails with a different client entirely, but most do. Emma’s built-in editor is BeeFree, now called RGE Studio, a drag-and-drop block picker. We have custom branded components saved as rows in Emma’s main account, but Emma restricts subaccounts from accessing those. When a department needs something beyond their template, the only options the editor gives them are the default unstyled blocks. Those create rework in approval.

Someone who isn’t a designer is looking at a block picker and those are all the options. Every email starts looking alike not because anyone chose that, but because the editor made it the path of least resistance.

University emails go to anywhere from a few dozen people to tens of thousands. I think they can be better than the editor allows. Better emails should get more clicks.

I spotted the gap, defined what the modules needed to do, used Claude to generate and explore options, then edited and selected which ideas had potential. I built the tool and I’m running the Outlook testing. This was a solo project from start to finish.

How AI fit in

Claude generated module concepts and layout options. I decided which were worth keeping, what content fields each needed, and how to group them. Claude Code wrote the toolkit's HTML and JavaScript from my specs. I reviewed every module and every field before it went in and corrected anything that missed the mark. Every design decision was mine.

1 · Forms, not code

Each module has a form. You edit the content, watch the preview update, and copy the HTML. Longer lists like contacts, agendas, or schedules can be uploaded as a CSV from a template. The hardest part should be deciding what to say.

2 · A separate tool, not a new editor

The toolkit lives on its own, outside Emma. You build a module there, copy the HTML, and paste it into the email you’re already working on. Nobody has to learn a new platform or rebuild emails that already work.

3 · A short list of colors, not a color picker

Every module offers a few approved backgrounds: white, tint, forest, and a few others. People get choices without drifting off-brand. A free color picker would produce a hundred different backgrounds by the end of the first semester.

4 · Built for Outlook first

The timelines avoid absolute positioning so they render the same in every client. Known fixes travel with the modules: removing BeeFree’s default 30px padding, keeping the format-detection tag so iOS doesn’t recolour dates and phone numbers.

The toolkit is built. 40 modules across five categories, all with form fields, live desktop and mobile preview, and a Copy HTML button. The Emma subaccount restriction still exists, but it no longer means every department email has to look generic. Departments have branded options they can use without writing code or needing access to the main account.

Outlook desktop testing is the last step before I share it. These emails reach anywhere from a few dozen to tens of thousands of people. I want every module to hold up before anyone sends one.

When you can’t control who builds the thing, design the parts so the easiest choice is a good one.

The editor isn’t going away, and I’m not going to approve every email before it goes out forever. The toolkit is useful now, but the real test is what happens when a department I’ve never worked with picks it up and uses it without asking.

If I continued this work

• A starter template that combines the most-used modules.
• A short guide for approvers on what to check.
• Retiring modules nobody uses.