Companies of all stripes are getting bot happy, rolling out bots for third-party platforms like Facebook Messenger, Kik, WeChat, Slack, and more. Firms like Yahoo, H&M, KLM Airlines, and others use these chat bots — software built to simulate human conversation and to help consumers complete tasks — in an effort to better win, serve, and retain customers.
A few banking providers are beginning to dip their bank-shaped toes into the bot space: Capital One allows customers to take actions like paying bills via Alexa on Echo devices; Bank of America has announced plans to roll out a bot on Facebook Messenger; and numerous Chinese providers offer banking services via WeChat.
But while a few banks are in a position to experiment, digital business executives at most banks must decide whether to use precious resources to build or buy a chat bot offering. Forrester’s brand-new research report argues that most of these executives should hold off on launching chat bots for messaging platforms. This is because:
Today’s bots often lead to uneven — or worse — experiences for customers. In our research, we found many instances where a chat bot offered a quick and effective answer to a consumer’s question; however, about one-third of the time, existing chat bots either failed to complete the consumer’s request or provided a clunky, awkward experience.
As a preview of the report, here are two of our predictions for 2016:
APIs and open platforms will take center stage. APIs are becoming the most powerful technology in digital business design. Done right, APIs open new angles for business strategy. Financial services providers have been relatively slow to recognize and act on APIs as an opportunity to transform their businesses and, ultimately, better win, serve, and retain customers.* This will change in 2016, as digital executives collaborate with CIOs to champion big investments in internal, B2B, and product APIs. APIs won’t only help firms increase agility and provide services to clients and partners: They will enable financial firms to build dynamic ecosystems of value, reconnecting a fragmented value chain. They will be part of a wider, and longer-term, shift to open platforms as the foundation of digital financial services strategy.
Often considered the poster child of digital transformation, APIs are proliferating at enterprises making industry-leading investments in mobile, IoT, and big data. As these initiatives mature, CIOs, CTOs, and heads of development are coming together with business leaders to manage and secure companywide use of APIs using API management solutions.
Forrester recently released a report that sizes and projects annual spending on API management solutions. We predict US companies alone will spend nearly $3 billion on API management over the next five years. Annual spend will quadruple by the end of the decade, from $140 million in 2014 to $660 million in 2020. International sales will take the global market over the billion dollar mark.
In interviewing vendors for this piece of research, we discovered a vast and fertile landscape of participants:
Startups have taken $430 million in venture funding, and so far have realized $335 million in acquisition value. In April 2015, pure-play vendor Apigee went IPO and currently trades at a valuation north of $400 million.
The data economy — or the system that provides for the exchange of digitized information for the purpose of creating insights and value — grew in 2014, but in 2015 we’ll see it leap forward significantly. It will grow from a phenomenon that mainstream enterprises view at arm’s length as interesting to one that they embrace as a part of business as usual. The number of business and technology leaders telling us that external data is important to their business strategy has been growing rapidly -- from one-third in 2012 to almost half in 2014.
Why? It’s a supply-driven phenomenon made possible by widespread digitization, mobile technology, the Internet of Things (IoT), and Hadooponomics. With countless new data sources and powerful new tools to wrest insights from their depths, organizations will scramble to use them to know their customers better and to optimize their operations beyond anything they could have done before. And while the exploding data supply will spur demand, it will also spur additional supply. Firms will be taking a hard look at their “data exhaust” and wondering if there is a market for new products and services based on their unique set of data. But in many cases, the value in the data is not that people will be willing to pay money for bulk downloads or access to raw data, but in data products that complement a firm’s existing offerings.
Vendors across the board are building tools to add context-driven personalization features to mobile apps. Specifically, we see new offerings from vendors in personalization, mobile analytics, API management, predictive analytics, artificial intelligence, and the digital agencies for product and content recommendations, in-app messages, and voice-driven digital assistance.
Marketers and developers are jumping at these solutions because creating more personalized digital experiences will be critical to remaining competitive. And as CIOs rationalize a larger software platform strategy, these solutions will plug specific mobile engagement gaps along the way.
Want to hear more? In our new brief, Vendors Scramble To Enable Contextual Mobile Moments,we examine how different groups of vendors extend their capabilities to compete in the arms race to deliver contextual mobile apps and provide guidance for CIOs on managing the myriad solutions entering their organization.
As I move about the industry talking about APIs (application programming interfaces) and the API economy — which hold important and transformative business opportunities — I’m frequently confronted with disparaging remarks about SOA (service-oriented architecture), as if it’s passé, gone, finito. It’s often in the way of (uninformed) assumptions about SOA. I hear things like, “SOA failed because it was too difficult” or “People do REST APIs now, they don’t do SOA” or other such bunk.
I’ll be the first to extol the importance and benefits of APIs, but the tales of SOA’s failure and demise are simply wrong (I really do like APIs; see this report). I had a powerful reminder of all this while attending IBM’s IMPACT conference this week. First off, I arrived late to one customer’s plain-vanilla “this is our enterprise SOA journey” session only to be refused entry because the room was over capacity. Glancing over the conference program, there were at least eight such sessions representing four continents and at least five vertical industries. I attended five of them and also had lunch with another SOA leader. The stories could all be summarized by the following plot line:
We saw the value in SOA. Whether the need was multichannel customer engagement, faster time-to-market, retiring legacy, getting past complex and costly point-to-point integration, dealing with duplicate applications, or some other business-technology problem, a core team recognized that SOA could make things better.
Many of us in the information security space have a proud legacy of only purchasing best in breed point solutions. In my early days as an information security practitioner, I only wanted to deploy these types of standalone solutions. One of the problems with this approach is that it results in a bloated security portfolio with little integration between security controls. This bloat adds unneeded friction to the infosec team’s operational responsibilities. We talk about adding friction to make the attacker’s job more difficult, what about this self-imposed friction? S&R pros jobs are hard enough. I’m not suggesting that you eliminate best in breed solutions from consideration, I’m suggesting that any “point solution” that functions in isolation and adds unneeded operational friction shouldn’t be considered.
Open Web developers tend to use a variation of the façade pattern for their applications but refine the pattern to focus on standard web formats and protocols and services delivered via the Web — so we refer to it as the open Web façade. Developers draw on three bodies of de jure and de facto standards to implement the open Web façade pattern:
Client standards. Application clients based on a body of emerging standards collectively labeled HTML5.
Service plane standards. A service plane that exposes interfaces using the REST pattern and resource-oriented architecture principles. These services are often called RESTful web services.
Virtual infrastructure standards. A highly virtualized server tier (often a public cloud service) that is easy to deploy initial solutions to but that is also able to scale up or down on demand to meet surges in capacity.