Getting everyone ready for a launch
Owning the documentation for a launch, from internal teams to support to customers, so everyone's ready before something new goes out.
I spent five years at Nextep, mostly writing for corporate dining and fast-casual restaurants. The audience wasn't especially technical, so the writing had to meet people where they were. A lot of that work was planning and running the documentation for a rollout, start to finish. It was proprietary software, so I can't show the actual screens, but here's how two of those launches went.
Rolling out multi-factor authentication
The problem
Nextep was the first of the Global Payments companies to require multi-factor authentication. It was a security step every customer would eventually have to turn on, and our customers weren't especially technical. So the real challenge was getting a lot of people ready at once: the internal teams who'd field the questions, the support team, and the customers themselves.
What I did
I started while the feature was still in development. First I documented how it would work for internal teams, beginning with Product and Sales, so they knew the dates customers had to adopt it by and the exact steps to turn it on. Then I wrote detailed release notes and quick reference guides for support. All of it ran off a documentation plan I put together and carried out for the rollout.
Giving support documents they could hand straight to customers cut the volume and frequency of support calls by 50%. Customers were less frustrated, and the internal teams were ready for the questions that came their way.
The company's first mobile app
The problem
When the pandemic hit, restaurants needed a way to take orders on mobile, and they needed it fast. The Product and Development teams built and launched an ordering app in a hurry. It was the company's first mobile product ever, and it shipped in stages: a base app first, then a white-label version customers could brand as their own. Everyone involved had to get up to speed on something brand new at the same time.
What I did
I started with an internal documentation plan. The internal release notes and quick reference guide got Sales ready to encourage adoption and cut down on the questions coming at Development. Then I wrote the full set of customer documentation, release notes and quick reference guides, so Product, Sales, and Support all had something they could share directly with customers.
With every team prepared before the app went live, customers ran into less confusion and support carried a lighter load through the launch. The documentation held up as the product grew, too: what started as a few versions now supports more than 10 white-label builds of the app for the company's largest customer, all running off the same core docs.