The other day, a colleague got back to the office with a flyer advertising a pop-up coffee store around the corner from our office, in a gentrified-fashionable part of Tokyo. It advertised free coffee. We needed to have a business conversation and headed over.

The requirement was made clear to us when we arrived that a post on Facebook or a tweet with the pop-up’s hashtag would be appreciated. Here, my limited knowledge of Japanese limited my understanding of the pitch, but it seemed to me we were asked to refer to the taste of the coffee (an interesting attempt at priming us to notice the great flavor waiting for us in the cup). I was a good boy and tweeted:

Now, to be honest, “sweet” was the nicest word I could come up with — I was actually disappointed and not very impressed with the coffee, but I was afraid of being the philistine and also didn’t want to sound ungrateful when the staff had been so nice and, after all, had given me free coffee.

Also, the environment was really, really nice: wood and bright lights, airy and sophisticated, in a fresh back street of Omote-Sando.

But neither of us really drank that fast, the coffee was just not very good.

When we left, we drained our cups and the staff then pointed out the words printed at the bottom, which informed us that we’d in fact been drinking canned coffee — this wasn’t brewed fresh, and was in fact Coca Cola’s Georgia brand coffee.

Don’t get me wrong: canned coffee can be pretty nice: I’m a huge fan of Kirin’s Fire brand, which feels reinforced with extra caffeine and will get my heart racing on the first couple of gulps.

However, this was pretty poor. The taste wasn’t very pleasant, and there was no bite to it.

Now, what to make of it?

This didn’t make me feel great. The slightly overwhelming service was beyond friendly, and they were very successful at ensuring that I spread the word on social channels. However, priming and context can’t fix a poor product, and I won’t either recommend it, or buy it myself.

Also, I feel I’ve been used a bit. The “gotcha” at the bottom of the cup (if I’d been able to read it myself, and explained to me verbally instead) was somewhat annoying and didn’t make me feel very good about the experience.

Overall, while I enjoy “ambush” marketing if another brand is the target of the ambush, I do not enjoy being tripped up myself.

Finally, I believe I understand what’s good about “enterprise software.”

Until now, I thought “enterprise” was a conventional justification for inferior, bloated, and massively costly software that hardly did what it was supposed to, and certainly in a way that took neither users nor best practices into account.

To me, “enterprise” meant the opposite of agile, high-quality, user-friendly, high-performance, innovative, and capable of being iteratively improved after launch. And I simply could not fathom why anyone with an ounce of common sense, animated by the desire to do good (as opposed to being Mordak or the BOFH), and equipped with a bit of relevant technical knowledge, would ever choose such solutions over the better alternatives.

Those better alternatives being SaaS, software built to order by actual human beings that happen to be good developers using agile and other modern approaches, or open-source packages brought together in a meaningful combination.

This all remains kind of true. (I want to assuage any concerns I might have become a convert, we’re not quite there yet.)

But such a choice does have some advantages (and that’s what I didn’t have an instinctive understanding of): scalability, long-term stability, and risk management.

Scalable isn’t so much in terms of numbers of people using the product simultaneously, nor quantity of data or transactions being handled (this may or may not be part of the package), but in terms of quantity (large) and quality (can be low) of resources that can be brought on board to the project, and how systematic that onboarding can be.

The enterprise approach relies heavily on planning and structures because the contributors aren’t asked to shoulder the overall purpose and understand all stakeholders, nor to commit to an elusive definition of abstract quality. On the contrary, the definition of quality for any member of a project, regardless of their role, can be fairly well understood by anyone, because it is defined, in simple terms, as part of the specifications.

This doesn’t sound very appealing to me, but in the practice, it means that the client or recipient of the product can trust the project structure to come to life in a rather short period of time, in many different places at the same time, independently of fundamentally unreliable factors such as buy-in, enthusiasm, or conceptual understanding and alignment.

The alternative is organic project growth, which is perhaps more satisfying, and definitely feels more cost-effective, but is slower and depends so much more on recruiting, retaining and maintaining the motivation of high-skill individuals.

Long-term stability comes from the fact that little if any knowledge is held exclusively in people’s heads. The emphasis on explicit documentation and measurable targets (unit tests, SLAs) ensures that various stakeholders can come in and out of the project without upsetting the overall structure.

With much of the “better” software, bit rot (the decay of functionality due to technical advances breaking compatibility, random infrastructure failures, and human mistakes, around systems that aren’t under active development) requires specific provisions, which are often considered onerous.

