Programming & IT Tricks . Theme images by MichaelJay. Powered by Blogger.

Copyright

Facebook

Post Top Ad

Search This Blog

Post Top Ad

Responsive Ads Here

Archive

Post Top Ad

Contact


Editors Picks

Follow us

Post Top Ad

Fashion

Music

News

Sports

Food

Technology

Featured

Videos

Fashion

Technology

Fashion

Label

Translate

About

Translate

Sponsor

test

Weekly

Comments

Recent

Connect With us

Over 600,000+ Readers Get fresh content from FastBlog

About

Monday, January 29, 2018

Great technology. Shit service. That’s our reputation.


In one of my earliest roles at a B2B startup, there were so many fires in a day, that if no “emergencies” occurred for even a couple of hours, I sensed something was wrong immediately. It got to the point where I knew hundreds of clients by name because of how frequently I needed to do damage control.
Meanwhile, new products, new features, new services, were continuously released as we aimed to stay on the ‘cutting edge’ of technology. With limited resources and a mission to stay innovative, low impact bugs and minority clients were deemed low priority. I watched clients cancel and support staff burn out.
Internally, the “importance of customer service excellence” was reiterated time and time again through every possible means — email, chat, message boards, meetings, handbooks, training workshops, etc. Pull aside any employee at random and they could mindlessly regurgitate that it was one of the company core values. In reality, we missed the mark by a long shot.
“Great technology. Shit service. That’s our reputation.”
Related image
if this got a chuckle out of you, then you probably know what I’m talking about

Where was the disconnect? The answer isn’t black and white, but I saw two areas contributing the most to this issue.
  1. Not all clients were treated equal. With the mentality of move fast and break things, beta users or clients who contributed to advancing the product/software were implicitly given priority. This is not necessarily a bad thing if there was load balancing to ensure sufficient support for the majority of the client base — paying customers with expectations.
  2. Innovation was prioritized over maintenance. Yes, complacency is dangerous and it is important to grow, to scale. But at what expense? With stretched resources, it can be easy to neglect seemingly ‘low impact’ bugs and glitches. The result? A team of support staff unequipped to provide long-term solutions to recurring issues for clients that reach out again, and again, and again.

Let’s break this down.

When a startup makes the transition from early stage (looking for market validation), into a growth stage, there is no longer the luxury of only dealing with ‘Innovators’ and ‘Early Adopters.’
This. Is. Not. A. Bad. Thing.
Great technology that is lucky enough to have reached ‘product market fit’ serves a need, fills a gap, or solves a problem. Here’s the thing. Clients onboarding at this point — the ‘Early Majority’ — have an inherent expectation that they can reliably use the product. There is a lower tolerance for inconsistency, errors, glitches.
Most, if not all, are not willing guinea pigs supporting your grander, ultimate vision. They do not care about that. They did not sign up for that. They want the tool they paid for to work. They want it to work, the way it’s designed to, when it’s supposed to, so they can go about their day running their own businesses.
Related image

What am I saying?

The crux of it is this. There comes a point when innovation can wait. The point where the difference between success and failure is execution. Not the idea. Not intelligence. Consistent execution.
I get the sense that many startups thrive on the concept of organized chaos and inherently reject structure. Perhaps it’s a cultural thing. Perhaps some startups remain functional on this model. However, organized chaos is still chaos. And I, for one, can not imagine operational efficiency being optimal on a model of chaos.
There comes a time for structure, which does not have to equal rigidity. But it needs to create stability. While this will mean something different for every company, there are some general things. I’m talking about standard operating procedures. Enforcing internal processes (e.g. clients are not QA, production environments are not meant for testing… test the code!). And please, documentation can no longer be optional.
Stability is just as important as scalability. Hate to say it, but scaling on an unstable foundation is stupidity. Especially when hubris allows a company to believe they can get away with it.
The company I referred to at the start of the article was a SaaS startup utilizing a subscription model. While it was vital to retain all our customers, the cost of switching platforms was often too high and there weren’t comparable programs on the market. As a result, the team calibrated to the errors and took our clients’ tolerance for granted.
There is nothing more detrimental to a business than falling into the trap of believing their technology is great enough to outweigh good service.

No comments:
Write comments

Interested for our works and services?
Get more of our update !