Chatbots: An Enterprise Architect’s Perspective
Messaging apps are more than just a trend; they’ve already emerged as the dominant mobile interface, surpassing even Social Networks. And now chatbots are following lockstep, providing ancillary services directly therein. The reasoning goes: If you’re already using your messaging app, why exit and load an entirely different interface just because you need to hail a ride? The messaging app already has your identity, location, and potentially your credit card. How much less friction is involved with simply typing lyft or uber? A well designed chatbot could offer a quick list of your most common destinations and ask which card on file you’d like to use. One word and two clicks later, and you’re on your way. As we look forward to a future already underway, the question is, “How do we get there without disrupting what we already do well?”
Using Hindsight for Insight
When mobile apps began gaining traction in the late aughts, it was no great surprise that many were hardly indistinguishable from their Web app predecessors. Forms, links and buttons are all vestiges of the Web app legacy upon whose shoulders mobile apps now stand. But consider China and other emerging markets. While US and European markets were the first to embrace mobile, the fact that China was effectively a greenfield market with no existing infrastructure paved the way for more rapid change.
The biggest advantage for China’s tech industry, according to many analysts, is that it was able to fill a vacuum after the country essentially created much of its economy from scratch following the end of the Cultural Revolution, in 1976…
Many Chinese also never bought a personal computer, meaning smartphones are the primary — and often first — computing device for the more than 600 million who have them in China.
— Paul Mozur, New York Times, “China, Not Silicon Valley, Is Cutting Edge in Mobile Tech”, Aug 2, 2016
It’s an interesting insight that reveals the essence of the challenge that mature markets now face, namely, once a technology becomes entrenched, changing that technology has a derivative impact. While consumers eventually change their favorite app-du-jour, the enterprise is significantly disadvantaged as they consider existing business processes. How much will it cost to retrain the workforce? How long will it take to implement? Change management — particularly within the enterprise — drives decision making, not a laundry list of the latest features.
Viva la Evolution
In late 2015 Gartner coined the term, post-app era. Although provocative, the essence of the argument is not that mobile has become passé; rather, it simply acknowledges the relentless, ever-changing IT landscape. For the CIO and similar decision makers, the most pressing question is, “What’s next?” With Chinese and other Asian markets as our guide, the answer most certainly is chatbots, which of course begs the next question, “How do we get there?”
I’ve spent the majority of my career as a software architect designing tools for the enterprise. I know from first-hand experience to never pitch wholesale change. Instead, it’s better to learn the customer’s business: markets, capital investments and legal constraints to name a few. You need to reassure decision makers that their existing processes and employees are still good enough. Show them the straight and navigable line between what they’re already doing well and how they can adapt their existing expertise to an uncertain future.
API-driven design is the cornerstone for handling uncertainty and change. It began in the early aughts with service-oriented initiatives (like WSDL/SOAP) and has only accelerated with the emergence of the API economy. Whether one sells widgets or services, a well-conceived API defines the long-term, transactional nature of the core business. Surfaces ranging from Web sites to mobile apps will come and go, but a well-designed API is rarely so mercurial. As we look forward to an uncertain future, one thing is sure, namely, APIs will continue to serve as the bedrock of a resilient technical strategy.
Apples to Apples
A great way to understand new and abstract concepts is to frame them using familiar, concrete examples. It’s not enough to simply say that APIs are central to an effective chatbot strategy. To this end, I’ll begin by describing a common user interface that we’ve all encountered while surfing the Web, namely registering online for a service. I’ll then follow this example with one using a chatbot.
Web and Mobile Apps
We’ve all experienced searching google for a product or service. We click on a particular search result to visit the site and review its offerings, and ultimately select the service that fits us. The specifics vary from site to site, but the basic experience is familiar to all.
Consider the following signup page used by my company, Intwixt, to educate users about our offerings and ultimately guide them through the registration process (the values and prices are unimportant as we finalize our pricing and prepare for our public launch this Fall). This is where HTML and its document-oriented model really shines. Web pages with full-screen, side-by-side comparisons are an effective interface for educating users. Hyperlinks and buttons further augment the experience, allowing the user to drill down for additional information (such as clicking the INFO button). The Web app experience definitely has its strengths.
Once the user has reviewed the particular plan and is satisfied that it’s a fit, they can click TRY to register for the service.
A multi-step wizard then appears, walking the user stepwise through the process.
Once the user chooses a plan and agrees to the terms and conditions of the site, they are prompted for profile and contact information such as their name, email and phone.
Next, the user is prompted to confirm their email and phone by verifying the tokens that were sent to each account.
Finally, the user is prompted to enter their payment information and decide whether or not to pay upfront annually for a 10% discount.
Once the user clicks SUBMIT the wizard concludes by sharing a few links to help them get up and running and even prompts them to recommend Intwixt to friends in exchange for additional resources.
At Intwixt, we never create a UI without first designing the supporting API. This means that every aspect of the user registration and management process is backed by a set of well-defined APIs. Here are a handful, documented using the Open API format (a.k.a. Swagger). As we walk through the chatbot interface in the following screens, keep in mind that every message is backed by a call to one or more of the following APIs, just like the Web app shown above.
While there are many messaging platforms upon which to build a chatbot strategy (Slack, Telegram, Kik, etc), we decided to lead with Facebook Messenger given its enormous install base and rich capabilities.
Chatbots are relatively new to North American markets (our primary focus), so we felt it necessary to prompt users to switch contexts. We needed a way to entice them to engage our chatbot. To this end, we decided to add a banner to our existing signup page, offering a free, 7-day trial if the user registers using Messenger.
Once the user clicks the banner (or scans the image using their Messenger app), we engage them conversationally using our chatbot, beginning with a welcome message.
Because we already know several details about the user, including their first name, last name and Messenger PSID (Page-Scoped ID), the registration process is notably simplified. We begin by prompting the user for a password. This is one area where the core messaging interface is inappropriate given that passwords and sensitive information should never be displayed as part of the recorded conversation. Instead, when the user clicks Open, we launch a secure HTML page embedded within Messenger.
Upon clicking SUBMIT, the response goes directly to the Intwixt server, bypassing the main Messenger conversation.
With the password now captured (and hidden from view of the main conversation), we next prompt the user for their phone number.
Upon receiving the phone number we immediately text a security token to the user, and prompt them to echo it back to us to confirm that they do in fact control the stated number.
We repeat this process once again for their email address.
We conclude the registration process by welcoming the user and providing a link to the Intwixt Conversation Designer where they, too, can create conversational apps.
Keep the Conversation Going
The power of chatbots lies in the power of conversation. While the Web App surface captured billing details up front, its conversational counterpart allows us to distribute the interaction over time, using a long running conversation to reduce buyer friction. Why ask for everything upfront when you can gradually let the user self-select? Allow them the time to discover whether or not the platform is right for them.
In the following example the prospective customer has run out of credits during the free trial and asks for an extension. The chatbot, recognizing their unique Messenger PSID, checks their usage and then grants their request. (It never hurts to do a favor for a prospect.)
If the user grants our chatbot permission to contact them, it will attempt to engage them in a long-running conversation. A week later (as the extended trial is about to end), the chatbot reaches out to the user, asking them if they’d like to become a customer and continue using the service.
If the user chooses a plan, they’re prompted to open a secure, single-use form where they can enter their payment details.
After entering the relevant information, the user clicks AUTHORIZE to complete the transaction. (We use Stripe as the payment processor in this example, although any standard payment service can be supported, including Square and Braintree.)
Once the card is authorized in the background, the user is sent a thank you, letting them know the payment was processed successfully. They’re now an official customer!
Any time the customer has a question, they know where to turn. Everything from billing to account management can be handled by the chatbot. And what better way to care for a customer relationship than to keep the lines of communication open.
Chatbots represent a new and uncharted territory for IT decision makers. And we’re only just now beginning our journey. Usability is of utmost importance in software design and there are many aspects not fully understood as we learn when the conversational style is most appropriate and when it is not. For me personally, particularly as a software architect, the experience was eye-opening to say the least. While it took just shy of three weeks to create our Web app surface for the registration wizard (including wireframes, responsive layouts, color schemes, code, etc), the conversational chatbot was done in a day using our conversation designer.
For example, here is the subprocess that handles the 7-day, free trial. Those activities with the blue Messenger logo represent calls to the Facebook Messenger APIs, while those activities with the white Intwixt logo represent calls to the Intwixt APIs. (I’ve hidden error handling and sibling subprocesses such as payment processing for readability.)
As far as surfaces go, there is no question that the conversational surface (the chatbot) is the truest match to the underlying API I’ve witnessed to date. Said otherwise, you’re closer to the finish line than you ever imagined possible. Just look to your APIs for a glimpse of the future.