Search for a command to run...
How a quotable movie from the 90's drove me to build our internal support & success tooling.
I'm a developer from Vancouver, BC who's had an interesting journey in tech starting from support, through cloud infrastructure and project management. Currently I work as an SRE at lightstep helping build and "operationalize" things that helps to guide others towards better o11y :)
No comments yet. Be the first to comment.
How Terraform's setunion() disregards ordering.
How using a table during the planning step could have saved a lot of headache.
A practical guide in using Bash to solve a real-world problem with examples.
This week I've been finishing up a task that involves updating our CI/CD pipeline to make use of a feature available in the newest release of the Open Telemetry Collector to validate configuration files. In doing so, I got a chance to get up close an...
So what would you say you do here?
Is a question I routinely ask myself, because in a start-up, it’s always changing. (And also because Office Space was a fantastic and very quotable movie).
And as a Founding Customer Success Engineer - the follow-up to this question in the movie actually…kinda fits!
Well, look, I already told you.
I deal with the [fantastic] customers... so the engineers [can focus on other things].
I have people skills.
I am good at dealing with people!
Can't you understand that?
Now, while I don’t physically bring the requirements from the customers - to the engineers. The premise is still the same. My goal is to be out in the field interacting with customers to bring back anything that can help them become more successful with the product …which happens by helping us build a better product. (I wasn’t sure how to order this sentence)
If I’m not talking to customers to bring back concerns, insights, or feedback - we’re not moving forward.
At different parts of the organizational journey - the role can be much more sales-leaning, or more success-focused; but at all times, my job revolves around interactions.
In that sense, interactions with our customers (existing and prospective!) are my bread and butter, and they are my atomic unit of work. I suppose you could say they are a primitive in my system of work.
And so, when I started here a year ago, I realized one of the first things I’d need to do is start tracking these interactions —
So to build the tooling & processes to help, here are the steps I went through.
I first needed to figure out some answers:
Zoom calls - These are the majority of my interactions that happen during the Sales Evaluation phase for getting customers on-boarded
Emails - For any routine correspondence, which usually happens before and after calls, and for questions & support requests.
Slack Messages - Either 1:1 or 1:M for direct support requests, questions, or if there are any general announcements about the product.
Bugs - Things that are not going as expected.
Feature Requests - Ideas for net-new functionality that’s doesn’t exist in the product.
Enhancements - Improvements to existing functionality that would help users be more successful with the product.
Comments - General thoughts that might not have an immediate action-item.
Questions- Self-explanatory.
I split these interactions into two categories (Actionable vs Good To Know), and each of them have the following destinations & possible end-states:
| Type | Destination | End Result | |
| Bugs | Actionable | Eng(ineering), P(roduct) M(anagement) | Bug fixed |
| Enhancements | Actionable | PM, Eng | Enhancement triaged and (1) scheduled for implementation, or (2) placed on-hold / determined won’t do. |
| Feature Requests | Actionable | PM | Request is (1) assessed and (2) built or (3) tabled / cancelled. |
| Comments | Good To Know | PM | Possible FR’s or Enhancements. Could help with future strategy / unearthing potential new ideas. |
| Questions | Good To Know | Support / Success | Can help unearth things that could be optimized, better explained and is a prime source of information for docs and content-ideas. |
For each interaction type:
What would the consumer of this information want when they’re reading it?
What are the specific pieces of information?
Bugs
Details: What’s the problem? And in detail?
Severity: How bad is it? Does it stop users from using the product?
Can it be validated & reproduced? (Is this an edge-case, or is this proven to be happening)
Any supporting details that would help resolve the problem? (Anything that the engineers don’t need to hunt for)
Feature Requests (& Enhancements)
Details & reasoning: What does the customer want, and why?
Level of importance: How bad do they want this? Will this be a deal-breaker for implementation or continued usage?
How does it fit into their usage?
Comments
What do they users have to say?
Sentiment: Is the message positive, negative or netural?
Questions
What’s their question?
Has this come up before?
Could this be answered through better messaging, documentation or updates to the product?
I’ve worked in medium sized businesses, and I’ve worked in some large mega-corps - and I’ve seen the way that they handle these challenges. Usually, it’s through the use of tools like ticketing systems (like Zendesk) and project management tools (like Jira) and with all the accoutrements (like middleware to walk between them) to go with it.
But we’re not medium-sized or a mega-corp. We’re a start-up, which means scrappy, resource-efficient and moving quickly. We’re not going to buy those products (yet), and we don’t have all the time to build something very custom.
These tools will not do Donkey - Shrek, if he were faced with the same problems . probably. idk.
I think I may have been reading through Atomic Habits by James Clear at the time - because one thought at top of mind was making it easy to capture and track this information. Especially since this is something I was going to be doing a many times a day. I wanted to get the important information out of my head / conversations - quickly.
The whole point of this was to get the information into a central place so that it could be (1) organized, (2) reported and (3) actioned on.
Right information, to the right place, at the right time.
To make this work, I broke down the system & tooling into a couple of units:
This was the initial solution I came up with with three main pieces from left to right:
Portal: The interactions come “in” via me (or anyone else in the org)
To make sure it was easy to do quickly, and especially in a call - I wanted something like a quick-fill form:
Database: The interactions are stored in a central place with the relevant information - with all the required and relevant information; and then finally
Systems of Record: The interactions are routed to the appropriate places for consumption, recording or action. (An example below)
Consumption: Into Hubspot as entries into the CRM (and Slack as messages to tag me)
Recording: Into the customer “Implementation plans” that we were originally storing in Notion; and lastly
Action: Into Github Projects for PM & Engineers to create issues and build off.
I decided that my system would probably have to look something like this:
where I decided to use Retool as the database & front-end for a couple of reasons:
I was very comfortable with its use,
It provides a powerful no-code editor to get UI components up and running BUT also the ability to really dig into (and implement) your own logic / scripts using their workflows and
The ability to connect to multiple and various different resources. (This comes in handy for things like connecting to product endpoints for usage data and connecting to other API’s for supporting information - i.e. to our AI notetaker’s API for transcripts of conversations)
With all of that in mind, this is what capturing interactions looks like in YeshID today:
When anyone needs to record an interaction they head to the SupPortal (which, with the use of go-links, becomes very easy to remember with go/supportal)
Org_ID which means no hunting for information through the database)
The interaction types is a drop down split into Bug, Enhancement, Customer Request and Comment - which determines how the interaction will be actioned. (Lets look at a Bug as an example). I can then go in and fill out the details. An option I have for most interaction is “Is this a blocker” which adds a specific label onto the issues in Github projects (where we track our work)
Once the interaction is submitted, it’s fanned out into the following places
Slack - So that I have a record (which was initially my only record)
Github Issue - So that the work can be picked up by PM or Eng
and finally:
Hubspot - So that when I’m prepping for calls or whenever PM / someone else needs a recap on a customer’s journey so far, they can see all the interactions that have happened:
While knowledge is half the battle getting the information is important - at some point, it only becomes useful for the user when they know something’s been done with their feedback. I’ve improved this system so that now when Engineers close a ticket, it will automatically alert me in Slack and in Hubspot.
By using this system, I’ve noticed a couple of advantages:
The right information is collected at the right time. No more bug reports going to Eng without basic information like OrgID’s or loom links.
It’s easy to collect information and get the information to move quickly (that’s one of our few advantages against the heavy-hitters as a start-up!)
The interactions are trackable. All of the interactions are stored in a retool database which means I can have visibility and the ability to get information / insights like:
How long do tickets take to get resolved?
How many tickets are attributed to a specific customer?
Did some customers submit more interactions than others? Why? What can we learn from that?
One specific example that comes to mind - is the time we were about to enable billing and wanted to reach out to our customers. (A big milestone in any start-up’s career!). One of the tasks on our plate was to communicate the state of billing to our Lighthouse Customers (customers who partnered with us early to help gather data / provide feedback - in exchange for certain perks). We needed to let them know that (1) “hey you’re going to see some information about pricing and billing”, but (2) “don’t worry - [here’s how this information applies to you].”
We could have easily come up with some generic boiler plate messaging that could do the job but NOPE. That’s not the experience I want for my customers, and especially for those people whose efforts, time and feedback was instrumental in getting us to that very point. And so I thought about the idea of having a tailored blurb in each of those messages to act as a checkpoint to validate, and recognize their efforts.
Wouldn’t it be great if each Lighthouse customer got a little snapshot / blurb of how they helped?
Before this system, that task would have been painstaking and time-intensive. The effort required to dig through multiple places / systems and attribute the tickets would have been unfeasible on it’s own. But thanks to this system and having it all go into Hubspot (or into Github Projects with attribution) - I was able to make up blurbs like this on very short notice.
In a start-up, roles often shift, and as a Founding Customer Success Engineer, my job revolves around interacting with customers to improve our product. To streamline this process, I developed a system for tracking customer interactions using tools like Retool, Hubspot, and Github. This setup allows us to efficiently capture, organize, and act on feedback, ensuring vital information reaches the right teams promptly. The system enhances visibility, speeds up resolution times, and empowers personalized communication with key customers, proving invaluable in our fast-paced environment.