One codebase, seven hotels
How Maybourne Hotel Group sends for Claridge’s, The Connaught, The Berkeley and their sister properties from one component library.
Since 2018 I have built and maintained the email system for Maybourne Hotel Group. Each property has its own identity: its own palette, typefaces, voice and footer. Claridge’s does not look like The Emory, and it should not.
They all send from one codebase, on one platform, Microsoft Dynamics 365.
What changes, and what does not
What changes between properties is a small set of values: colours, fonts, the header lockup, footer details, voucher styling. What stays the same is everything that breaks: the table structure, the Outlook conditional code, the mobile stacking, the dark-mode handling, the alt text conventions.
That split is the whole idea. The hard engineering is done once and tested once. The brand expression is a file.
Variants without forks
Each property has standard and retail variants, and the group runs a B2B events programme with its own templates. These are not copies; they are different assemblies of the same components. A fix to the button in one fixes it in all of them.
Adding a property
When a new hotel or residence opens, the work is a token file, any property-specific modules, and a day of rendering tests across the journeys. Not a rebuild, and not a new agency brief.
Reviewing work from elsewhere
Large groups rarely have one supplier. When an agency or platform partner builds templates, the system becomes the standard they are reviewed against: does it use the components, does it respect the tokens, does it render. That review is often worth more than the build.
Get notes like this every two weeks
The Inbox Brief: what changed in email and what to do about it.