From Process to Precision: Essential Insights on Process Documentation and Data Management

Please introduce yourself.
My name is Regina Dawkins and I am a Senior Advocacy Consultant here at Referential.

How long have you been working in customer advocacy?
Eleven years.

And in that time, how many different programs do you think you have worked in?
Well over a dozen customer advocacy programs.

And of those programs, how many involve some form of data management?
All of them - every single one! A database is a MUST to track who your customer advocates are – their likes and preferences – and what they're doing for the company, as well as tracking them along the journey of their participation with the organization and program.

Are there specific data points within advocacy programs that you feel need to be prioritized? If so, how do you track that efficiently?
If there are multiple people engaging with a program’s database, there should be consistency on the input of data and the key points to be updated to keep records current. This also will enable swift return of accurate matches when searches are run.

What’s the ideal way to ensure that that data is accurate?
It comes down to process documentation and staff following that process. The documentation should be a step-by-step set of instructions covering what needs to be put in the database, updated in the database, and how it's updated in the database, so that that database is something that can be relied on by users.

Is the process documentation always different from organization to organization?
Yes, in terms of the steps you need to take, but the final document is obviously not. Each organization has their area of focus. For some, it is sales requests, and for others it’s marketing requests. Some just focus on customer assets, there are some that are just utilizing the system for analysts requests, so it's a hodgepodge and it could be one or all of the above that the database has to accommodate.

Can you define what the difference is between a sales request and a marketing request?
Well, a sales request comes directly in from the sales teams, and it's typically they want a reference to share their experience with a prospect or customers looking to purchase a new solution. A marketing request, as an example, could be for a speaking opportunity, or an analyst interview, or a webinar.

When you're trying to define what your process documentation is, what elements make that up?
I encourage putting yourself in the user's shoes: Extreme detail is warranted, with a focus on the steps that need to be performed to accomplish the tasks in hand. It's always a good idea to screenshot and display images alongside the step-by-step instructions to ensure a successful outcome for users.

*This image is part of a document, created by Regina, walking an individual through setting up processes in RO Innovation

Are you drafting your process documentation such that it's basically designed for somebody who's picking it up on day one of their responsibilities?
Exactly- imagine someone learning it for the first time. You can't assume that they have any system knowledge; it's a good training document if you're bringing a new colleague in on the account or they're starting with the organization and they're brand new.

How long does it take to put together this documentation, from start to finish?
It depends on, once again, what the organization is focused on in terms of what they want in the database, and it happens over time. I find that as you walk through your day, you're always bumping up against process and it's good to document that. And then over time you can add it. it's just not from one person. It's a way of performing continuous process improvement across the team too.

Once it's drafted, how often do you review it? How often do you update it?
It's a dynamic document. It's always being updated and tweaked, and especially if the organization is moving through a lot of different campaigns and doing a lot with different areas like assets, quotes, case studies. Always ask ‘how do you put that into the system to be efficiently found again?’ Step back and ask ‘what aspects of the system do I need to touch to make sure that that gets into the database and anyone wanting it knows where it is?’ It’s never a fully completed document because things are always changing, it becomes a working document alongside the team.

How do you get the teams to buy in to having a documented, established process? Is that difficult or do people generally understand the need for it?
Generally, it’s embraced. It allows for uniformity, productivity and efficiency. And once you have the steps, you don't have to spend the time to figure out how to do something. It's there for you to follow.

View fullsize

*This image is part of a document, created by Regina, walking an individual through setting up processes in RO Innovation

Do you have some strategies that you suggest for ensuring that data is consistent and accurate across multiple teams or departments, especially when you're putting together process documentation?
If you do have a large team, I think checking in with the team and then looking at the database to see if there's things that don't make sense or just bring attention to some things that don't look right to the team and say ‘moving forward, please focus on this’ and ‘it's in the process documentation, please follow that.’ In regular team meetings, keep referring to the process documentation and say, ‘Hey, if there's something that you're unsure of, if you think it needs to be clarified more or add…’ encourage the team to do that or funnel changes to an editor for it. The process document should be in a shared space, like a SharePoint or Google drive, and there should be editors on the team that can make changes.

Is there data that, in your experience, needs to be prioritized and tracked so that you can effectively manage a reference program or an advocacy program?
It depends on the organization and what their goals and priorities are and what they want to track for metrics. For example, with sales requests there needs to be documentation templates, showing how to open and close requests. List what information to put in, what's valuable for someone else to look at down the line. It needs to be very tight. If there's focus on recruitment or customer onboarding, it's the same thing. You need the templates, you need the process, and you need that understanding of what data needs to go in the system once you onboard somebody. Where does the product detail go? Where do the participation activities go? Who are your points of contact? It can't live in a notebook- it has to be entered into your system.

In your experience, working across the breadth of your clients over the years, when scaling customer advocacy programs, what considerations do you feel should always be made for the evolving needs related to data management?
Don't put the cart before the horse and begin the program without doing all the background work first to set you up for success. The bottom line is that it's quality in, quality out- this will lead to efficiency and productivity and to accurate results. This is especially valuable when putting together metrics and reports when leadership wants to know what's going on: ‘What's happening?’ ‘Who are our advocates?’ And if you don't follow a process, you're not going to get that information. The impact your program will have on the organization as a whole will suffer without it. When you do have that accurate data, the program can show a bottom-line impact on revenue that the C-suite love!

---