Research

ASSUMPTIONS

Prior to beginning research, we mapped out our assumptions about incident management and Customer Success Managers as the following:

• Users will want one central platform for communicating with customers & team members

• Users want to better communicate incidents to stakeholders

• CS Managers are under pressure to hit high uptime / customer success metrics

• CS Managers are looking for a simple way to find account history

• Users want to be able to defend with incident history their team in the wake of system errors

And after doing some competitive analysis we came up with the following list of potential features for Ballast Labs:

1) Internal chat matched with task assignments
2) Easily create knowledge articles & reports
3) Add resolved cases to knowledge base
4) Communicate incident resolution status with customer

PERSONA

We also built a Persona to understand the customers better：

CONTEXUAL INTERVIEWS

As a team we took turns to interview 5 Heads of Customer Success in small start-ups.

Purpose

Understand the current incident process (before, during, after) of Heads of CS, identify the tools and strategies they use to manage incidents, and assess how they communicate with engineers and other stakeholders.

Process

Incident Roadmap(the graph below)  – An interactive exercise for participants to document their process from incident discovery to post-mortem and map each step relative to their stress on an emotional scale.

RESEARCH & INTERVIEW FEEDBACKS

War Room + Communication

• No singular place for them to go to get all of the information they need

• Coordination and communication between stakeholders, ops, and engineering is difficult

• Participants often noted that there was a lack of clear task ownership

Shared Knowledge

• Users want a way classify and tag incidents to review larger account trends

• Users want to learn from past mistakes and avoid repeating them

• "When a previous Customer Success Manager leaves, account knowledge dies”

Increasing customer transparency

• Participants wanted the ability to provide more context and insight to their customers

Low-fidelity validation

We recruited 5 Customer Success Managers to test our low fidelity mockup.

Our team presented users with four tasks, framed within a mock scenario, central to Ballast’s functionality.

1. Create new incident
2. Add and assign a task to a team member
3. Update customer on status of incident
4. Close incident

We also used the participants’ time to gauge their overall impression of the platform and need for this kind of tool.

Goal of user testing: Validate lo-fi design and identify additional pain points, room for improvement, as well as potential opportunities for improving the product.

PAIN POINTS & TAKEAWAYS

1. Room setup

Problem: Confusing adding customers / team members / tasks in different places.

Recommendation: Add customers, members and tasks through one task bar.

2. Integrations

Problem: Need the ability to pull data in from Zendesk, and push data and reports to relevant external platforms (i.e. Github, Salesforce).

Recommendation: Provide base-level integration (Zendesk) for MVP. Give the option for other integrations that aren’t central to the core functionality later.

3. Resolving incident / closing room

Problem: Not intuitive. Would like flexibility in where the data is saved and where it goes.

Recommendation: 

• MVP: Push an incident summary to Slack and (optional) email.

• Paid option: Save/ Archive the data, view all incidents on an Incident Overview page.

4. Customer Communication

Problem: Status page is insufficient and/ or not flexible enough for incident remediation.

Options:

a. 3rd party integrations for global and/ or direct customer communication.

b. Status page - see lo-fi, with usability improvements.

c. Static text, copied and pasted into emails.

d. No external communication.

High-fidelity mockups