Archive for May, 2017

Can Chatbots Replace Humans?

Friday, May 26th, 2017

If you think bots will never replace human agents, you’re amongst the lucky few who has been served by intelligent human agents.

I admit that I’ve also been among the lucky few at times. But more often than not, I come across fairly dumb human agents. And, lately, I’ve started experiencing fairly intelligent chatbots.

Let me give you three recent examples.

#1. MNO (HUMAN AGENT)

I sent an email to this leading mobile network operator in July last year inquiring about its 3G plans. I get its quote in November! Although he – yes, it was a he – took four months to respond, the human agent hadn’t found the time to check my customer record in his CRM. Had he done so, he’d have found out that I already had a 3G connection by then! (Which I got by connecting with the MNO on social media after waiting in vain for a reply to my email)

#2. PUBLISHER (HUMAN AGENT)

I recently renewed the subscription of a reputed global business magazine. From the date of the last issue mentioned on the magazine’s jacket, I got a feeling that my subscription period was calculated wrongly. I decided to take this up with the Indian distributor of this global media giant. I sent the following email to this company:

Dear Fortune Subscription Department:

My newly renewed subscription is for 30 issues. I opted for Special Gift of “10 Bonus Issues”.

Therefore, my subscription should cover a total of 40 issues (being 30 + 10).

According to the cover sheet received along with the first issue dated 15 Dec 2016, my new subscription apparently expires in JUNE 2018.

This covers only 25 issues, calculated as follows:

December 2016: 1 issue

2017: 16 issues (being 12 + 4, given that frequency is monthly plus 4 extra issues per year).

Jan-Jun 2018: 8 issues (50% of full year figure of 16 issues)

TOTAL: 25 ISSUES

So there is a discrepancy of 15 issues (being 40 – 25) between what my subscription should include and what your cover sheet states it includes.

Please arrange to resolve this discrepancy and restate my correct last issue date – it can’t be June 2018.

Thanks in advance.

Thanks and Regards / Ketharaman S

I got the following reply:

Dear Mr Ketharaman,

Greetings from Business Media Pvt Ltd !

This is further to your appended mail regarding FORTUNE ASIA magazine.

Please be informed that FORTUNE is a monthly magazine with 4 Quarterly double issues which counts as 20 issues in a year.

Please feel free to contact incase of any further information is required.

Looking forward to your continued readership.

Best Regards,

Dhanpreet   |   Fortune Asia

Chief Manager – Consumer Marketing Services

As you can see, the reply – from the head honcho of the Indian distributor’s consumer marketing – was extremely casual and didn’t come anywhere close to answering my question.

I gave up on this company and finally got my issue resolved by escalating it to the parent company’s Asia Pacific headquarters in Hong Kong.

#3. BANK (CHATBOT)

I recently tested out Eva, the chatbot deployed by a Top 3 private sector bank in India.

I first raised a straightforward query:

Eva passed this test with flying colors.

I then logged a complaint related to the discrepancy in the length of the narration field between the bank’s IMPS and NEFT payment methods:

Eva failed this test.

But so did the human agent handling the bank’s Twitter account. Despite explaining the problem by attaching a screenshot to my tweet, I didn’t even get the bank’s customary auto-response.


When I wrote about chatbots here and here seven years ago, I found many of them to be quite human-like. I thought virtual agents – as chatbots were called at the time – showed tremendous potential and predicted that they could replace lower-end human call center staff within the forseeable future.

Well, that future is already here. Even a simple chatbot like Eva can match or outdo the two human agents described above.

From this, can we conclude that chatbots can replace all human agents?

NO.

Because there have been other situations where I’ve received a much better level of response from human agents that can’t be matched by chatbots available today.

This got me wondering when a chatbot can replace humans and when it can’t.

To answer this question, I’d a look at the so-called QRC model. According to this popular model used in customer service, customer missives to brands fall under Query, Request or Complaint e.g.:

  • Query: What 3G plans do you offer?
  • Request: Please send me a paper bill ASAP.
  • Complaint: My printer has stopped working.

When we think of Customer Service, we tend to think only of complaints. However, that’s not an accurate representation of what happens in contact centers. According to several CX leaders I’ve spoken to in the course of executing some of my company’s engagements, only 60% of support tickets are complaints, with the balance 40% split evenly between queries and requests.

From personal experience and anecdotal evidence, chatbots can outperform human agents for answering virtually all customer queries.

With the recent advances made in Artificial Intelligence / Machine Learning, chatbots may soon be able to match mid-level human agents for fulfilling most customer requests.

