Help Center/Knowledge Base Prototypes and Workflows

Help centers don’t typically appear out of thin air, except on very rare occasions…and possibly leap years. The truth is this: a functioning help center requires a lot of work on the back-end in order to be successful on the front. The content I am going to post here highlights a complex period when we were transitioning our help center and knowledge base from Zendesk over to Salesforce.

I am including this content for portfolio purposes as a way to demonstrate help center/knowledge base workflows from conception into a published final product.

Here’s what the original help center looked like in Zendesk, with a couple proposed tweaks for transitioning it over to Salesforce:

I’d also like to point out that the aforementioned help center was my very first experience with knowledge bases, so it was a bit more simplistic in design, but still effective with best-in-class documentation (shameless plug, but not really).

Over the years, the knowledge base would rapidly expand and our infrastructure on the back-end would appropriately evolve. We also grew from one help center to 20 simultaneous operations to satisfy all of our active products (SaaS). However, the cool thing about working with just one help center is that it’s a lot easier to establish a simple knowledge base infrastructure. For this iteration of the help center, the goal was to make it as quick and easy as possible to find the necessary content. This tree diagram illustrates the back-end design of the knowledge base:

Simplistic? Absolutely! That’s the point! When you’re building a help center, you have to realize that the closer the content is to the surface (aka how long it takes a customer to find the answer), the more beneficial it will be for the business. This is one way to help cut down on “time bandit” calls that CSMs have to deal with so frequently (i.e. I forgot my password, please help!).

I wrote up a formal proposal for how we could go about the Zendesk/Salesforce transition and presented it to management (5 page PDF):

salesforce-help-center-proposal

The final product continuously evolved throughout the build process until I settled on a graphical design that was quite a bit different from the original prototype:

We referred to this guy as the “OG” since it was the first published help center that was built in Salesforce. The design would remain exclusive to this iteration, as the help center and all future builds would take on new appearances. Still, what I liked about this version is that it was simple and clean. I was new to Salesforce as a knowledge base solution, so there are things I would change today had I known about them at the time.

When the Zendesk/Salesforce transition was officially complete, I wrote up a memo that was distributed internally that explained the whole scope of the project (4 page PDF):

support-center-pdf

The “OG” would still be used for testing purposes over the years and served its audience well during its brief but notable stint as the company’s “official” help center.