When I moved to Seattle and began working at LexBlog as a full-time Account Manager in the summer of 2013, one of the first things I began doing was organizing my inbox in a way that would let me easily find a certain class of questions and answers. This was primarily because at that time, LexBlog had no central repository of documentation for publishers using our platform. In this world, questions were a dime a dozen, but answers were in short supply or trapped in the brains of long-time LexBlog employees. Fortunately, the same or similar questions would come up time and time again, and each new question would get tagged and organized in a way that let me find it and other similar questions so that the next time it came up, the answer was just a few clicks away.
This might seem like a product piece for Gmail (it’s not, but Gmail sure is swell!), but far from it. This was an onerous, time-consuming process for all parties involved. On my end, my inbox was a mess, with emails from dozens of customers every day asking me how to do something when just the day before a colleague of theirs at the firm had asked the same question. Meanwhile, our customers were wondering how to do something and, finding no resources at their disposal, would email yours truly and wait patiently for a reply. When an employee at a firm would leave, someone new would take on the responsibility of managing the site and have to relearn everything on the fly.
We made it through those days through the power of fantastic employees who were truly dedicated to answering questions thoroughly and with a smile on their face. LexBlog is a company that prides itself on providing top-notch service and support, and it was (and still is) a necessity to be quick, nimble, and thoughtful, but things have gotten considerably better over the years. Those same great employees still exist, but our systems and knowledge management tools are considerably different.
First off, we’ve moved away from a centralized model of support where customer requests are funneled to a single employee’s inbox, to one where there are many hands making quick work of customer requests. This has been made possible through the power of Zendesk, which LexBlog uses to manage the queue of requests and projects. Secondly, we now have a support center, also powered by Zendesk, with hundreds of articles on how to perform a myriad of tasks inside our platform, and a full-time technical writer, Ted Cox, who has taken it upon himself to document all of the pieces of our platform that have for so long gone undocumented.
Almost two years ago, we moved from Get Satisfaction to Zendesk’s “Guide” product, and while there are shortcomings, the bevy of APIs provided by Zendesk have made it easy to bring contextual help and a support center inside the publishing platform. This alone has been an amazing transformation, but after a refresh of the LexBlog.com website, and a renewed focus on bringing more control to our publishers, we’ve decided that it’s time for an overhaul of the support center to make it easier to find content, get support, and review tickets and communications with LexBlog.
Ted has been working on this for a while now; thinking about different ways to organize LexBlog’s documentation and adding new content regularly, but I had the opportunity to get my hands dirty for the first time today as I updated some tools under the hood. This was the first step in redoing the look and feel of the support center – a task that Ted, Brian Biddle, and myself are all eager to begin.
Step one: I had to upgrade our existing product to take advantage of these new features. This wasn’t quite as easy as advertised as our old theme was home to a few files that are no longer supported in the new theming experience. After a several hour long treasure hunt, those files were removed or replaced, and we were on our way.
Next step: Installing Zendesk’s Application Tools. These are some simple Ruby-based CLI’s (don’t worry, you don’t actually have to know Ruby or much about the terminal to get up and running) that allow you to develop applications locally. This was a key reason that we updated our existing Zendesk Guide to this new beta product. The old theme model inside Zendesk’s Guide product was, well, not great. The workflows were not built for developers, but it still required a developer to do anything of note. Without going into too much detail, it was annoying.
Under this approach, I was able to take a theme, export it, version it inside Bitbucket using Git, and preview all of my changes to the theme locally without updating a single line of code in the production environment. Now we’ll be able to get off and running on updating the theme without worrying about disrupting our customers that are trying to find answers to pressing questions. On to the next step!