A Pardot Admin’s Guide to Documentation Best Practices

If you won the lottery tonight, could a coworker step into your shoes and carry on business as usual? Documenting your processes and saving them in a place your team members can easily access allows teammates to cover for one another (and you!) and expand your team without losing a beat. Here are some insights on what to document, how to upkeep your files, real-life examples, and documentation best practices.

Why is Documentation Important?

Benefits:

• Consistency and quality control
• Efficiency
• Risk mitigation

Risks:

• Loss of time and money
• Appear uninformed
• Incomplete processes

Documenting processes creates standardization and efficiency across the internal team and external stakeholders, eliminating waste. When you document problems and solutions for historical reference, this prevents future errors and re-work to solve the same problem.

There’s also risk mitigation, where you are enforcing recording data or processes to show compliance with industry requirements such as HIPAA or GDPR.

If you don’t document, you risk looking unprepared, not having projects complete, and losing time and money having to train someone new. You’ll also have inconsistency in deliverables and results.

Who needs documentation?

Everyone uses documentation in some form or another… probably every day. You may reference Salesforce’s help website when you’re looking for a solution or read an implementation guide. Those are both forms of documentation. The type of documentation you need may be different depending on your role: end users, consultants/agencies, leadership. I’ll touch on roles a little later.

What is Documentation?

Documentation is any communicable material that is used to describe, explain, or instruct. There are many types including:

• Executive Summary
• Strategic Brief
• Solution Design
• System Configuration
• Job Aid
• Regulations

Not every piece of documentation needs to be in-depth. Some things are straight forward like how you sign into a system. For more complex projects, like a platform implementation, you’ll want to use these components:

• Business Objectives
• Solution Design Plan
• High level flows / relationships
• Dependencies
• Impact
• Configuration basics:
  what / how / when

Define the background, problem, and solution, then also highlight the flows and relationships along with any dependencies. Think about if you make a change down the line, what will be affected? Document how to manage the changes, how to navigate to the solution (for example: if you implemented a new report, show how to access the report), then also how to update it when needed.

It’s basically saying at the end of a project: here’s what we did and why. You’ll want to show everything you configured and why you came to that solution. Why did you do it that way?

What should I document?

Documentation doesn’t have to be pretty, especially for the internal team. Open a notepad and jot down the steps. Different roles will need to consume different documentation. Think about the audience of the document and the stakeholders involved.

Examples

• Leadership: executive summary that includes risk assessment, strategic brief with objectives, product road map, document decisions/approvals
• Consultants/Agencies: new Marketing Cloud platform implementation plan, meeting notes, software architecture diagram
• End User: job aid for how to add users to a system, a process for adding new campaigns to Salesforce, or data flow from LinkedIn to Zapier to Pardot

Be sure to document decisions and approvals, like a variance, where you need to temporarily deviate from the previously approved process. Don’t just send an email to the team to change a process, this will not be easy to implement or reference.

In an implementation plan, if someone has a question about a particular aspect of the configuration, the answer is readily available. Consultants should make documentation a priority to ensure a seamless knowledge transfer occurs at the end of a project.

End users need the technical how to, like what the campaign hierarchy should be in Salesforce or what data flows from LinkedIn to Zapier to Pardot. They will likely need to know how to use it as well and how to make changes to the flow.

What about version control?

Does the document you’re working on need versions? Things like meeting notes won’t ever need to be edited and won’t need versions. Version control is important for historical reference and for regulatory compliance.

The program you created the document in (like Word), could store previous versions. Also, where you store the file could save version history (like MasterControl).

If needed, include a high-level revision history at the beginning of your document. It’s a when, who, and what. When was the edit, who edited it, and what was edited. This makes it possible to roll-back or reference a previous version when needed.

Create a naming convention

• Be consistent
• Short but descriptive
• Avoid special characters
• Include the date
• Include version number (if needed)
• Consider compliance requirements
  • Section 508

Establish a naming convention and be consistent. Document the naming convention and make it a policy or procedure. This will help everyone find the appropriate document quickly. Also consider compliance requirements, like Section 508: the document name needs to be 30 characters or less with no spaces or special characters. This is important for screen readers.

Storing documentation

Store your documentation in a central location and create a repository. Constantly reference and use it. People will eventually go there for answers first, instead of coming to you. Identify stakeholders and consider who should and shouldn’t have access. This may influence your document format type and where it’s store.

There are many possible storage solutions out there, each with their own pros and cons. Dropbox has no version control and is not collaborative. SharePoint has version control and is collaborative and you can set permissions to give certain people access to certain files. MasterControl has version control and variances. But no matter what you choose, the important part is having the documentation and using it consistently.

Examples

• Folder hierarchy on your server
• SharePoint
• Salesforce Libraries
• Dropbox
• OneNote
• Google Drive
• MasterControl
• Asana/Monday/Trello
• Jira/Confluence

Documentation Best Practices

Do a health check.

• Identify any gaps in current processes
• Is there knowledge you may only know?
• New initiatives coming
• Update existing documentation