However, chatbots will lag high-end human agents for resolving complaints for the forseeable future. That said, sophisticated chatbots can already complement human agents in this area.

I saw a great example of this when I couldn’t access one of my websites recently. Like I usually do, I used Twitter as my first port of call to reach out to my hosting service provider. Involving SSL, domain redirects and a few other complicated issues, the problem soon went over the chatbot’s paygrade. At that stage, the chatbot handed me over to the company’s live chat channel handled by a human agent. Normally, whenever I switch channels – say from email to telephone or vice versa – I’d have to start all over again. That didn’t happen this time. The chatbot seamlessly passed on the transcript of the Twitter DM conversation to the human agent so I could continue from where I left the Twitter DM conversation.

Agreed that such examples of seamless “omnichannel customer service” are few and far between today but I expect the technology to go mainstream soon.

So, to return to the title of this post. As things stand, with my vast experience with human agents and limited experience with chatbots, I’d answer the question “Can Chatbots Replace Humans?” thus:

  • “Yes” for Query.
  • “Maybe” for Request.
  • “No” for Complaint.

Looks like I’m not the only one who is so optimistic about chatbots taking over many customer service activities from humans.

According to a MarketingCharts.com / PegaSystems survey of 6,000 adults in North America, EMEA and APAC, the largest segment of the surveyed audience (38%) felt that chatbots can provide better customer service than human agents in the future.

This is great news for service providers who suffer from severe attrition of human agents caused by the tedious nature of most customer service work. By taking over their mundane work, chatbots can free human agents to focus on cross-selling, upselling and other value-added areas of customer engagement.

How To Win A Deal By “Sharing An RFP Template”

Friday, May 19th, 2017

“Can you give us an RFP template to share with our client?”, asked one of my company’s customers recently. “We can Google it but you can save us the trouble if you have something readymade”.

Good they didn’t use Google – there’s lot more to sharing an RFP template than Googling, downloading and handing over a standard template. B2B technology providers can use the opportunity to “share an RFP template” as an opening for introducing specs favorable to their product or service in the evaluation process. By shaping the purchase process in this manner, they can substantially increase their win rates.

But they need to play this right. Most prospects are savvy enough to see through one-sided specs and throw the vendor’s RFP template – if not the vendor itself – out of the purchase process.

Shaping an RFP calls for “outside-in” thinking, where you start from the customer’s pain area, spec a solution that alleviates the pain and also happens to showcase your differentiators.

Let me illustrate this approach with the following case study:

—–

The prospect was a large company with multiple production facilities and a wide network of regional and zonal offices. The company wanted to purchase and implement an ERP solution and invited all leading ERP vendors for a pre-bid conference. One of them was the protagonist of this story – let’s call it ACME. Its sales manager had a good rapport with the prospect’s CIO and was invited to share a sample RFP template.

To give you a bit of background about the market: ACME implemented its own ERP. Whereas its competitors just sold their software and left it to the customer to get it implemented by a “third party implementation partner”. ACME touted self-implementation as a strong differentiator on the back of the logic that, since a product owner knows the product best, it should be the one to implement the product.

In line with its usual strategy of using self-implementation as its USP, ACME added the following spec into the RFP template:

“Self-implementation: ERP vendor should implement its package by itself.”

Like it happens often in sales, the logic that makes great sense for a vendor crumbles when competition enters the picture. That’s what happened here.

ACME’s competitors billed their third-party implementation partner network as a major benefit, saying this provided access to global best practices and brought superior program management skills to the implementation. They also thwarted ACME’s thrust on self-implementation by saying that ACME was too small to attract third party implementation partners, which is why it had to do its implementations by itself.

In effect, competitors persuaded the prospect that, by touting self-implementation, ACME  was merely trying to create a virtue out of a weakness. As a result, ACME’s attempt to stipulate self-implementation in the RFP went out the door.

This was a big blow to ACME because self-implementation was a major plank of ACME’s pitch. It was about to lose the golden opportunity to steer the purchase decision in its favor by spec’cing the RFP.

This is when ACME brought us in.

We dug deep and were able to spot a fundamental flaw in ACME’s tactic: “Self-implementation” was an “inside-out” attribute. While ACME did try to convert the feature into a benefit, competitors were able to counter it effectively by promising other benefits from their third-party implementation offering.

In our experience, an “outside-in” perspective has a much better chance of working – not just in an RFP but in all stages of the sales process. Here, the spotlight is on the prospect’s pain area. All benefits and enabling features are shaped by alleviation of the pain. Not the other way round as is the case with an “inside-out” approach.

After a round of brainstorming with ACME’s team, we came up with a different spec:

