Fog Creek

How Our Support Team Shares Knowledge Using FogBugz

Support or Customer Service, at Fog Creek is different. The team is empowered to help our customers and do whatever it takes to solve a problem. We take great pride in the customer service we make available to our customers and often write about it – from seven steps to remarkable customer service, using it as a competitive advantage, dealing with angry people, to our 5-part series about how we do customer service, and how Trello (a product we created and spun off into its own company) use FogBugz to support 4 million members with just one person.

Something we haven’t written much about is how the support team share knowledge among its members. The nature of Support is fast-paced. There is always a constant flow of knowledge – from archival knowledge to the streaming updates of issues and features.

Staying abreast of this information is difficult, but our Support team stays on top of it all with FogBugz, and it’s search, wikis & cases, auto-subscriptions, shared filters, and subcases. We’ve broken down how we use each of these features to help share knowledge here at Fog Creek.

Write Down Your Internal Processes

The team uses Wikis for longer lived documentation. As a Support team member, you know to look in the “Customer Service” wiki before interrupting someone else. This wiki contains archival information for newer hires (FogBugz has nearly 14 years of history) and documentation of internal processes, among other gems. The great thing about the information in the wiki is that it is searchable. There’s also a clear outline and hierarchy to help organize the content and assist someone trying to find a piece of information. For example, if a new Support member was looking for general information to get started, they can see the table of contents and click the “General Customer Service” link.

wiki_main

If a few terms in the article are known, run a search. For example, here a Support member is looking for an article about To-Do items not completing:

wiki_search2

Document Your Thoughts

In addition to the Wiki, the Support team leaves artifacts for fellow team members in cases. They know that someone will leverage the power of search to help them with future cases. When working on a case from a customer, they write out their hypotheses or thoughts on how to approach the problem in the case comments. They make sure to include error messages too. If the case changes hands because a team member is out of the office, the information for troubleshooting it is already in the case, saving the new team member from starting over.

case_hypotheses

In the Support world, log messages are gold. We include them in case comments to improve searchability. Searching helps them develop additional hypotheses or determine ones to avoid. Perhaps another Support member looking at the case above would say “Why wouldn’t we check the Chrome console logs first for any errors?” and add that to their troubleshooting steps.

For the occasional “FYI” situation, the Support team uses the “Notify More Users” field on a case to explicitly let a team member know of new information. This organically grows knowledge throughout the team. Here we have Mary editing an inbox case and notifying Erin:

case_notify

Stay Updated Automatically with Auto-subscriptions

The auto-subscribe feature is used by the support team to keep up with key Project Areas in FogBugz as well as cases they create.

These key areas being “Known Issues” and “Fix It Twice”. The “Known Issues” area contains cases that quickly document a recently uncovered issue with our production (i.e. live) On Demand service and the communication needed both internally and externally. This could be an unfortunate service interruption, a regression bug or a new feature not working as expected. These issues can be reported either internally or externally. Here, we have an issue reported externally that Mary is creating a known issue case about (you can also do this for “Fix It Twice”) cases:

case_knownissue

Once the case above is created, Mary will be subscribed to the case so that she can see when Jamie adds the related subcases. Jamie has the same auto-subscription preferences, so he’ll be able to automatically see updates on the case that Mary makes. This is visible under the “Subscribed To This Case” field on the left-hand side of a case if you have this feature enabled.

list_subscribers

Essentially, any time a case is updated or created by someone, the rest of the Support team instantly knows about it. They can use this information to react to any cases they are currently handling.

Bonus tip: You can auto-subscribe to Wikis too!

Don’t Repeat Yourself with Shared Filters

To further take advantage of FogBugz’s search capability, the Support team uses three primary shared filters: one for customer cases due today, one for the “Known Issues” area, and one for the “Fix It Twice” area. This is in addition to their own personal filters for cases assigned to them.

sharedfilters

The filter “Support: Next Due”, is very important because of our promise to our customers: We answer all email within one business day. It shows all cases due today. Having these two filters available to every team member without any extra effort (read: creating their own identical filters), saves everyone time so they can focus on their work. New team members briefly look at the list of cases that are due today (and not assigned to them), and subscribe to anything that is new that they might learn something from. They don’t subscribe to everything because that is quite simply just too much information, but cherry-picking some cases to “eavesdrop” helps fill knowledge gaps quickly. The added bonus with eavesdropping on cases is that a new team member will see the culture and tone of the company and use that in his or her own cases.

Keep Things Organized with Subcases

“Who is currently affected by that new Known Issue?” is a question the Support team will ask for every new Known Issue that they get a notification on. The answer is in the subcases. When a case is added to the “Known Issues” area, this case becomes the parent case, and any and all customer cases become subcases. The Support team uses this hierarchical relationship to get a top-level view of who is affected and needs communication about the issue. See “Subcases” on the left-hand side of a case, or click “Case Outline” if there are several.

FogBugz’s search feature is tremendously powerful. The support team uses the available search axes to narrow down cases and/or wikis that contain relevant information. Has a similar issue happened before? How did someone else approach solving the problem? Didn’t someone already report this problem? Among the countless other questions. For example, a full-text search for “todo item not completing” can be run to see what wikis and cases show up:

todoitemnotcompleting

The key search axes for the Support team to sift through full-text results are:

  • orderby:lastedited
  • edited:”today”
  • edited:”-1w..now”
  • type:case
  • type:wiki

The key takeaway here is that the information exists in cases and wikis because someone took the time to write it down. Don’t worry, the first time you write something down, it doesn’t have to be perfect. You can always go back and edit what you wrote.

Creating an auto-subscription, a shared filter, and writing things down in wikis and cases will put you well on your way to getting the most out of sharing information with your team. The powerful search facility provides one way of accessing the increasingly valuable knowledge base growing inside of your FogBugz.