Wouldn’t it be amazing if every piece of software was as simple as a hammer? When you look at a hammer you can intuit what it does, and when you hold one, you more or less know how to use its weight.
Unfortunately, most content or marketing software looks something like this:
Softwares like this are not hammers. They’re not even power drills. They’re more like Swiss Army knives, but even that metaphor is reductive when we’re talking about the complexity of marketing and content software. And as much as software developers provide extensive documentation and training, everyone who encounters a new piece tool is going to have a moment of “WTF am I staring at and how do I work it?”
So if you’re implementing a new technology, I recommend creating some materials to mitigate that WTF moment that every single person on your team is going to have when they open their new tool.
(BTW, the process of choosing a tool should have its own set of documentation but that’s another blog post for another time.)
And so, here follow the seven pieces of documentation you’ll meet in the process of a successful tech change:
1. The contract
A bit of a no-brainer, yeah, but make sure everyone knows the following: what are the terms of the contract? When does it expire? Does it auto-renew, and if so, do you have to give 30- or 60-days notice? What happens to the content created by/managed with the tool after the contract expires? Make sure multiple people are familiar with the contract terms and that you set some calendar reminders for the months before the expiration date.
2. The brief... or something like it
I’ve been a digital strategist for a while, and I know our cliches. A strategist’s traits are as inevitable as a passionate Scorpio: we will insist that everyone aligns on the main objective, which we’ll want to define in some brief-like format.
With a new tool, there doesn’t have to be a single objective (the way I’d advise for kicking off an algorithmically driven marketing campaign). But what your team needs is an outline of the vision for how the tool will help the company. Preferably the brief will outline specifically reasons for why a company chose the tool and what the tool is expected to help the team do. Writing this out will help everyone involved remember why the technology was switched in the first place, especially when they’re at the high point of frustration with the change.
3. A list or chart of everyone in the organization who is affected by the new technology.
And I mean everyone. Everyone who uses the tool and everyone who sees the results, from the summer intern to the CEO. Any IT stakeholders responsible for security, the back-end developers responsible for mapping the data to existing security, and every single content creator or project manager that will be using the software. Loop in the board. All of them! I assure you, it will be more people than you think, and they’ll all have different roles in the process, but they all want to know that this change is occurring to the extent that it affects their work.
A good SaaS will likely have a client service rep to help you determine the roles and responsibilities but if you’re responsible for onboarding the organization onto a new technology, you’re responsible to ensuring all of the people on your chart understand why the company is making the change and how it should help. (Hint: a well developed brief should address all of these changes!)
4. A clear timeline
You can be as agile as Simone Biles, but even she has to practice to learn new moves. It’s going to take time to onboard your team to any new technology — likely weeks or months. As with any production project, make sure deadlines are clear and expectations are set. If you’re transitioning something core to your business processes like your CMS or email platform, make sure that everyone is aware when switches will be flipped.
Allow extra time for routine processes after the tool is implemented, even if the tool is designed to save time eventually. People take time to learn new software (or updates to old software — ask any designer who has needed extra time to complete regular tasks when Adobe launches a new version).
And again, your SaaS client service rep can be a huge help in developing your timeline. Ask them how long regular processes should take and how long you can expect the transition period to last (and if they don’t know, have them ask their current clients).
5. Training documentation and defined best practices.
Again, a bit of a no-brainer, but you’d be shocked at how many companies flip a switch and then just say Have At It to their colleagues. Many companies will create training for one set of stakeholders (IT/ops) and not another (content creators). Most companies won’t train anyone but daily users on what to expect from the tool. Or they just rely on self-guided training materials or an on-site training session from a tool rep.
Here’s the thing: a one-day training from an outside source on a complex tool isn’t a sustainable way to train on a new technology — especially if it’s lecture-style vs. hands on. Many software companies charge for additional training sessions. It’s in your company’s best interest to develop training materials in-house for your business case. They don’t have to be encyclopedic, but having defined best practices and use cases with visual examples custom designed for your company will help everyone understand why and how to use their new technology.
Sending a couple of team members to an offsite training doesn’t really cut it either, unless those team members are invested in passing what they’ve learned along. (Raise your hand if you or colleagues have received in-depth training and then left for another gig within a year, leaving your org with no one who knows how to use a particular tool.) When sending users to an outside training, ask them to create a plan to pass what they learned along to other colleagues. Have them lead a center of excellence and provide the resources they need to do so.
In the onboarding process, I recommend that you create training documentation for executives as well. Give them a high-level overview of a report the tool would produce and let them know how to access it. Demonstrate the value that a new technology can be expected to bring.
6. Designation of champions, a center of excellence, and a Slack channel while you're at it.
In all likelihood, the champions of the tool will not be the daily users of the tool. We’ve all known the director who was excited about a new technology but then didn’t understand how to use it beyond the initial training. Heck, I’ve been that director. That director should not be in charge of how the tool is used on a daily basis!
Delegating tool champions and a center of excellence creates a core group of power users who can assist each other in understanding the tool’s ups and downs. Your power users can be a resource for the rest of the organization as they learn the technology. Designating champions is also an opportunity to give early career colleagues ownership of a new process. (One of my first leadership opportunities was owning use and best practices of an SEO tool for an agency, and it was a solid, if oft-frustrating, experience.)
Make sure that others in your organization know who is in the center of excellence. Make sure that everyone who uses the tool knows how to get their questions answered. Creating a help-related group on Slack or other collaborative chat technology will help all users in the midst of a challenge, outage, or success.
7. Goalposts and reports
Now that you have your training and your champions, create a system for ensuring your technology investment is being used. Create quarterly or semiannual usage reports so you can understand who is using the tool and how. Once more, look to your client services rep to help create these markers of success. Ask whether they have access to the number of logins or the amount of time users are spending in the tool.
Ensure that leaders are on board with ensuring teams have the resources they need to use the tool well.
If after a few months, colleagues are not regularly using a tool, ask why. Do you need more training? More time? Incentives? And if it’s not working… be honest with leadership and with your company. If no one is using the tool because it is confusing and making a simple process overly complicated, then ask why. You’ll be able to spot red flags after the first quarter.
Or, in the best case, everyone will be so excited to use their new tech toy and you’ll want to schedule semiannual trainings on new features.
And generally chances are, if you create the above documentation, have commitment from all the users you’ve identified, and have a sound business case for the investment, you have a much higher likelihood at being successful. The process may feel top-heavy (a bit hammerish, actually), but it will be worth the effort to cultivate your technology stack and help your team succeed.
Hand-picked related content
Deborah Carver
Deborah Carver
Deborah Carver