Trust Through Transparency: Building a Demand Central

Trust Through Transparency- Building a Demand Central

Transparency can be scary. Especially at a company when failures are certain to happen. AKA every company. #failshappen. It is natural to want to cover up the low points, whether to keep your team, and yourself looking good or to not worry teammates about challenges that might not affect them anyway. 

So much of what happens in modern ops teams can be traced back to a lack of trust. Data quality. Lead quality. Time estimates. Prioritization. Urgency. It gets to a point where even the things that are completed on time and on budget aren’t seen as wins since there’s little faith that it will hold up as time passes. Then there are the more tactical breakdowns that come with no transparency—individuals are unable to effectively assess and manage their own and their teammates’ capacity due to blurred lines about process. Errors and shortcomings that could be improved on if everyone works together to align on a new plan go ignored. And overall, the company’s dynamic takes a hit as different pieces of the puzzle are left out for each person.

Publishing Your SLAs 

It is so hard to take the first step. But minor changes make a massive impact here. If Quality is a Maturity Model, Transparency is a continuum that culminates with trust. I am a big believer in publishing your service-level agreements (SLAs) to kick off your transparency journey. Starting here gives everyone the chance to see what’s going on, both on their team and company-wide, so you can start to evaluate and get into the real work of identifying what’s good and what’s not and fixing it.

Published SLAs aren’t just good for the company but also for individual employees. They eliminate the questions that come with out-of-the-loop interactions (Why isn’t this done? Why wasn’t I notified about that?) and instead create an opportunity for candid conversations about realistic goals and timelines. For example, every marketing ops team should have a published and agreed-upon SLA for building new programs and for communicating known outages.

You can map out your process, what you’re staffed to handle, and therefore how long a specific task will take. The SLAs should be accessible to everyone so the exact details of calculation are clear. If your stakeholders can’t calculate the SLA on their own, the measure isn’t clear enough. 

There can be SLAs for the critical occurrences across your tech stack, and each new piece of info adds clarity to the bigger picture. Here’s a common example. A major hosting provider has an outage. At company 1, there are no SLAs. At company 2, there is an outage notification SLA. At company 2, discovering that outage and communicating it quickly helps the ops team achieve their goals (SLA to communicate outage met!). At company 1, Sales, Marketing and Web Ops all spend their morning individually discovering the problem and trying to find the root cause, because no one wants to get blamed for it.

A Place for Everything, and Everything in its Place

Don’t ask a Marketo Champion about their file organization system unless you have a few hours to spare. Every great company has a great system in place IN their Marketing Automation tool. Few have a great system for keeping everything else together. Most have something —maybe it’s a Wiki, Sharepoint, Confluence, maybe it is just a Google Sheet—but the where is less critical than the what. A place where the right information is easily consumed, sometimes called Demand Central or sometimes just “that intranet page,” is like a living artifact of trust. It’s the ultimate act of transparency and puts everyone on the same page with details, big and small. 

My favorite example is GitLab’s Marketing Operations handbook. It isn’t just accessible internally but to anyone globally. Everything is spelled out. How to access training, how to get permission on tools. Where to find documentation. Status. 

I first learned about Demand Central at a Marketing Technology and Operations Symposium in New Orleans. For the folks in the discussion, Demand Central was as much about self service as it was about transparency. I’d even argue that self-service is the goal, and transparency and trust are the byproduct of a well-architected site. With a clear view and consistent single source of information, Ops teams can safely assume everyone is in the loop, or would be in the loop if they cared to be.

Commit to keeping it updated (maybe that’s even one of the SLAs you publish), and you’ll have the basis of a center of excellence.

In addition to publishing your SLAs there, your Demand Central can include:

  • A map of your tech stack
  • Rules/how to’s for getting access to a particular piece of technology
  • Agreements on who can access what
  • Ticketing Systems for new users or new issues
  • Project backlog and status
  • Outage notifications 
  • Lead Lifecycle & Scoring models
  • Standard Values for Sources or UTMs
  • Business metrics and tracking (dashboards!)
  • Links to common assets like brand guidelines, logos, and images

A word of caution – don’t post and share everything on one page. Too much information, especially documentation and details can hurt more than they help. Focus on the right information, and information you will commit to always keeping up-to-date.