“ERP product vendor must take responsibility for the success of implementation”.

Now the RFP didn’t forbid use of third party implementors. It just asserted that the product should work for the customer – a very logical ask from customer’s point of view. It also sought to mitigate the risk of failure, which was – and still is – is a clear and present danger in any enterprise software implementation. No prospect in its right mind could argue against this stipulation. And so the spec was inserted into the RFP and circulated to all the vendors.

Since ACME was doing the implementation by itself, it was a no-brainer that it took the onus for its success. That was not the case for competitors who wouldn’t / couldn’t underwrite implementations done by third parties.

This gave ACME the winning edge.

Let me hasten to add that we need to be careful while writing specs like these so that they don’t pose an undue risk to the vendor, especially when it comes to implementation of enterprise-grade software with hundreds of locations, thousands of employees and countless moving parts. We mitigated the risk for ACME by specifying a set of success criteria and multiparty roles and responsibilities.

—–

I highlighted the importance of spec’cing an RFP in What Happens Before A Prospect Contacts Sales?. Getting ahead of the RFP is the only way for sales to escape the blindzone caused by the modern Buyer 2.0 purchase behavior.

Like a veteran B2B sales manager used to say, “if you get an RFP without working on it in advance, you’ve already lost the order”. Although his statement is two decades old, his words ring more true today than ever before. As McKinsey highlighted in a recent report, “two-thirds of B2B deals are lost before a formal RFP process even begins.”

Vendors can shape an RFP on several dimensions including core product features, company stature and attributes of the total ownership experience. While we’ve used the example of ERP to illustrate how to do this right, the basic principle contained in this post can be adapted for any kind of B2B technology product or service. If you need any help with this, we’re always there!

Why Gmail When Hosting Provider Gives Free Mail Boxes?

Friday, May 12th, 2017

After trying out a half-dozen hosting providers, I settled on one that I’ll call ACME. Among other things, I selected ACME for its following two features:

  1. Hosting for virtually unlimited domains on a single hosting plan
  2. Free unlimited number of mail boxes, each with virtually unlimited storage (subject only to the overage storage limit under the selected hosting plan)

These two features were strong differentiators for ACME when I signed up for it. Apparently, they’re not widely available from other hosting providers even now because, whenever I talk about them, many people find them unique to ACME.

I also use these features extensively – as you can see from the following screengab of the Mail section of ACME’s control panel, I’ve over 70 mail boxes.

The above USPs that attracted me to ACME have made me loyal to ACME – a decade after I selected ACME, I still host all my personal and business websites on ACME.

Not only that, I keep talking about them to many people. Ironically, without any explicit loyalty program, ACME has cracked the Holy Grail of modern loyalty programs.

While the first USP of ACME will only appeal to people who own multiple domain names and websites, the second USP is more broadly useful because everyone – individual or company – needs email, typically one mail box per employee. And many people whom I’ve recommended ACME to have signed up for it, primarily attracted by its offer of free mail boxes.

That’s why I was stunned to see the following “banner ad” on the email section of ACME’s control panel recently.

“Upgrade to Professional Gmail”, proclaimed the ad.

I thought, what the heck, people are choosing ACME because of its offer of free mail boxes, why would they want to move to Gmail.

Turns out the operative term in the ad copy is “Professional”.

While ACME provides mail boxes, its three web apps for viewing emails  – horde, roundcube and SquirrelMail – are a bit scrappy.

I noticed their poor UI right in the beginning and never used them. Instead, I’ve been using Microsoft Outlook as my email client from Day One of signing up with ACME. You can’t get more professional than that. Therefore, I’ve never felt the need for Gmail or any other email service provider.

However, that’s only me.

Outlook is de riguer in the enterprise world but many startups don’t have much love for Microsoft Windows in general and MS Office in particular. Many of them prefer the open-source Linux / Ubuntu and Libre Office, which are free. They don’t have Outlook and, in its absence, they’re compelled to use frontends like horde, which do look unprofessional. Ergo, the relatively more professional-looking Gmail will appeal to them.

Ergo upgrading to Gmail is worth it for the market segment that doesn’t have Outlook or a another professional email client.

As for me, I’m happy with my free ACME mailboxes and perpetual-license of Outlook that I bought many years ago.

In this day and age of sophisticated audience targeting, ACME might want to check what email client its users use and then take a decision whether to target its banner ad to them or not – instead of showing it to all and sundry and shocking some of them like me!

Why Is Software Still Built From Scratch?

Friday, May 5th, 2017