List out your current processes. START SLOW! Focus on one department or project at a time and capture all related functions. Write down processes or steps that you may know that someone else may not. This will allow you to take your vacation in peace! It’s not about losing job security; it’s eliminating a single point of failure. Think about if you won the lottery or had an unexpected injury, could your team carry on without missing a beat?

Write down any existing documentation as well and plan for keeping it up to date.

Plan ahead.

• Leadership/stakeholder support
• Implement a timeline
• Establish roles and responsibilities
• RACI
• Create templates to streamline
• Prioritize

Write down the risks if you don’t document and share it with leadership. Create a timeline and stick to it, otherwise people will drag their feet and it won’t get done. Establish roles and responsibilities with RACI (who’s responsible, who’s accountable, who’s consulted, and who’s informed). Create a template where it makes sense. Why start over every time when you can reuse what’s been created? Using the same format is efficient and makes the document easier to consume.

Identify your top 3-5 priorities, starting small and building consistently is critical for success. Set aside time every week to work on documentation. It may seem like it will take a lot of time in the beginning, but it will save a lot of time at the end.

What do you only know?

Take a minute to write down something you do that no one else on your team may know.

Download the worksheet

Download this simple spreadsheet to help you start visualizing the documentation you have for processes. Focus on one department, project, or platform at a time. Be sure to get input from other members of the team, this will help you find out what’s missing and needed. Use this worksheet to help you keep track of what has been updated as well. After you download this, put what you wrote down in the previous paragraph as your first item on the Identified Gaps sheet. Edit the worksheet to fit your team’s needs.

At the very least, if you don’t have larger organizational buy in to do proper documentation, you could document your own knowledge and eliminate gaps within your functions.

What does this mean for a Pardot Admin?

Pardot Administrators are often one-person teams. Ensuring you have proper documentation eliminates that point of failure if you were needing to be out of office or took another job offer. This will also save time and money by not having someone else spend time trying to figure out what was set up and why. Remember, you may have nuances set up in your account that others may not. For example, when you import a list, maybe you always need to add required Salesforce fields to the spreadsheet.

Consider:

• How to import
• Process for new leads
• MQL/SQL process
• Engagement Studio Programs
  • How prospects enter and exit
  • Automation rules or dependent fields
  • Email templates, landing pages, forms, and files
• Email approval process
  • Third-party email proofing tools used like Litmus or Email on Acid
  • How to set up your Litmus testing
• Third-party workflow tools
  • Examples: Zapier, Workato, LeadsBridge, or Automate.io
  • How are Pardot and Zapier connected?
• How do you edit the data flow or add a new one?
• Project management platforms
  • Examples: Trello, Asana, and Monday
  • Create a template for gathering information to use in Pardot emails, forms, and landing pages
• Salesforce and Pardot
  • Process Builder or Flows updating data in Pardot
  • How to create new users

Example Pardot Documentation

I’ve created a lot of end-user documentation in the last year. I knew I would be out on maternity leave and I was the only one on my team who administered and worked in Pardot.

I spent a lot of time documenting how we had our Pardot set up, like naming conventions, tags, campaigns. I also document our processes, like how the team handled MQLs coming into the system, for example.

The key stakeholders were listed on the steps that included them. To make finding the assets in Pardot easy, I included links to everything referred to in the document. If I mentioned an email template, I linked to it. If I mentioned an automation rule, I linked to it.

Then I saved these documents in our shared SharePoint folder so everyone who needed access, had it. As I worked in Pardot, I would try to capture a “how to” for everything I did that day. Each day that new processes came up that I hadn’t documented yet, I would take a break from what I was doing and document it. A few of these examples are below.

Example: Process for New Pardot Prospects

This example is what the team needed to do when a new prospect came into Pardot. I have an objective, steps to follow with screenshots to help clarify, and links to the assets in Pardot.

Example: How to Create Custom Redirects

This example is a how to for Pardot Custom Redirects. It also reiterates the naming conventions and other agreed upon processes with the team. Everything is in one place and there isn’t a need to reference multiple documents.

Example: Engagement Studio Pieces

It is a good idea to use a tool like LucidChart or Draw.io to map out the flow of your Engagement Studio Program before starting. This allows you include the “behind the scenes” actions that don’t go into the actual program, like a completion action on a form that sends a prospect to a list to enter into the program. This example also has a form of version history near the beginning to make it clear when and what changes were made.

 

Example: Forms Used on Website

This example is a list of forms used and which web page they are on. This makes it easy for the team to make any updates needed. To export your list of forms, in Pardot Lightning, navigate to Content > Forms. Under Tools in the right corner, choose CSV export. This will give you a starting point to start compiling your list.

Recap

It can be overwhelming to think of all the possible details you may need to document. Start slow. Think of questions you get asked frequently. Can you document the steps for a coworker to pull their own report? Can you create a list of forms and the web page they are on? Are you always having to ask who the email sender is or what the preheader text should be? Create a template for the team. Once you get started, be sure to consistently reference it. Eventually your repository will become the source of truth for processes and how-tos.

This blog is a follow up to Marah’s Documentation Best Practices presentation for the Twin Cities B2B/B2C Marketers User Group. View the presentation here.