Rooftop Digital built marketing emails at scale, producing across a pipeline that ran from Writers, who submitted creative briefs, through Coders and Designers, to Editors who reviewed completed work before anything went out. That final review covered two layers: brand alignment, advertiser-specific requirements, and grammar on the surface; a preliminary legal check underneath. But the same compliance information shaped the work at every prior stage: Writers had to write within current advertiser guidelines, Coders and Designers built to brand-specified color values and logo files, and every creative needed the right disclaimer language. Working across upwards of 200 brands, that shared body of requirements was substantial, and it lived across departments in different locations and formats, with no central index and no clear owner.
Updates reached whoever maintained a given document; there was no formal process for surfacing changes to the other teams they might affect. Performance data moved similarly: what was working at the vertical or campaign level wasn’t consistently being shared with the people building the work. The pipeline itself crossed two continents, with all teams split between the US and India, working remotely.
The remit was to meet with stakeholders across that pipeline and assess where process improvements could be made.
In a high-volume production system, friction compounds. A writer without ready access to the current advertiser guidelines produces copy that fails the editorial review. The creative goes back, the copy gets updated, the coder rebuilds, and the Editor reviews again: one information gap, multiple repeated handoffs. When a creative reached the advertiser and was rejected there, it restarted the cycle entirely, a particular liability for time-sensitive campaigns where the send window was already fixed.
The hypothesis was that consolidating brand requirements, advertiser feedback, compliance updates, and performance learnings into one shared, actively maintained system would reduce that friction at every stage: fewer revision cycles within the pipeline, fewer advertiser rejections, and the kind of consistent output that builds client relationships.
Equally important was the update problem. Keeping the information current was only half the task; the other half was ensuring the right people knew when something had changed. A cross-team weekly meeting, recently put in place as part of a broader effort to improve coordination, was still taking shape but already provided a shared space that hadn’t existed before. A recurring segment dedicated to system updates gave it a reliable broadcast channel: additions and changes reached all teams at once, rather than arriving late, piecemeal, or not at all.
The geography added weight to both sides of the case. A centralized, accessible system matters more when the people who need it are working across time zones and can’t walk over to ask.
Research, selection, and rollout.
Research
The first phase was in-house: meetings with representatives from every team in the pipeline to understand their workflow and see how their documentation was structured and used. Analytics, Writers, Designers, Coders, Editors, Mailing, Marketing Operations, and Legal were each working from their own set of documents, in their own formats, held in their own locations. Understanding the full picture meant seeing those workflows firsthand: not just cataloguing what existed, but understanding how people were actually using it, what the migration effort would look like, and what capabilities the new system would need to support.
With that scope established, the tool evaluation began. Options included building a purpose-built solution in a prototyping tool, commissioning a proprietary build from the development team, and acquiring an existing platform. A detailed matrix was assembled covering every identified option against the system’s requirements: capabilities, constraints, storage, user limits, cost, and the effort required to build, implement, and maintain. A sample brand built in a prototyping tool served as a proof of concept for the custom-built approach, shown to stakeholders and the exec team to illustrate what a fully customized, purpose-built solution could look like. Progress was shared through weekly written updates distributed across the company and reviewed with the exec team in a follow-up meeting; the proposal for moving forward was built from that accumulating body of work.
Selection
The custom-built and proprietary approaches offered the most structural control and design flexibility. Both came with real constraints: updates would require specialized skills, which would have limited who could maintain the system and made contributor onboarding more complex. An existing tool could trade some of that flexibility for broader accessibility and lower cost, a better fit for a system that needed contributors across teams with varying technical backgrounds.
Lingo, a digital asset management web application, was adaptable enough for the requirements and cost-effective. Their customer service proved responsive as well: after the team had been using the platform for some time, they even incorporated a feature request into a future product update. Managing over 200 brand kits pushed the platform well past its typical use case, but it held up.
Build
The initial brand selection wasn’t arbitrary. A review identified the top campaigns by volume alongside any brands with a history of frequent updates or creative approval challenges. Those were prioritized as the highest-value starting point before expanding to the full set.
Asset gathering proceeded brand by brand: collecting materials from multiple existing sources, organizing them into a common structure, and building out each kit. A checklist standardized what each kit should contain; developed with an ambitious initial scope, it was refined over time as the commonly available assets were confirmed and additional internal content (performance data, research, material that simply didn’t exist at launch) was incorporated as the program matured. An SOP was written and a screen recording walkthrough produced to accompany it, both completed before the broader rollout began.
A resource was eventually dedicated to building out the remaining brands, with weekly check-ins to maintain pace and consistency.
Rollout
Rollout was structured in layers. A company-wide launch update introduced the system, with primary users across the pipeline granted access at launch and an open invitation extended across the company for anyone who wanted it, paired with a cadenced schedule for when additional brand kits would be added. The weekly cross-team meeting provided the introduction: what the system was, why it existed, how to use it. Team-specific follow-up sessions went deeper into each group’s areas, and contributors received separate training covering not just how to find information but how to maintain it.
Ongoing maintenance
Building out the brand kits was only part of the picture. Each team was responsible for the content that came from their work: Editors maintained advertiser feedback and updated compliance materials, Designers added new brand assets, and the pre-writing function contributed research: top and bottom performers, landing page captures, and vertical best practices. The system stayed current not through a single point of maintenance but through distributed ownership, with each team’s representative accountable for their section over time.
What the system produced.
Over 200 brand kits were eventually built into the system. Each served as the authoritative reference for its brand: color values in hex and RGB for Coders and Designers to pull directly, font packages for brands requiring non-standard typefaces, logo files, and guidelines covering brand do’s and don’ts. Disclaimer language was date-stamped so the most current version was always identifiable at a glance; advertiser copy governance updates were time-stamped for the same reason. Flow screenshots of client landing pages and form paths were included for Writers to reference when approaching copy. All of it in one place, consistently structured across every brand.
The results were qualitative but consistent. Revision cycles between teams shortened. Creative rejections from advertisers declined. The system saw regular daily usage across teams, a signal that people were finding it worth returning to. For the first time, there was a system that gave everyone in the pipeline a single, reliable place to look.
After the system had been in use for some time, an advertiser contact reached out to the Editor unsolicited; the note was passed along to the broader team.
”Thanks for making our lives easy with the creatives you turn in. It’s nice not having to ask for a fix or alteration.”
As the system matured, its scope expanded beyond brand assets. Vertical and campaign best practices began to be added, including performance recommendations drawn from the template system described in The Infrastructure of Evidence. Information that had previously circulated informally, or not at all, found a permanent home accessible to anyone with access whenever they needed it.
The broader lesson was about structure. In a high-volume operation, the friction of scattered information isn’t visible as a single cost; it’s distributed across hundreds of small moments: a coder pulling the wrong color value, a writer working from outdated copy governance, an Editor catching something that should have been caught two stages earlier. Centralizing that information didn’t eliminate those moments, but it reduced them consistently, which at scale amounts to eliminating them in aggregate. Having each team responsible for the content that came from their work meant the system stayed current without a single point of maintenance, and without becoming anyone’s full-time job.