A few months ago, I’d visited the South Indian temple town of Tirupati with my family. On the way, whenever the train stopped at a station, the engine was switched off. But the air-conditioning still worked because it was powered by huge battery packs installed in the AC coach. Coincidentally, the manufacturer of these battery packs is located close to Tirupati. I know this company from the time it purchased my employer’s ERP in the early 2000s. Through the years, I’ve stayed in touch with the ex-CEO of the unit, Rajesh Bapu.

I met Rajesh during my latest trip and introduced him to my family as the guy who “built the electronic circuit that manages the battery packs on AC coaches of Indian Railways trains”.

He corrected me, saying, “I assembled the circuit using available integrated circuits without building every part of it.”

12?F Capacitor (Source: Amazon.com)

Yes, indeed. Since times immemorial, automobiles, printed circuit boards and many other products are assembled from standard components, which can be sourced from catalogs.

But not software.

I joined the software industry two decades ago. From then to today, I’ve been hearing of technologies like SOA, CBSA and microservices that purportedly allow programmers to build systems by assembling prebuilt functionality.

But that vision has still not turned into reality.

Once upon a time, developers had to build software systems from scratch perhaps because there was no prebuilt functionality.

Then, it’s quite likely that developers built reusable components by using technologies like SOA. But, despite the existence of methodologies like CBSA, development teams still had to build software from scratch because they didn’t know about the existence of reusable components.

Then came innovations like open source repositories and open API marketplaces.

For the uninitiated, an open source repository (e.g GitHub) contains prebuilt source code for components that can be used by programmers to develop their own systems; and an open API marketplace (e.g. Algorithmia) expose readymade functionality that can be accessed by developers from their systems via application programming interfaces.

In theory, if you want to develop a new system, you should be able to review the catalog on these platforms, pick and choose the component or API you need, and integrate the prebuilt functionality into your new system.

In practice, this has worked reasonably well in building software pilots / proofs of concepts / MVPs.

However, when it comes to enterprise systems, these platforms haven’t made a big dent in the traditional way of building software systems from scratch. I’ll outline the key hurdles of changing the time-worn development methodology by continuing to use the PCB analogy:

  1. A 12?F (twelve microfarad) capacitor will work on any PCB. Whereas, since software is heterogeneous, a .NET component won’t work in a Java system.
  2. You can’t manufacture a capacitor ab initio even if you wanted to – at least not within the timescales of most PCB development projects. Whereas, most development teams believe that they can develop any piece of software from the ground-up within software project timescales.
  3. You use a capacitor as it is. Whereas developers inevitably need to make some changes to borrowed code before being able to integrate them into their systems. According to open source foundation rules, you’re required to share the enhanced / modified code back with the community. That can be tricky if it contains a company’s secret sauce. You either flout OSF rules – à la  the investment bank described in Michael Lewis’s book Flash Boys – or eschew open source code altogether.
  4. You can buy a capacitor. But you can only license an API, which is not the same as buying it. The license is subject to the Terms of Service of the API owner (“OEM”). Now, many of these TOS are ambiguous and easy to infringe without any wrongful intent. The deadpool is littered with startups that got on the wrong side of the TOS of an 800-pound gorilla’s API.
  5. Once you plug a capacitor into your PCB, it will work the same way throughout its lifetime. Whereas an API won’t. When its OEM releases its next version, you’ll need to modify your software such that it works with the updated API. We faced a costly change to our HEATMAP360 social intelligence platform when Twitter changed its API specs.
  6. If the manufacturer of a capacitor (also “OEM”) folds up, your PCB will still work. But, if the API’s OEM dies, your system will stop working and you’ll need to find an alternative source for the said functionality. As illustrated by the examples in Does Cloud Increase Vendor Risk?, the death of a few API OEMs has caused existential crises for many software systems and their owners.
  7. Then there’s the big elephant in the room that no one talks about: Programmers don’t like working on code written by anyone other than themselves.

As a result of these challenges, it has been hard to develop enterprise-grade software systems by assembling prebuilt functionality.

That’s not to say it can’t be done.

But cracking the Holy Grail of software engineering will require structural changes in the way software is packaged and sold. The purchase process for software should mimic that of electronic components whereby customers can:

  • discover software components in an open catalog
  • find out their specifications and select which components they need to assemble their system with
  • buy the selected components outright without onerous licensing terms or dependency upon any form of first- or third-party IP
  • be assured of getting the same functionality throughout the life of the software, and
  • modify components without having to share the source code with external entities.

If you’re wondering “what’s in this” for a software product vendor, you’re not alone. Actually, this model is more closely aligned with IT services. More on that in a follow-on post.