The enterprise approach has ready-made, well-known arrangements to handle long-term stability. For example, the concept of “legacy platforms” isn’t really about the old code itself, but the practices that have to be developed to keep it running in a changing environment.

Risk management is an interesting question. In the startup world, taking risks is part of the lore, and a daily occupation. However, risk-taking is a fairly specialized business, and larger corporate organizations have a limited taste for it, usually concentrated around the organization’s core business.

Functional development projects that fall outside of the organization’s core mission are very likely to get nixed, one way or another. Not conceived is the first level: nobody will think of them. Not formalized is next: for whatever reason, a person who had an idea doesn’t bother to actually capture it and shop it around for execution. The enterprise model can’t really do anything about either barrier.

But the next barrier is that a project will not get approved. The enterprise model contains very strong tools for describing (and actually increasing, at least on paper) the feasibility of an idea, which can ensure the idea is accepted by the organization. Project plans are very actionable for management, in that they only require a binary approval.

Then comes the possibility that a project will fail. In my opinion, failure isn’t necessarily a big problem — what’s most important to me is for the organization (and the individuals inside it) to learn from the process, and therefore get better at carrying out its purpose. However, project failure in large organizations curtails the ability of teams and individuals to pursue further projects (as failure is usually considered negatively…), and the enterprise approach, when done properly, all but removes the risk of failure. (The risk that a project was irrelevant in the first place — a huge cause of failure — isn’t really taken away, though.)

And finally another risk is the inability of an organization to sustain a project — the previous point about long-term stability is a strength of the enterprise model.

In summary, I still hate the enterprise approach, even if it works. It goes against my instincts, it perpetuates a dependency on swindle-as-software (SaS, as opposed to SaaS), and I remain unconvinced that the tradeoffs (much more expensive, and perhaps less satisfying for some of its practitioners, in exchange for the key benefits outlined above) are actually worth it in the bigger picture. But I now see how, in many instances that are common and legitimate in larger organizations, it can be a better choice, and often the only option actually available.

I still would like everyone (inside and outside IT organizations) to be enough of a software engineer to be able to tackle data, computing, and business-process problems in a leaner, more knowledgeable way, and I believe a higher tolerance for the more likely failure of smaller individual projects can actually lead to a stronger company — but that’s probably an unattainable ideal at the moment. To its credit, the enterprise approach lives in the reality of business.

Once again, my team is recruiting! [Edit 5 Sept: only one position left to fill!]

The global ASICS Digital Marketing team works from our office in Shibuya, which gives us access to many greatfoodoptions, and has recently been equipped with a fancy coffee machine (no nespresso for us).

As we’re preparing to launch e-commerce globally (actually, we’re already selling online in Japan but it’s still a big new push), I’m fleshing out my team. We’re looking for smart and ambitious people who are excited about bringing ASICS and Onitsuka Tiger products to online shoppers, and will help our regional teams achieve their commercial objectives.

At the moment, we’re looking for two roles:

an e-commerce product lead, who will develop the platform and create new revenue streams, whether new products or new ways of selling [hired!]

Would you like to join our team, and participate in changing the face of this company? Review the job descriptions, and send us your resume with a cover letter: tell us what you’d bring to the brands, and how you’d approach the job!

First, the April 2011 assessment by Ben Horowitz on Page’s new brief points out the difference between peacetime and wartime CEOs, which boils down to whether the company’s market is new, expanding, and relatively non-competitive, because its expansion benefits the company anyway, regardless of whether it benefits other players as well — a wartime CEO is focused on outright winning an existing market from the competition.

Second, a January 2013 article in Fortune, which points out that Page has carried out significant reform in the direction of tighter execution control, focused on a more defined plan, and somewhat stepped back from the culture of all-out innovation with less concern for a business model.

Signal is pretty good, and I’m checking my email and using maps (marginally better in China on iOS 6, by the way!) while on the subway. Everything is dramatically slow but functional. FaceTime even works (although I only succeeded in taking an incoming call, but couldn’t place any myself).

However, this is still the internet from within the Great Firewall. And right now, while Gmail access has been restored, Google itself (the search engine) is still blocked, as are Facebook, Twitter (including the URL shortener t.co), and Bitly.

And TinyLetter is in fact using a captcha supplied by Google, hosted on the banned domain www.google.com. Here’s what it’s supposed to look like:

Now this makes sense.

