>> ...and just turned 10, has been nagging me for ages to teach him Haskell...
I'm guessing you would have taught your human(?) kid some human languages first before he started nagging you (why you, he can read too, right?) to teach him Haskell. I think you had a dream or sumping...
Not at all ironic. OP was posting about how customer support is a cost center, amongst other claims. He stated that it is like this in any company. I completely disagree and have experienced the proof of that first hand.
I'm a little unclear from how you worded things--was the question around the notion of firing people as heroic juxtaposed against what we call our support team (ie. Heroes)?
What your example demonstrates though is how much of a difference happens when a company thinks of CS as a profit center rather than a cost center. That's great for you guys but there's lots of industries where CS genuinely is just a cost center and should rationally be treated that way, with all the attendant pathologies that go along with that.
I've heard this argument before and with all respect, I don't buy it.
Can you provide any examples of industries where there is no opportunity to turn CS into a profit center vs. a cost center? Sure it might be very difficult to model and prove out the exact impact it has on the bottom line, but I'm not convinced there are any scenarios where pissing off your customers with a poor experience is better for business than making them feel loved and, well, supported. :)
Sure. The airline industry, for example, has been notoriously unfriendly towards most attempts at differentiation based on quality. Margins are razor thin (http://www.cnn.com/2014/06/03/travel/how-airlines-make-less-...) and customers are incredibly price sensitive. While many consumer's stated preferences are for things like more legroom and less delays, their revealed preference is they'd rather save $5 on a $300 ticket and suffer the indignities.
I would argue you're seeing the same narratives play out in the ride sharing space right now. Lyft tried to compete with Uber with their friendlier drivers vs we'll get you there faster and cheaper messaging and we'll see how long that differentiation lasts since Lyft seems to be rapidly backing away from their branding and into competing on purely on price.
Markets which are natural monopolies like Comcast also don't profit from extra CS. When your choice is shitty broadband vs no broadband, there's little CS, good or bad can do to sway your decision.
Markets where the purchaser is not the end user like enterprise sales also benefits from investing more money in sales than support. Every doctor I've ever been to has bitched at length about basic usability issues with the software they're forced to deal with but they have no real power so the software stays uniformly bad.
Markets where purchases happen infrequently. I recently had to buy a spare part for my refrigerator. Amazon didn't carry it, and the sites that did seemed uniformly low rent and amateur. I ordered from 1 site that said it was in stock and chose reasonably fast shipping. After not hearing from them for 2 days, I sent an email and they got back to me saying that due to a clerical error, it was actually out of stock and wouldn't be shipping out for another 4 days. Meanwhile, the website still listed the part as in stock. They didn't care, what's the worst I could punish this retailer for? Denying them all of my future spare fridge part purchases?
Sure, there's always exceptions to be found in all of these areas but by being the exception, you relegate yourself to a niche of the market and it becomes hard to expand outside of that niche.
> their revealed preference is they'd rather save $5 on a $300 ticket and suffer the indignities.
It's hard to believe this is true. I'd gladly pay $20 extra for a trans-Atlantic seat with more legroom and my experience shows that I'm not alone--all those "improved economy" seats are usually sold out well in advance (and they cost a lot more than $20 on a 1k extra).
$20 a seat will buy you legroom on a 2-hour flight (and $30 will buy you extra legroom in the front of the plane with better recline). Extra trans-atlantic legroom costs more like $200 a seat, though.
In the Bay Area Megapath competes with Comcast by offering the same exact connection but much better service with value added options like proactive monitoring. The same physical line in the ground will get you internet access. They will almost always cost more than Comcast, but it is worth it to many people to not have to deal with automated phone systems that waste your time and ineffectual support.
Right, so what you see is in areas where people have a choice, Comcast rationally decreases prices and increases service levels. That's the entire logic behind Google Fibre. But for most of the country, there's literally no choice of broadband and there's no incentive for Comcast to improve.
I had a feeling you might cite some of these examples :)
Admittedly the Lyft example was unknown to me--I'll have to dig in, sounds interesting.
Specifically to airlines, I'd direct you to some interesting info on Southwest[1]. While TBH the case study doesn't really prove to me the causation of success by being customer-centric, it does show that they can compete in that industry with that approach and be successful.
For the cable industry I'd argue that Sonic.net has carved our a nice business for themselves in part because of their amazing service. That doesn't really disprove your statement that it relegates a business to a niche of the market and makes it hard to expand outside the niche, but I again think back to the question of correlation vs. causation. Comcast, TWC, etc. were all well entrenched before Sonic.net even existed. So it is hard to say how much of a factor that played in their limited ability to compete vs. the fact that they focus on customer service.
Respectfully, what I still remain unconvinced of with your examples is what exactly Comcast and others like them are leaving on the table by not having awesome customer support experiences. You don't necessarily need to break the bank to have one, but you do need strong direction and culture, and that comes from the top down.
I go back to the notion of customer acquisition costing potentially 5x as much vs. retention costs (all hypothetical averages of course). If an industry has razor-thin margins and cost-focused customers, wouldn't you think it would make them a lot of money to maximize the LTV of said customers?
so everyone loves to talk about Southwest but I'd say the far more representative example is Virgin America. Despite being the mesia darlings and winning all sorts of awards, it's hemorrhaged money for 6 straight years before posting a meagre profit (http://articles.latimes.com/2014/mar/26/business/la-fi-mo-vi...).
As you mentioned, it's always hard to separate out cause and effect but I'd argue Southwest's unique fleet and labor arrangements gave it a temporary structural advantage. Now that those advantages are disappearing, it seems to be reverting towards the mean (http://www.wsj.com/articles/SB100014240527023039497045794596...).
When there are other big differentiators, and the CS issue in question is not serious, then yes, the non-CS factors are likely to dominate decisions.
But often this is not the case. I find that while good CS can make customers happy in normal circumstances, CS really makes or breaks a customer relationship when something goes wrong. Good CS and you have a brand advocate. Bad CS and you may have a nemesis that will go to irrational lengths to tarnish your brand out of pure spite.
I left my old cable operator for two reasons: 1) they were unable to fix my cable internet for two weeks, 2) their customer service kept giving me the wrong information.
Of those two, the latter was by far the most important factor. The former was just the trigger that put me at the mercy of their abysmal CS processes. Before that, if you'd asked me, I'd have recommended the company, and been totally neutral about their customer service, as I'd not had to deal with them for anything of substance.
Leaving did not get me internet back faster. It did not get me better service - just different. But it gave me the satisfaction of telling them to f-off, very publicly, after I'd suffered through multiple days of regular calls to their customer service team.
The downtime made me annoyed to start with, but their CS team who could have defused the situation just with some basic courtesy - others have - massively escalated things by being unsympathetic, not passing on the right information, not calling back when there were changes to the situation, and the final straw: after I'd decided to cancel, and had waited in line 45 minutes, I was told the computer systems were down and when I asked if they could take my details and arrange it later, they said no - ok, but could they call me back? No. I was expected to call back, wait in the same queue again for who knows how long, without knowing if they'd manage to cancel for me then.
So just by attitude and a few process issues that would not have made a material difference to their cost, first they lost me as a customer, then they pushed me into publishing a scathing complaint on my blog and tweet about it. I "only" have a direct reach of a few hundred people, but apparently that worried them enough that I had a call from someone claiming to be an assistant to the CEO the following (Saturday) morning, asking how he could help.
While that calmed me somewhat, had they just had better processes in place, they'd have had several thousands pounds in additional revenue from me by now, and not wasted a dozen or so CS reps time with all the repeated calls that arose from their poor internal communications.
That's why good CS matters.
It's those cases where long term previously satisfied customers decides to blacklist you for life and starts to badmouth you to every friend, co-worker and relative just because your CS processes made them angry by unnecessarily escalating some minor problem.
the original assertion that customer service is somehow a cost center is prima facie false, since there are such things as services/consulting companies, and they are some of the largest.
I think by OP he confusingly meant the person in the article, not the post at the top of the thread. Support hero's would be an ironic concept in relation to that.
Ah, that makes more sense. I admittedly read and responded to his initial comment before RTFA. I can see where that might be considered slightly ironic (while simultaneously terrifying that anyone would ever describe mass firings as "heroic").
I used to love the physical cabinet I had in the fifties. The sound of it opening, the actual rustle of the paper under your fingers - these _were_ your files, with real letters written on real paper, not some representation of them in a window on a screen. They don't make finders like that any more....
Clojure is horribly unsafe. I spent a year writing Clojure and half the time we were fixing bugs where someone had wrapped a map in another map or changed the shape of a data structure. For all that's worth, I'd rather use Javascript. To add insult to injury (the amount of wasted time on something that could be easily checked by a compiler and a sane type system) there's all the bad habits you acquire and the general lack of confidence in your code, which took a good six months after that to cure. I'm sticking with types now, thank you very much...
Sounds like you needed Schema, which can ensure the shape and contents of a map as :pre and :post assertions in every function you annotate, then be turned off for production use. https://github.com/Prismatic/schema
That's why I come back to Clojure every time, if I need anything, it's available as a library. Need better typesafety? Just add in what you need with a macro or two. (Schema is not much more than that).
That's not really possible easily with Javascript, and Javascript has a lot more unsafe by default edge cases than Clojure. I'm not sure why if a mostly safe dynamic language bothers you, you'd now prefer an extremely unsafe dynamic language?
Lastly, types only give you a single dimension of safety, is this that exact shape, and ensuring I don't put a square peg into a round hole: both of which Schema adds in easily. Clojure is ALSO safe along many other dimensions, like thread saftey, immutably, null reference exceptions, etc.
80% of the problems I had to deal with (in a live, real-life Clojure system that had to be maintained and supported, not a hobby-happy-slappy-project-thing) were caused by putting square pegs in a round hole. You're telling me I need to get a macro-based library and add :pre and :post conditions that check the structure of a map, as opposed to using a language with types?! Really??? Oh, and guess what, I am sure there is a Javascript library that does that too...
I don't really use anything in production, I am just a learner right now :)
There are some people using some of extensions for Haskell inspired by "dependently typed" systems in production.
Dependent typing is an active research topic right now, and I doubt any fully fledged dependently typed language is used "in production".
However, I was just pointing out that it is possible for types to express a wide variety of things that we do not normally associate with them. Even without full dependent typing, Haskell types are wonderfully expressive and powerful.
Oh, god, thanks for reminding me about the whole agent/atom/ref hell - another reason I'd rather erase the whole Clojure experience from my brain altogether...
Jesus, maybe you were not able to read a clojure book befor you started. Its amazingly simple to explain how to write thread safe code with clojure, and pretty easy to add concurrency safly.
There are 3 concepts that are all diffrent, and a couple yours ago core.async was added. All in all thats a amazingly simple and powerful combination. Everybody I have heard is pretty happy with these tools. What is your problem?
Agree to disagree. I do not enjoy the impossible to prove defensive coding around threads and callbacks. The core.async library made threading in Clojure for me to now be simple and pleasant compared to difficult to test mutexes and deadlocks.
You're the first person I've seen that is vocal about having a truly bad experience with Clojure. Even from other people who prefer strongly typed language, I've mostly seen them expressing it as "not their taste", rather than actively dislike it. Do you mind sharing your experience and what was wrong with Clojure? You put js as an alternative, but in term of typing, js is borderline one of the worse type system out there.
Great, if you want to hire people who "can code", but have no social skills. I am personally done working in environments where people think they "can code" but have not enough of a social skill to at least empathise with your point of view on naming conventions.
Don't get me wrong, I can code, I'll write you anything you want, AND IT WILL WORK! and I'll still know there may be a better way but this is the way that works and I still think I don't have enough years to live to argue with social incompetents who think that fighting over tabs or spaces is a good idea and a pocket protector makes you sexy.
More often, when talking about naming/indentation conventions, consistency is more important than who's right. The entire code base should look exactly the same (no exceptions).
Most people will (rightfully) settle for money. Because people need love, and to demonstrate love you need to show that you care, that you're willing to give something up in a hard situation. And the only thing a company cares for is money. So, I want said company to give me money. More money than the 'manager'. Because I can do their job just as badly as they are doing it, but they can't do mine at all.
I don't want your stupid titles and shit - those are cheap. Cash is what will hurt you. Pay up if you care!
And when people realise they have to pay you or lose you, then you get respect. Priceless!!!
Please note that, below, when I refer to a multi-paradigm language, such as Scala, as an OOP language, I am specifically referring to the OOP qualities in that language. And I would like you to ask yourself, if you use a multi-paradigm language to write in the “functional” paradigm, are you actually gaining anything from the OOP qualities of that language? Could you perhaps achieve the same thing, more easily, using a language that is fundamentally “functional”, rather than object oriented?
Yes, isUpper is a method on Char, _.isUpper is a lambda that is given to exists, which is a method on the trait TraversableOnce, which String happens to implement, along with many other things, such as Option and Future. Where's the OO and where's the functional? In the Clojure example in the OP does the author realise that all of those things are in effect Java objects? Does any of this make the code better or worse?
But that's not the point, the Scala code provided there is beyond ignorant, whoever wrote that has no right to be judgemental of the language or its founding paradigms.
I'm guessing you would have taught your human(?) kid some human languages first before he started nagging you (why you, he can read too, right?) to teach him Haskell. I think you had a dream or sumping...