The Keys to A Successful Customer Relationship

Back in early March I had the pleasure of joining Qotient, Inc as their Director of Customer Success for North America and Europe.  The CEO of Qotient, Justin Wright, brought me on because he saw how important the role of Customer Success was in his vision for Qotient.

 

Qotient was created to help revolutionize the sales process, but one of the biggest factors in even getting it off the ground was ensuring that we were building strong relationships with our customers. With that in mind, we put together a list of the five keys to building the right type of relationship with our SAAS customers, during all stages of their journey with Qotient.

 

  1. Get to know your customer LONG before the sale has been closed.

Being involved in the pre-sales process is critical to a successful sale and the long-term success of your customer. Salespeople spend a ton of time nurturing an account prior to a sale, and when a prospective customer sees the Customer Success Team taking the same care and attention it signals to them that they are important, and that their business is going to be in good hands after they sign.

At Qotient, our Customer  Success team is responsible for putting together a project plan prior to the sale close in addition to our normal introductions, which has helped the establish and maintain the trust once the sale is closed.

 

2. Identify your internal champions early, and often.

No one stays in the same job for long these days, and the person who was once your champion might end up moving to a department who has absolutely no need for your product anymore. That’s why it is key to make sure that your list is updated regularly.

At Qotient we spend a lot of time on the phone with different companies, and any time someone new is introduced CS evaluates whether or not they are someone that we might be able to consider as a champion for us.

 

3. Establish not just what you consider to be success, but what your customer considers to be success.

Your customer got excited about purchasing your product for a reason, and in all likelihood they have told themselves a story about how your product is going to change their lives. Knowing what that story is and the outcomes they expect is going to be the best tool in your arsenal when rolling out a new product, and in establishing long-term goals.

At Qotient we spend time during our initial rollout chatting with executive stakeholders as well as the day-to-day users of the product to ensure we  understand their needs and wants from a relationship with us, and let them know upfront just how we can help them meet their goals.

 

4. Measure everything.

Once you know what your customer and you consider to be success, and you’ve agreed on that criteria, then the next step is to ensure that the data you look at is relevant to that goal, right?

Of course. But what about the other data that has nothing to do with that goal? How can it possibly help?

After taking on the Customer Success team at Qotient, one of the first things that I made sure we put in place was Google Analytics, so we could start to track not just logins or when a user created a meeting, but also small things like how long a user spent looking at a page. Our customers now receive information regarding both mindshare and user loyalty, which can be extremely hard to capture accurately, in addition to reporting around basic metrics like sales numbers.

 

5. Ask questions, take feedback, and be willing to change.

Owning the customer account means owning the customer experience. A customer success manager has to be willing to be the face for their product– this means every little bug and every failed login are going to make your customer think of you, but it also means every win they have you’ll be able to share in as well.

At Qotient we try to take feedback on what isn’t working and highlight what is in equal measure, then share it with the whole Qotient team. Hearing from someone about how excited they are to use a particular feature makes our day, but we also take time to listen to when our users run into difficulties. The data, customer quotes and victories are what drive us forward, and we take what we learned and feed it back to our product team to help improve the experience for every Qotient customer.

“But You Don’t Code”

“But You Don’t Code”

 

Not long ago I was sharing my work history and how I’d progressed to a Site Reliability Engineering position. I suggested that it might offer hope to other women in the company that it was actually possible to start in one position, develop skills, take risks and move up. Shockingly I was met with the almost accusatory response of, “But you don’t code.”

It took me aback, enough so that I sheepishly agreed and dropped my part of the conversation. In that moment I was sure that they were right about my talents and abilities. I had done so much with my career,and regularly received accolades for my work, but I wasn’t building applications for our site or customers… so this person assumed I didn’t have value to offer as a technical employee. The real irony in the situation is that the person that I was talking to worked on the corporate side of the house, far removed from any understanding of my job or job duties.

This led to the realization that sometimes we place so much value on the “coding” persona in the industry that we often forget the plethora of other positions which both support and stabilize the work that coders do. It has to be acknowledged that technology companies rely on more than just coders to get a job done, and in some cases sitting and coding for 10 hours a day isn’t the only way to actually get that technical work accomplished. Moreover, it isn’t the only position we should be pushing women in technology towards.

Working for a large internet company means that I have plenty of opportunities to interact with and encourage women I meet to take on technical positions, especially when I see latent talent just waiting to be nurtured. If I told the majority of them that the only way they could truly be taken seriously was to learn to code there’s a good chance that most of them would stop right there. Yes, coding is a necessary part of my day to day job, but it isn’t the only thing I do, and it isn’t what a ton of other women who are also very knowledgeable and much smarter than me do either.

In my day to day work I’ve fought for major product changes and bug fixes, and dug deep into website back-ends to fix customer scripting problems in HTML, PHP, and .Net. Now, as a server administrator I do significantly less code work than our developers but the work I do is certainly classified as technical. There are a myriad of roles within the industry that have nothing to do with coding– data center technicians and technical support positions come to mind. But even in those roles there is a fairly good chance that you do more coding than you think, and I came to realize this as I was busy writing up bash one-liners during my work day… which qualifies at the very least as programming.

I’ve spent years learning the intricacies of server administration, but I’ve also listened to people tell me “you don’t code” as a proxy for “you’re not technical / good enough” and I’ve used that definition to construct an idea of what a “Woman in Technology” looks like. It’s even prevented me from going out for more difficult roles in the past. Continuing to operate under that definition wasn’t really getting me anywhere other than more frustrated.

How ridiculously unfair I was being to myself! This is a job I do not just daily, but take pride in doing well! The comment was from a person that couldn’t do the most trivial of my tasks and still I let that doubting voice creep in. There is more to technology than coding, and I can be a woman in technology just starting out in Python and NodeJS, but also rocking it daily keeping up the services and servers that run the internet.

By allowing myself to question the value of my abilities based on someone else’s understanding of what it means to be a “Woman in technology” with the words “But you don’t code,” I let the work I do daily be dismissed. By continuing to agree with that definition I also make it harder for women coming up behind me.

The internet is a massive market full of work that can be as complicated or easy as anyone likes and they can still consider themselves to be a part of the ever-growing experience. I only get to dabble with GitHub in my off hours, but I am technical. With time and effort I know I will get better at coding and will understand more– ultimately I hope to be creating projects that people choose to fork.

There is not some massive race to the finish line or some badge for everyone to earn. If we don’t take the time to learn it in our own style there is no way we’ll enjoy it.

 

Beginnings

It’s funny how when I am driving home from work, shopping at the grocery store, or even eating dinner out I can have sudden bursts of inspiration and creativity regarding this blog, but when I finally get the chance to sit in front my my computer the words evaporate. It’s so easy to sink into my couch, kick my feet up on the coffee table, and turn to Netflix– especially when Bill is out of town and it’s been a long day.

And I have more than enough to keep me busy once I get home– there’s Comicon volunteer work, Comicon costume work, and online classes to complete. When did life become so busy?

Either way, I’m looking forward to starting to document it here.