Site and app makers: if you want to be reliable in China, make sure to host your libraries yourselves. You never know when the country’s censors will take down a site you were relying on, and all those libraries and social media widgets will just refuse to load until they timeout, rather than spit out an immediate error.

Over the past few years, social customer support has really taken off. KLM was covered in the business press for making its service agents available through social media channels (they’re on Twitter with 316k followers and 94k public tweets, Facebook with 2.1m likes, Google+, Pinterest, etc.).

It starts well, for example, the response comes back very quickly:

@raphal Hello Raphaël, that doesn’t look good! Can you send us your bookingcode in a DM so we can investigate this further, thank you!

However, no solution was then given to this problem: after a few follow-up questions, the @KLM team advised me to use my desktop browser. (And since last month, I haven’t tried the mobile site again — I’m not sure the payment form has been fixed.)

I was left frustrated on my primary goal (couldn’t book the upgrade), an irritated that my issue was not understood and dealt with. And I’m not sure KLM picked up on the actual problem in their mobile app, which makes me unlikely to use it again: why would I waste time with a mobile booking that may fail at the time of payment?

Social customer support rule #2: make sure to understand what actual issue is underlying that user’s problem, and when it’s a real problem with your product or service, launch an internal project to fix it for everyone.

Social customer support rule #3: follow up, so the user’s trust in your service is restored. This implies some kind of continuity in tracking the issues and the internal projects that relate to them.

Another one, when I was faced with a check-in problem, with the intro text hawking a possibility that wasn’t actually available in the options listed underneath:

@raphal Hello Raphaël, we just tried this and it works! Please only select the option “send boarding pass” and then this should work.

I would never have believed I’d see an instance of “we tried it and it works” in the wild! What an amazingly unhelpful answer.

Social consumer support rule #4: afford your users the same standards of respect online as you would offline, although allowances must be made for the 140 character limit, and the informal nature of online interactions.

A few months ago, I was stuck in a traffic jam on the highway to the airport (an accident blocked traffic for a couple of hours). When pinged, @KLM’s answer was: call the airport, which in itself was rather unhelpful. But what’s worse: no phone number was provided. I was back at square one, and vaguely irritated.

Social consumer support rule #5: when offering support, make sure you’re empowered to actually solve the user’s problem, whether googling something for the user, or navigating the internal teams of your organization and roping in the appropriate resource. Act as a concierge, rather than a switchboard.

I think it’s great that KLM is trying hard to be closer to its passengers. However, the rush to use social channels has undermined key success factors for customer service. And in my personal case, the heightened expectations have led to disappointment, and damaged KLM’s brand image as flailing and useless.

Posted inCommentary|Comments Off on Social customer support: 5 rules to avoid disappointment

What do you think will happen if I click on S? Will I teach my spam filter that it was right in catching this mail, or will I have the email delivered to me? (I suppose the lack of an “N” option is disabled by the administrator, but then does it really need to be in the caption? Never figured out what the red markers were for.)

My point here is: the actual, real-case usability of a web app is complex, fiddly, and can break down easily. Using short-hand for controls along with captions to explain what the short-hand means — this isn’t a sensible trade-off.

This week, I’m working in China. At the moment, I’ve got a room in a fancy hotel in a peripheral neighborhood of Shanghai, where my company is holding its sales conference. Bad internet is not a stranger to high-end hotels the world over, but over the past couple of days, I’ve been made aware of just how much I rely on internet connectivity for my daily work.

I’m a big user of Dropbox, because it allows me to have my files offline (as opposed to Google Docs online-only approach, although Google Drive is supposed to change that), across several computers, easily accessible on my mobile devices, versioned, and shareable (systematically with designated colleagues who also have Dropbox, or as a one-off with special URLs).

My company relies on the dreaded Lotus Notes for email. It’s bad in so many ways, many of them related to how it’s managed for us (the ridiculously low mailfile size limit and mobile support limited to Blackberry), some related to the architectural design of the tool.

Although more of my tools are having difficulty, I’m deliberately picking those two examples: one is a fairly modern digital-native tool, well-written and very stable, while the other is a notoriously clunky holdover computing concept from over a decade ago.

Both fail spectacularly in this context of low-bandwidth, limited internet access. And guess what still does work well?

As I have noted at greater length elsewhere, I had come to fear that China may be where the 200-odd-year-old carbon-fuelled capital-driven model of economic development runs into an ecological wall. Britain, where it started, and China may be bookends on a period of global expansion that has never been seen before and may never be repeated again.