Curse & Fandom Service Wiki [Case Study]
I joined one of gaming’s fastest-growing startups, Curse, in 2016, as their first Environments Manager after a four month gap in the role. During this gap, the internal Environments service system had all but vanished. Most internal processes were manually managed and consumed far more resources than they should have.
It was time to build something that would elevate our internal support process from a “scrappy startup” solution into a full-bodied support network employees could rely on every single day.
Elements of my work have been omitted from this case study to comply with my non-disclosure agreement. All information contained within this case study is my own and does not necessarily reflect the views of Curse, Twitch, or Fandom.
The Problem
From Table Talk to Case Study
My first year at Curse focused primarily on rebuilding our environment support network. This included on-boarding new vendors for snack/drink management, catering partners, etc. Once I established a framework for automating our day-to-day processes, I knew it was time to start work on a system for internal service and support.
During lunch one day, a conversation evolved regarding office services with a handful of employees. I used this opportunity to take a pulse-check on how employees felt about our internal support process.
During the conversation, I received a wellspring of advice, suggestions, and feedback regarding the way things were done in the past and how we thought things could be improved. As I wrote down dozens of suggestions and ideas, I noticed that almost every passerby also stopped to offer their thoughts. Through this, I understood that many of my teammates were eager and excited to help us evolve, and thus, my research began.
My top-level research goals were to:
- Discover what employees valued most about our internal support team and processes
- Discover what types of requests individuals submitted and how we could best manage the ingest of these requests
- Discover what support staff members needed from a global support system
Users
Curse had anywhere between 60–80 employees during the period of research and development of the service wiki. This did not include the 1000+ employees who then worked for our parent company, Twitch Interactive. Twitch was a subsidiary of Amazon Inc., so there were hundreds of possible users for this service tool.
The service wiki and ticketing system would be designed for use within the Curse organization, but would be viewable and useable by Twitch and Amazon staff.
During the course of the project, Curse would be acquired from their previous parent company, Twitch Interactive, by Fandom (formerly Wikia Inc.) This would widen the scope of which offices would directly benefit from the service wiki to a total of ~350 employees globaly.
There were three distinct groups of users who would interact with the service wiki:
- General Staff — Developers, Managers, Product, Marketing, etc.
- Executive Team — The CEO, President, & VPs
- Support Team — Environments Managers, HR, & IT
My Role
When I started the project in Q4 2017, I was the only person involved. I conducted my research throughout Q4 2017 — Q2 of 2018 and launched the first iteration of the wiki at the end of Q2 2018. However, the wiki was designed to evolve over time. I would complete dozens upon dozens of edits, refinements, and revisions over the first several months of the wiki’s launch.
I then worked closely with our HR and IT teams through 2019 to implement the Jira Service Desk into our team workflow. The final wiki + service desk ticketing system was soft-launched in May 2019 and fully integrated into our support team workflows by July 2019.
Research
Looking Back to Find the Patterns
In order to build a system that would be useful, I needed to understand who would interact with this system and what types of solutions would be important to them.
I first conducted an audit of requests submitted via email, Slack, and in-person across the past six months. This gave me a wellspring of quantitive data about the types of requests individuals were submitting and what the expected turn around time for these requests was. I discovered that requests typically fell into one of three categories:
These three categories provided the framework I needed for the next stage of research, face-to-face interviews.
Building the Path Forward
I conducted over a dozen face-to-face interviews with employees from our three primary user groups:
- General Staff — Developers, Managers, Product, Marketing
- Executive Team —President & VPs
- Support Team — Environments Managers, HR, & IT
Many of the individuals who were willing to share their thoughts were eager to discuss their ideas and expectations for what a support tool might look like. Each of the three user groups provided a unique and valuable perspective on what this support tool would need.
I conducted interviews in a casual and relaxed setting, opting to talk to participants over coffee or on our game room couches. This allowed participants to relax and share how they truly felt about our internal support tools.
These discussions covered topics from current service strengths, past frustrations, great service experiences outside of Curse, and reflections on what makes coming to work at Curse fun and enjoyable.
Discoveries
The Hidden Stress of Seeking Help
My first major discovery was apparent from the very first interview all the way to the last:
Asking for help can be an emotionally stressful experience.
I discovered that most employees loved the personal care and attention I gave to every request. However, this caused me to become a bottleneck for incoming requests.
Many individuals don’t want to admit they are stuck or lost, and many more would prefer to solve their own problems rather than rely on a support person.
Although I wanted to provide a white-glove experience for employees seeking help, I was inadvertently creating an environment where non-critical requests/feedback were being discarded by the staff.
We first needed to provide a way for employees to self-service their common questions and problems.
My Way or the Highway
If an issue or request were critical, time-sensitive, or too complex for a self-service tool, then a formal request would need to be submitted. The obvious choice to manage something like this would be an issue tracking ticketing system, which both executives and support staff wanted. However, this would add an additional layer of complexity to an already stressful workflow.
How could we integrate an issue tracking system without adding unnecessary complexity or stress to our daily workflow?
The answer was really quite simple. The support team could use the issue tracking tool as a task manager, collaboration, and prioritization tool while the staff could continue to submit requests in a way they felt most comfortable.
Through the task submission audit, I discovered that most issues were submitted via one of three channels:
Fortunately, each of these platforms offered easy forwarding and conversion into most ticketing software, so we could quickly convert the request into an issue ticket.
The aforementioned bottlenecking issue also affected the ability of staff to check the status or progress of their request. This created a frustrating experience similar to checking on your place in line while waiting at a restaurant.
We needed to deploy a ticket tracking system to allow support staff members to easily track and prioritize daily requests while also providing users fast insight into the status of a pending requests.
Showing Your Work
The third major discovery involved the role of Environments Manager itself. Executive team members wanted a way to track the day to day work of Environments Managers to understand where operational improvements could be made. Environments support staff wanted a way to quantify their work for the purposes of performance reviews and merit increases.
Curse had never had any hard KPIs (Key Performance Indicators) assigned to the Environments Manager role. The role’s performance was evaluated mainly by general staff satisfaction and overall budget spend. This created some situations were the Environments team felt like their individual wins were muffled while their misses were magnified. This could sometimes create friction between key stakeholders and the Global Environments Management team.
Something had to change.
We needed a solution that could provide hard data regarding our priorities, workload, and overall quality of work. This was a simple problem to address, however, as most issue ticketing systems track these exact metrics.
We needed our issue ticketing system to include key metrics such as the number of tickets closed, time to the first contact, and an average turn around time.
These important metrics would also provide important KPIs that would be integrated into our annual performance reviews.
Building
Building the Wiki
Our discoveries told us that we needed two things:
- A fluid and easily updated knowledge base tool
- An issue ticketing system to track tasks and requests
A majority of our developers were already using Jira Cloud to manage their day-to-day development projects, so working within the Atlassian ecosystem would be a cost-effective and familiar tool for the team. I wanted to make sure that whatever system we built would be:
- Low friction for both general staff and support team members
- Easy to adjust and edit as the service tool evolved
- Flexible enough to integrate into the support team’s existing workflows
The tools of choice were clear. We would build a support wiki in Confluence and an issue ticketing system in Jira Service Desk.
Launching the Wiki
Once a tool was chosen, it took only two days to build the first version of the Curse Service Wiki inside Confluence.
I started with a low-fidelity wireframe to serve as a quick guideline for what to build, but the entire process came very naturally to me. I had compiled a list of frequently asked questions and requests from the earlier audit, so populating the wiki was a simple matter of listing the most requested and important information first. I also pulled from my extensive experience with the structure of support pages and help tools from my five years of work as a trainer at Apple Inc.
Elements included in the 1.0 version of the Curse Service Wiki included:
- An intro block to provide visitors from Twitch, and later Fandom, the context for what Curse did and provide basic information about Huntsville, AL for out of town visitors.
This feature was specifically requested by the executive team during the research phase. They had wanted something like this for a long time but never had a good place to host and distribute this simple information. - A quick link sidebar to the most common request forms and external links. These included creating IT tickets, shipping packages, accessing updated branding assets, and viewing the updated company seating chart.
- An events widget to provide a quick list of upcoming company events and links to each event’s signup form.
I soft-launched the 1.0 version of the wiki and sent a link to the research participants so they could experiment with the new page and share initial impressions.
Every single research participant loved the service wiki.
I knew we had a good starting point that would easily scale as the service wiki evolved. We could also quickly spin up new wiki pages using this format for other offices around the globe.
From Twitch to Fandom
Several months after the deployment of the Curse Service Wiki, it was announced that we were to be acquired by Wikia Inc., also known as Fandom. Part of this acquisition would include a complete rebranding from Curse to a new unified brand image under Fandom.
This caused a minor delay in implementing Jira Service Desk due to a number of integration tasks taking priority. However, I took this time to visually refresh the wiki to reflect our new Fandom branding and spearhead our integration efforts with Fandom’s Global Environments Team.
The executive team also asked for the intro block to include a new section detailing our integration philosophies as a reminder for everyone visiting the wiki front page.
Our new Global Environments Manager at Fandom was excited to see the work I had already put into deploying Confluence and Jira Service Desk. He authorized the continuation of this project so that Fandom’s Global Environments Team could start using this system as soon as possible.
Building the Service Desk
With the wiki fully deployed and integration efforts underway, it was time to build the issue ticketing system into our new Fandom Service Wiki.
I converted our existing Google Forms into ticket templates that would allow us to capture necessary information for ticket requests without frequent back-and-forth contact for clarification. I was also chosen to lead a training session with our Global Environments Team to teach my peers how to use Jira Service Desk.
We then integrated Jira into our company Slack, an internal chat application, to allow simple ticket creation without switching to another app. This change resulted in a surprising shift in behavior.
Because Slack displays a message and link when a ticket is created inside the app, we noticed that fewer requests started coming in via Slack. Upon reviewing our service desk analytics, we noticed that the number of tickets submitted directly from the wiki had increased.
Our users were changing their behavior to look for an answer first, then submit a ticket without any interaction with a support team member.
This behavioral change resulted in fewer disruptions for support team members increasing their ability to focus on larger projects and improvements.
Impact
The fully functional Fandom Service Wiki and Support Center launched in Q3 2019. Within the first few days, employees were using these new tools to self-service their issues and submit requests through our new Service Center Knowledge Base. We would continue to add new support pages to the wiki as new policies, tools, and programs emerged.
Within the first two months of deployment, we closed 300+ tickets and created dozens of edits throughout the support center. We also established new KPIs that would be used for the Environments Support Team’s annual review process.
Achieving our Research Goals
I hope you have enjoyed reading this case study.
Thank you for your time! 💜
