What is the best way to document your marketing technology stack?

There's a propensity among marketers to think "more is more" when it comes to martech. It's for this reason we see surveys from Gartner saying marketers use only a third or so of the existing capabilities within their martech stack. This is to say, it's probably the case you're throwing your finite marketing dollars at something you’re not even using.

Documenting your marketing technology stack is crucial. It aligns tools with objectives, identifies gaps, simplifies onboarding, enhances collaboration, showcases value, and keeps you updated on trends. A well-documented stack streamlines operations and ensures that tools serve your marketing goals efficiently.

It mostly depends on the martech that you use. If the CRM already has build in filters and reporting system you can organize and save it within the platform, if not then excel might be the better option.

Documenting your tech stack is like having a blueprint for success. - It helps identify what tools actually serve your strategy and which ones are just collecting digital dust. - Makes onboarding a breeze and collaboration more seamless. In essence, a well-documented stack is your playbook in the ever-evolving game of marketing tech.

One of the biggest values of documenting your tech stack is to highlight redundancies. You'll often find that you have two (or more!) tools that serve similar purposes or a tool that has functionality that you aren't using which can enable you to sunset one or the other!

There's a few different purposes here. #1: Create an inventory This provides clarity on what tools we have, contact details for AEs/CSMs, where contracts live, renewal notice periods, how to login/provision etc. I have these as a series of pages in a knowledge-base. #2: Configuration How do your tools work? How do they fit together? A high-level diagram is useful as a map but is limited. You really need to think less about the tool here and more about the internal business functions they support (which can span many tools). Then create a series of bite-sized pages in your knowledge-base to capture the business definitions and system configuration for each of these internal "products".

Documenting a marketing tech stack is vital for clarity and efficiency. Start by defining your goal, audience, and detail level. Opt for a format, whether it's a spreadsheet, diagram, slide, or software. Inventory every tool, then categorize by function (e.g., CRM, Analytics) or team (e.g., SEO, Paid Ads). Detail features, costs, connections, and how each tool fits workflows. Visualize with flowcharts or diagrams, showcasing tool interactions and data flows. Regularly update the documentation for accuracy, reflecting tool additions/removals, and measure tool performance periodically. Ensure easy access for all stakeholders and foster team collaboration.

When it comes to teach stack mapping, it doesn't have to be "fancy". Even using a spreadsheet or a simple slide to get started is okay! One of the first things I do when starting a new role is get a view of all of the technology that we have. Even opening up a spreadsheet and listing the basics is a good start (tool name, primary use case, owner, users, contract details, pricing, etc., etc.) and you can add to it as you move forward. The key is to just get started!

In addition to the good advice already shared, it goes without saying that documenting processes is a key step. But, that’s just one of the first steps. This should be a living, breathing document that is visible and can gather input from across the enterprise. When choosing a process mapping and/or documentation tool, make sure it enables collaboration, communication and a feedback loop.

The medium of your stack documentation should reflect what you hope to get out of it. Documentation for documentation's sake doesn't help anyone. Your documentation should enable you to make better decisions. It doesn't need to look pretty, hang on a wall, or be something you'd stop to gaze at in a museum. Often, this is easiest to handle in a spreadsheet or table format (something like Airtable). I don't usually go all-in on specifics, but I'm a strong believer in this approach. A table allows you to sort, filter, compare, and sum. You can quickly identify gaps or outliers. A little bit of governance can ensure that you're seeing consistent data in each of the columns. This will help simplify analysis and enable you to move quickly.

Consider who will be reading your MOPs documentation and how best to organize and present it accordingly. For example, Campaign Ops will have very different needs and interests in your documentation than Project Managers, Content Managers, and the Leadership team. I like to organize it into sections, whereby you can see the components of the tech stack, campaign processes, lead lifecycle definitions, reporting legends, and so on. In other words, avoid just dumping everything into a folder on Google Drive for example - the last thing you want after painstakingly documenting everything is for everyone to just ignore it because it's so hard to navigate!

Avoid Ambiguity: Clear, concise descriptions prevent confusion. Over-complexity: Keep it detailed but readable. Overloading with minutiae can deter users. Outdated Information: Regularly update the documentation to reflect current tools and processes. Exclusion: Involve all relevant teams and stakeholders to get comprehensive insights. Ignoring Security: Ensure any sensitive information, like API keys or passwords, is secured or omitted. Bypassing Compliance: Stay updated with data privacy laws and regulations. Failure to Evaluate: Periodically assess the tools for effectiveness and ROI. Lack of Access: Make the documentation easily accessible but secure. Remember, clarity and relevance are key.

If you are like most companies, your tech stack is fairly large and/or complex. Definitely involve others to help provide information for your documentation. Provide an outline and template for others to complete and then assign sections to individuals on the team to gather and provide the information. In addition to driving collaboration and potentially more comprehensive information, you will also save time and expedite the process.

Similar to my suggestion of involving others in the initial documentation exercise, be sure to communicate the process for keeping the information updated and relevant and for adding new tools. Also, assign owners and reviewers!

One thing that can help is to get all of the important information out of the contract documents themselves. Things like start/end dates, package information, specific data/security requirements, opt-out notice information, AE, CSM & Support names and contact details are especially helpful. This is extremely helpful in the case that the person with all of the tribal knowledge about the tools leaves the company suddenly. Another key item is to describe the use case(s) each tool is intended to be used for. This will help document why a tool was originally purchased, and if there is significant overlap between existing tools or potential new ones.

Documentation is extremely important - yet often an unpopular task. Therefore, try to integrate the documentation process into natural workflows. Also, remember that the most important part of documentation is ensuring that all existing and future team members have access to the information. 1. manage your team passwords in secure wallets such as One Password to ensure access at all times. 2. keep it simple: sometimes a shared Google Doc is better than an elaborate project tool 3. set up simple team documentation rules and mark recurring dates in the calendar to update the documentation.