General Customer Success Tips
I am, reluctantly, a Customer Success (CS) Agent. I should be a T3 Support Manager or Solutions Engineer, but my career has not gone according to plan. That said, I do love talking to customers—albeit I’d prefer to do it in my more technical and nerdy way. Instead, I find myself doing it like an ESL teacher, where I have to pretend that everything a client does is impressive. "Great work setting up an email template!"
After teaching African migrants CS principles and running various role-play demos, I wanted to share some key insights that I cannot believe people miss. These things seem like no-brainers. Keep in mind, CS is very different from Sales, which is different from R&D. Sales communicates like someone who just did lines of cocaine and won’t give up on asking a girl out. R&D often communicates like they’re autistic (I get to say that because I… was in R&D).
CS is not just about selling existing clients on new features we’ve developed or listening to endless feature requests. It’s also about selling the customer’s use case back to our own company, ensuring that development priorities align with real user needs. CS sits at the intersection of all relationships within a company, acting as teachers, PR, marketing, and so much more.
1. Immediacy
If you need to schedule something, never take more than one minute to create the calendar event. Include a Zoom or Google Meet link, and be sure to invite all relevant users. Make this a habit, like using your indicators if you're a good driver (aka not a BMW driver).
A lot of people go by the 30-second rule. I have a rule in life: if it’s easier to do something than to ask someone else to do it, just do it. There are a few exceptions, but generally, I’d rather do a roommate’s or girlfriend’s dishes than waste time asking them to. It’s really not a big deal.
Personally, I like to add detailed descriptions to calendar events, but I’ve found that most people don’t read them. And even if you make a plan, the customer or manager is likely to do their own thing anyway.
2. Take Ownership
Ideally, every company would have an ISO-9001-type guide that defines who is responsible for what. But companies don’t operate on ideals—they operate on laziness (see my article “Motivations of Lazy”: https://kingchill.com/guyspace/lazy ). Unless you’re in R&D and can see the Git Blame, you need to develop an intrinsic understanding of who is responsible for what.
But ultimately, none of that matters because you are responsible. Even if a PM is making dev decisions, you need to convince them that your issue is a strategic priority. You need to help with documentation, flowcharts, and assisting R&D or QA in identifying missed use cases that led to bugs. It’s not in your job description, but it’s what separates you from others.
It is incredibly tough to work under someone you think is incapable of doing your job. People respect their managers only if they know their managers are capable of doing their work—and they respect them even more if their managers can do it better.
Learn to read logs. This is what separates a technical and non-technical person. If you’re not experienced with logs, early in the job, ask someone who is to create a short document with links to logs and examples of commands they use. You can write down the keywords without fully understanding them and still look like a genius.
3. Fake It…
Even if you don’t like someone, suck it up and pretend you do. You need to stay on everyone’s good side. At the very least, learn how to phrase things diplomatically—kind of like how Southerners say "Bless his heart" when they mean someone is dumb, or how Tech Support uses PEBKAC (Problem Exists Between Keyboard And Chair).
Customer Success isn’t just about managing customers—it’s about managing relationships, internally and externally. The better you navigate those, the easier your job becomes.
