I’m currently a first year Masters student in Human Computer Interaction & Human Factors at Rice University and have over five years of experience working with users at early-stage startups.
With a background in putting the customer first with quantitative and qualitative data, I aim to improve and create experiences that are designed to solve real people’s problems and delight them along the way.
- I’m a listener and am a firm believer in seeking first to understand through active listening.
- I’m curious and love learning, about people, their interests, how they work, and what gives them the “aha!” moment they’re looking for.
- I default to solving problems and finding creative ways to get there.
- I believe collaboration and communication with others are the keys to success.
- Revamping the Station Houston Mentor Program
- We love Percy comments! But we never use them.
- How do I cancel my Percy account?
Case Study #1: Revamping the Station Houston Mentor Program
Station Houston was an innovation hub in Houston, TX designed to offer services and support to technology entrepreneurs and creatives in the Houston area. Station Houston members were unsatisfied with the quality of the Mentor Program, and wanted improvements to the program in order for them to get value out of it.
As the Membership Programs Manager, it was my job to first understand why members were dissatisfied with the Mentor Program, and then use the resources at my disposal to make the appropriate changes to the program.
1:1 interviews with members
A core part of my team’s function was to have 1:1 meetings with Station Houston members to understand their needs and connect them with resources in the community. As part of the mentor revamp, we used these 1:1 meetings to ask targeted questions that covered the following question:
In an ideal world, what would you like to see from the Mentor Program at Station Houston?
We asked 10 members this question in 1:1 interviews, and some of the responses are below:
“Just knowing which mentors are involved in the program would be great to know”
“I wish I could meet with mentors who are experienced with the stage of startup that I’m at”
“I’d benefit from longer engagements with each mentor, versus one-time meetings that aren’t that impactful”
Google Form Survey
We used the responses from the 1:1 interviews to design a Google Form to receive more quantitative and qualitative feedback.
This survey was emailed to a member base of ~250 individuals. Approximately 45 replied and identified three primary improvement areas for mentoring:
- Better tools for booking with mentors
- Easier ways to discover the best mentor
- Remote mentoring services
From these responses, we realized that our biggest constraint was that we did not have an accurate internal database of Station Houston mentors, nor did we have a systemic way of keeping it up to date. Before we would be able to implement #1 above, much less #2 and #3, we would need to first build out the internal Station Houston mentor database, and implement mechanisms for keeping it up to date.
Case Study #2: We love Percy comments! But we never use them.
Percy, a visual testing tool for software engineers, had recently launched a feature allowing users to write comments directly onto the build view in order to increase collaboration with team members. Adoption of this feature was low, and we sought out to better understand why.
As the Customer Success Manager at Percy, it was my job to understand if and how our customers were achieving their desired outcome with our product, and to encourage continued use and expansion within our enterprise clients.
1:1 interviews with users
A core part of my function at Percy was to schedule Quarterly Business Reviews (QBRs) with our Enterprise Customers on an ongoing basis. The purpose of these check-ins was to:
- Discuss customer usage metrics and plan-usage fit
- Review our recent product updates since we last spoke
- Give a preview of our upcoming product roadmap
- Ask for customer feedback or thoughts on our recent changes, and their input for what they’d like to see on our roadmap
Over the course of 5 different QBRS with groups of Enterprise Customers (attended by both super users and financial stakeholders) we asked them the following question:
What do you think about the new “comments” feature? How have you been using it?
Responses to this question included the following:
“We’ll usually write any changes to be made in GitHub because we don’t want to lose the conversation history”
“Yeah we’ll use it sometimes.. I guess we don’t use it as much because we want there to be a record of the changes and comments in GitHub”
“Is there a way to link to the comments made?” [when asked why] “it’d be really helpful to take the URL to the comment and log it in GitHub”
Customer Satisfaction Survey (CSAT)
While we did not send out a CSAT survey specific to the comments feature, we have received a couple of CSAT scores over the past few months that are related to the comments feature:
“Sometimes it’d be useful to have a permalink to a given comment on a diff”
“I don’t use the comment feature much because we’re very used to getting links to comments in GitHub discussions”
Now that we have passed this information onto our designer and team of developers, they are working on mockups to revamp the comments feature and user test with our customers along the way. To help with this, we’ve asked customers from the QBRs if they’d be willing to receive a follow-up for feedback as our team works on this, and they have all enthusiastically agreed.
Case Study #3: How do I Cancel my Percy Account?
When Percy self-serve customers (i.e. not Enterprise customers) wanted to cancel their Percy subscription, they would have to reach out to Support to cancel. This was a problem because:
1) It would be difficult for them to find out how to cancel, and there was no clear direction on the website that would tell them where to go. This could result in frustration with the process, and leave customers ending their use of Percy on a negative note.
2) We would lose out on an opportunity to collect feedback from customers who were churning.
When customers would cancel via Support, they would or would not provide candid feedback to our Developer Support Reps. This feedback was optional, and there were no actionable steps we could take after a cancelation.
As the new Customer Success Manager, one of the key metrics I was focused on evaluating and then reducing was customer churn. I realized that without a feedback loop around customer cancelation flow, it would be impossible to identify why customers were leaving. I decided to evaluate the current process, propose a new workflow, and build this cancelation flow with our team of engineers.
Step 1 was to first map out the current cancelation workflow:
- Customer decides they want to cancel
- Customer goes to billing page
- Doesn’t see cancelation option, goes to “contact us”
- Types in “cancellation” → doesn’t see any docs → contacts support
- Directly contacts support → “I’d like to cancel”
- Developer Support Reps respond with, “I can help with that! This is usually a great chance to collect feedback about Percy and what we can do to get better. Is there anything in particular that is making you want to cancel? Any kind of feedback would be helpful 🙂 I’ll take care of the subscription now.”
- They may or may not provide us with feedback
Step 2 was to come up with a rudimentary proposed cancel flow. This process was designed based off of the current volume of cancelations we were receiving, and some research into how other B2B SaaS companies handle their cancelation flows:
Proposed Paid Plan Cancellation:
- This could lead them to a product document on docs.percy.io that talks about how to cancel, explains the billing period, and links to a Typeform allowing them to cancel.
- Could also lead customer to contact support first.
- Developer Support Reps should have access to the same form in case customers reach out to them directly.
- Team Percy gets notified via new Slack #churn channel with Typeform contents after each submission.
The cancel flow would also require that the user fill out a form. The design of the form was built by filtering through tagged support conversations, and evaluating responses when customers had given feedback as to why they were canceling. After reviewing over 30 responses, I came up with the following form design:
- Org Name (captured via Typeform hidden fields)
- Email Address (captured via Typeform hidden fields)
- What was your initial goal for signing up with Percy?
- Did the product meet your expectations?
- What is your main reason for your downgrading your Percy subscription?
- No longer need it
- It didn’t meet my needs
- Found a better alternative
- Found a cheaper alternative
- Quality was less than expected
- Ease of use was less than expected
- Access to the service was less than expected
- Shutting down or downsizing my organization
- If Other, please elaborate:
- Any additional feedback or improvements we can make for Percy?
After creating the rudimentary cancel flow and form draft, I set up meetings with our Developer Support Reps who were the primary team members handling customer cancelations, as well as our COO who would be able to speak to any financial impacts this project would have. After a series of meetings, we settled on the following flow:
The engineering requirements were minimal, and we were able to get the project implemented within 3 weeks. Churn is now accurately measured, tagged, and reported on in monthly meetings. The team is able to proactively follow-up with customers who churn, and stay in touch with customers who who requested features that we were able to deliver on later. This project also provided the team with a bird’s eye view on churn trends and how that may influence the product roadmap.