In 2016, Microsoft CEO Satya Nadella declared that “Bots are the new apps.”1 The world at the time was riding a wave of optimism around what chatbots would be able to do. It was clear that messaging applications were growing faster than social media, and users were suffering from app fatigue.2
Chatbots looked like the ideal way for companies to position themselves where users were (i.e., within messaging applications). In addition, since adding a chatbot was as simple as adding any other contact to your messaging app, it meant that you didn’t have to download and install something separate.
Others took this optimism further still, declaring that web sites were done for as well. Why have a web site when you can directly talk to a brand on Facebook Messenger? Chatbots were going to take over the world and nothing could stop them.
By 2018, people were singing a different tune. The impending takeover of chatbots did not quite go that way. Web sites were doing just fine, and so were applications on our phones. People had interacted enough with chatbots to realize that they were not that smart after all. Actually, quite a lot of chatbots where ineffective and would trip up at the slightest problem. What happened?
Well, chatbot technology, like any other technology, went through a natural cycle of maturity. The initial enthusiasm, necessary for anything to get any traction, met the harsh problems of the real world. People tried out different approaches because there were no established best practices yet. Just like those web sites of the late 1990s and early 2000s, we added the equivalent of blinking cursors and rotating GIFs. Everyone did things slightly differently, and users were trying to figure out what on earth was going on. Inevitably, people got disappointed and some dropped away.
At the same time, however, practitioners learned from their mistakes. Conferences and meetups took place and lessons were shared. Some made it through the dark times and the process starts over. This time, however, experience and redimensioned expectations can lead to more practical applications.
By 2019, chatbots were no longer considered the savior of all things digital. Far more sensibly, they were considered another useful tool to apply with due consideration. My experience with chatbots tracked this trajectory. I recall sitting down with Tim Deeson in 2016, my now cofounder at GreenShoot Labs, and discussing what technologies would be interesting to explore. Chatbots and conversational AI were at the top of my list. By 2017, we decided that it was time to do something practical. We started building some experimental chatbots to see what the technology was capable of and discussed the possibilities with clients.
What we learned over the next year is that although there was a lot of activity around consumer-facing chatbots, there was also a very interesting but less explored opportunity with enterprise chatbots: chatbots specifically built to help people within organizations to get work done. We went ahead and built a product for Slack, a bot called TeamChecklist that allowed users to store useful checklists and manage them as a team. Through that process we discovered just how many different applications of chatbots there were, but we also clarified our ideas about how we should think about the space.
Ultimately, the more interesting product we built was not TeamChecklist but the tool we used to build TeamChecklist! OpenDialog.ai is an open source conversation management platform. It expresses a very specific way of both designing and building chatbots. GreenShoot Labs eventually pivoted into a conversational AI consultancy that helps clients figure out what solutions are useful for their specific situation and, where required, uses OpenDialog.ai to implement those solutions.
- 1.
Conversations as their main interaction paradigm
- 2.
Conversational AI to provide users with a more natural way of exchanging messages
As with all the other chapters, I feel that clarity around concepts and the relationships between them is crucial in order to be able to plot an effective strategy.
From Chatbots to Conversational Applications
One of the problems of chatbots is that they suffer from a lack of a clear definition. At the core of this “identity” issue is the conflation of issues surrounding the use of artificial intelligence with a mode of interaction between humans and machine. When people try out something that responds “like a human,” the almost knee-jerk reaction is to test the limits of its capability to respond. Admit it. We’ve all messed around with Siri or Google Assistant: asked them questions they had no business being able to answer and giggled at their responses. This overlaying of different issues (how intelligent is it? what can I do with it? how does it interact with me?) can be distracting though. It is for these reasons that I prefer to call what we are building “conversational applications.” The use of the term application reminds people that we are trying to address a specific need, and it just so happens that the predominant mode of interaction is via a conversation.
A conversational application is one that is meant to operate within a conversational environment, such as Slack, where the predominant mode of interaction is the exchange of messages.
Using the term conversational application makes it clearer that we are attempting to build a tool to complete specific tasks, as opposed to a more consumer-facing chatbot that might be just as equally employed in simply entertaining the user with chit-chat. Broadly, it is the same distinction I would draw between more general web sites (e.g., a news web site or a social media web site) where the goals are more open-ended and more specific web applications like Xero for accounting or Google Docs for online document collaboration.
Structure of Conversational Applications
What makes up a conversational application? While we don’t want to delve into the specifics of implementing applications, it is useful to understand the environment within which we are operating. This will help you visualize how you could integrate conversational applications (both off-the-shelf and custom ones) into your own conversational collaboration platforms.
Elements of a conversational application
Central to it all is, of course, the bot itself. The bot is the identity that our application assumes in order to interact with users in a conversational platform. Just like every other user, it has a name, an avatar to represent it, and can provide presence information. It is, for all intents and purposes, another participant in our platform. Through the bot engine, the bot can interact with data sources and services in order to provide relevant information and carry out tasks.
Users can interact with bots either within groups (where multiple people can exchange messages and collaborate) or through direct 1-1 chats (where just a single user and the bot participate). If it is part of a group it can, depending on the granularity of settings for applications within a platform, “listen in” on all conversations happening in that channel just like any other member. This can be useful if the bot is meant to proactively participate in discussions, but if the bot is only supposed to provide information and reply when it is directly engaged, it is best to look for ways to limit the flow of information to the bot.
Keep in mind the security implications of allowing a bot to participate in channels where sensitive information may be shared. If a bot can listen in on everything, this means that necessarily all the information is flowing back to the bot engine. If that bot engine is a component that is internal to your organization, that may be OK or at least easier to manage. But what if that bot engine is actually an SaaS product? Who is the provider and what guarantees do you have that they will treat your data appropriately? You need to carefully consider what information you are potentially sharing with them and what the terms and conditions are that govern this.
Allowing a bot onto your conversational collaboration platform and giving it permission to listen in on all conversations is the same as allowing a stranger to walk into your office and listen in.
Having a bot in a channel can also be useful for a group of people to see the results of an interaction with a bot. For example, when someone asks for the latest sales numbers from a bot, everyone can see that report. Conversely, you need to consider whether that is too much noise for a team or simply not relevant. Often the route that conversational applications take is for notifications to arrive in a channel, while the execution of operations, actions, or the request for further information happens with 1-1 messages.3
Messages that the bot receives make it back to some sort of “bot engine” where reasoning will take place about how the bot should reply. Depending on the type of message, this is where we would be employing natural language processing to extract specific meaning from a user phrase and map that specific meaning to a response or action.
Open-ended vs. structured interactions
I have often found myself debating with people about the authenticity of a chat experience on the premise that structured exchanges, where people can press a button or select an option from a dropdown menu are considered inauthentic. “That’s not a proper chatbot; it’s just a glorified form experience,” the argument goes. While I can understand where that thinking is coming from, the first consideration must be the ease through which a user can flow through the interactions. If you can clarify options for a user with a couple of buttons, then that has to be the right thing to do. While we are taking advantage of the conversational nature of the interaction, we should not lose sight of the fact that we are in a richer digital environment and we have access to a wide range of options.
Interactions with a conversational application
The more socially oriented and open-ended the interactions are, the more “NLP” (in a very general sense) we will need to keep track of context and maintain a realistic dialog. A good example of such a bot is Microsoft’s Xiaoice bot.4 It operates within the Chinese WeChat platform and has over 660 million “friends.” It is specifically developed to be able to act as a companion and display empathy and social skills. The bot has a strong personality and will engage in conversation on any topic. It even has its own TV show!
Alternatively, we may have bots that do allow open-ended interactions, but the object is to support a specific task. Intercom’s AnswerBot would fit here. AnswerBot will allow users to type in any open-ended question, which it will try to answer (by diving into FAQs and articles it was provided). If it fails to get an answer, however, or if the user wants to ask a follow-on question on the same topic, it quickly hands over to a human. It will not try to keep a conversation going beyond that point. The aim is to ensure that interactions are either clearly useful or they should swiftly come to an end to allow a human to take over.
What sort of interactions will your conversational application need to support? To what extend do they need to be open-ended vs. structured? What is the bot attempting to achieve in general? In the next section I will present a simple set of considerations that allows you to map the various dimensions of your conversational application, and we will then go on to consider some specific examples of applications.
Planning for Conversational Applications
Considering a conversational application across different dimensions gives us a way of framing and scoping the problem. We can then better identify what methods and tools we will need to solve it. We’ll look at five different dimensions and the impact these can have on the application.
Capabilities
The first aspect to consider is what our conversational application needs to do. On one end of the scale we have applications that focus on a single task. For example, a bot that only helps us to approve or reject vacation requests. On the other end we can have applications that behave more like a Siri-like general assistant.
Specialized bots can narrow in on the range of possible interactions and provide more robust behavior. They can keep driving the user toward the appropriate outcome because there are only a few possibilities. More generic assistants, instead, have a challenge just in trying to understand what specific activity the user is trying to complete (as we’ve probably all experienced with something like Siri or Google Assistant when we wanted to play a song and instead it thought that we wanted to call a contact). The intelligent assistant approach is attractive when you can see more benefits from providing a single entry point, which is what makes them so popular with the large technology companies.
If you consider Alexa in this context, you can see its hybrid approach. The keyword Alexa wakes up the general assistant that then, based on what was said, will activate a specific skill. Once you are in a skill, however, you are interacting with a single bot that is potentially coming from a provider publishing their skills in the Alexa ecosystem—just like an app creator publishes an app on the Google Play store or the iOS store.
Interaction Style
As we discussed earlier, the interaction style of our conversational application can be quite important. Are we looking to support fully open-ended interactions? To what purpose? Is that helping our users to complete a specific task? If a user is trying to describe a complex problem, allowing them to describe that problem in an open-ended way can be amazingly powerful. It is the thing that differentiates conversational applications from glorified interactive voice response systems (IVRs). Everyone hates those because they are simply forcing us to navigate through an endless tree of choices. However, when our application needs specific answers and the user doesn’t actually have wide choices, pretending that they can interact in an open-ended way is as annoying. If the only thing a user can say is “yes” or “no,” it is pointless to make them think that the possible interactions are more open-ended.
Dealing with Complex Problem Descriptions
A conversational application we worked on at GreenShoot Labs had the task of helping victims of cybercrime to recover from the attack. The aim of the chatbot was to attempt to understand what type of attack the user experienced and, if successful, provide appropriate remedies. Initial designs of the conversational application centered on complex conversational flows wherein we were asking users a number of different questions to attempt to collect all the pieces of information we needed in order to identify the attack. All those approaches made the interactions too complicated for users. In the end, we decided to ask them to do the simplest thing: “Describe to us what happened.”
This way, the users can recount their story just as they would say it to anyone else, and the application then uses natural language processing and a knowledge graph of cyberattack information to identify the attack. It can also ask clarifying questions of the users if the attack type is not immediately clear. This way, the hard work is not passed back to the user by having them answer lots of different questions. Instead, it is the machine that needs to up its game and handle a more complex textual description.
The rest of the interactions with the application, which lead the user to the appropriate guide to deal with the attack and collect feedback, are all structured. By combining open-ended interactions where needed and structuring the rest of the conversation, we are able to keep a focused path through the application and ensure that the user is always clear about where they are in the process.
Context
Context is essential for automation. From a user experience perspective, if people feel that the application does not “get it” they will quickly abandon it. “Getting it” in this case involves making those connections that depend on contextual information and lessen the amount of information we have to explicitly input in an application.
Imagine having to use a car-sharing application in which you can’t simply plug in the destination; where you also need to explain where you are currently; and where you have no way of knowing whether the driver is on their way. Payment wouldn’t automatically happen. Yes, I realize that is exactly how taxis used to work! All the things that we enjoy about modern car-sharing applications are a result of that application using contextual information to make the task simpler for us.
If users are made to jump through hoops just because applications don’t have access to information that is considered readily available (e.g., calendar availability) they will, rightly so, not see the benefit in using a conversational application.
When talking about new products, especially in the context of startups, we often talk about minimum viable products. What is the minimum set of features that should be covered for the product to provide value to the user? When you are dealing with automating processes, you can transform that concept into a minimum viable automated process. How much of a process are you automating, and is that offering real value to the user?
For example, consider a conversational application that is supposed to help users find a common time to meet. The application does a great job going back and forth between users to find that time, but it does not integrate with the calendar in a way that it can actually create the meeting. The application is released and, to your disappointment, after some initial usage you find that people stopped interacting with it. Investigating further, you realize that the calendar app provides a less powerful but still useful way of comparing everyone’s calendar and finding an appropriate meeting time. Since people had to bring up the calendar app anyway to insert the meeting, they just preferred doing everything there.
As such, it is important to consider what the application will need to “know” or “do” is order for it to be able to really solve a problem and offer value. Thinking about the minimum viable automated process and the contextual needs of your application in order to achieve that can save considerable delays and disappointment further down the line.
Platforms
What conversational platforms will the conversational application need to operate on? Will it be just a single platform (e.g., just Slack), or do you require an application that is made available in multiple platforms that might potentially span voice, SMS, Slack, etc.?
You may need multiplatform support to reach more users or because you are bridging a gap between users on different platforms. For example, messages sent via SMS from customers can be piped into Slack for support workers to deal with and then sent back via SMS to the user. Teams that are mobile might be best served by a different application than teams that are in the office.
If you are considering an experience that will need to span or integrate platforms, you will need to consider how well conversations can translate across platforms. If parts of your team are on Slack but a new team that was merged in is still on Skype for Business, what will a single solution for both look like? Each platform enables different types of interactions, and it is up to the designer to find that minimum common denominator that is applicable across both.
Analytics and Improvement
No conversational application will get it right on the first day of launch. While analytics and ongoing improvement are strategically important for any application, they are particularly important when it comes to conversational applications.
There are two dimensions to consider here. First, are the types of “improvements” and “learning” the application might be doing automatically as it interacts with users. Are you confident that the behavior cannot be derailed and that there are checks and balances to allow real-time improvement to happen? Second, if you are planning to do offline review and further training (which is the case for most conversational applications), have you made sure your team will have the time and resources to do this?
I’ve seen successful deployments of chatbots forced to stop because there wasn’t the capability to maintain and monitor the interactions with them. Delegating decision-making to machines can free up resources, but it is best considered as an enhancement to the current team that allows it to scale as they move toward focusing on the harder cases and in maintaining the automated software.
Where to Use Conversational Applications
Now, let us start connecting everything that we’ve discussed so far by reviewing some examples of conversational applications and the implications of introducing such applications into your own conversational platforms. These examples illustrate both what people are already doing today and how that can be enhanced via further automation. These examples are a way to get you thinking about what you could develop and apply in your organization.
Just a note of caution: as we review interesting and fun features, keep in mind that we should not be enamored by the technological capabilities. At every step of the way the hardest question is not if something is possible. The hardest question is if something possible is worth doing. The most important thing to identify is what feature would bring most value to your users.
Notifications
Monitoring of key data
Support and collaboration
Intelligent Notifications
Yes, notifications are very likely the least favorite thing for any knowledge worker. There are too many of them, and I have yet to sit in a meeting where someone said they would like to receive more. Nevertheless, notifications are still necessary. Our challenge is, sadly, not to eliminate them but to determine how we can marshal notifications so that we get the most amount of useful information in the least distracting way possible.
The first part of a solution is setting up notifications in a way that we can more effectively control them. This can be achieved by fine-tuning what applications have the right to distract us and by making it easy to tweak settings to fit both our individual and team needs. The second part is to increasingly delegate the decision-making about whether a notification is useful or not (and when it is most useful) to software, so that it helps us be more efficient.
The first part of the challenge is something that conversational collaboration platforms can definitely help with. They are likely the first app we log in to in the morning, as well as the app that we can carry on all different work devices, mobile and not. True to their role as an organizational operating system, they can become the conduit through which all notifications get to us.
In addition, these environments provide us with tools to manage notifications in a variety of ways. One can set hours of the day where they should not be disturbed at all, as well as specific rules on a per-channel basis or based on keywords.
The second part of the challenge is the essence of this book: the use of AI techniques to delegate decision-making to software. In this case the decision-making we want to delegate is when and how we should be notified about something. In addition, it is worth exploring what else might be useful to have a conversational application provide in the context of notifications. One of the limitations of notifications is that it is hard to “action them.” We get told something but we are not provided with the tools to do something about it right there and then. With customized notifications, we can integrate the functionality that we need to perform actions as well.
Basic Notifications
The example we will use throughout this section is based on the Slack integration with Google Calendar. At the time of this writing it provided some key notification capabilities out of the box that already proved the value of basic notifications through conversational collaboration platforms.
The first thing a conversational application can do is notify you and allow you to take action directly from within the conversational environment. Through the Slack/Google Calendar integration, if a colleague creates a new meeting you will be notified and can choose to accept or reject the meeting through the notification. As meetings are about to start you can also be notified in Slack, and any relevant information, such as link to join an online video call, is provided in that same context.
Furthermore, since your conversational collaboration platform is where you also provide presence and overall status information for colleagues, the calendar integration edits your status and, as such, indirectly notifies others about whether you are in a meeting or not. This means colleagues can quickly see what you are up to, which can help them decide whether to send you a message or delay it, or whether it’s worth getting up and walking over to your desk or not.
Finally, the integration also sends a daily summary at the start of the day with all the events of the day. This means you can stop other applications and e-mail notifications doing the same.
These capabilities are basic and don’t involve much beyond usefully taking advantage of the environment and exposing the required functionality. Nevertheless, it is a fantastic starting point from which to go on to build more self-direction into the system.
Active Notifications
Attending a meeting requires a certain amount of preparation before the meeting from a number of different perspectives. How do you get there, who is attending, what is the agenda , what do you need to prepare before the meeting?
The calendar application can act as an active assistant that provides, within the context of the notification, useful information to help you get work done. It can provide travel information, highlight if a room or a location needs to be booked, and provide a checklist of tasks to do in advance.
In order for this functionality to be made possible, our application would need to be able to reason and understand about such things as the location of a meeting, the agenda, checking traffic reports, and more. It should be actively working (through a conversation) with users as they set up meetings, to ensure that it collects information such as the agenda and premeeting tasks. A simple question such as “Would you like to add an agenda for this meeting?” or “Is there anything attendees should prepare in advance?” can help people set up better meetings, help the meeting be more efficient, and establish cultural norms within the team (in this case around better meetings) that improve working life for everyone. A favorite of mine would be something along the lines of “Are you absolutely sure you need this meeting?”!
Team Notifications
Finally, since we are in a team collaboration environment, we can also consider how notifications could be best served if they went out to a team rather than single individuals. What if I could set up a meeting, but rather than mandate which specific people should attend I could request a specific role (e.g., someone from the user experience team, the development team, or finance to help us sort through specific issues)? The notification can then go out to the appropriate team channels and it is left to those teams to identify who is best suited to attend a meeting.
Of course, throughout you need to be thinking how the use of notifications works within the context of a specific organization and its culture and policies. Teams that have a culture of being active and accountable would have a better chance of being able to collectively react, while teams that are more individualistic and focused on their single tasks would not be a good fit for such a feature.
Monitoring Key Data
Tools to collect, collate, analyze, and compare data abound. It has never been easier to create charts and make them available in beautiful dashboards. However, as the chief marketing officer of a large multinational once told me “We’ve built them, but nobody is coming.” Nobody is looking at those beautiful dashboards or, if they are looking at them, there is no confidence in whether the various marketing teams are interpreting data in a consistent way. We have just built ourselves a more elaborate treadmill to run on, but we are still not getting anywhere. What teams need are tools that they can trust to let them know when something interesting has happened and, ideally, explain why that has happened.
Reports typically provide an updated chart or a straightforward piece of information such as “Visits to your site today are 20% more than average.” The interpretation of that data is left to the receiver of the notification. Why are visits up on the site? Which section of the site? Is it because a new paid ad campaign started? Is it because a newsletter was sent out? Did our product get a mention in the press? Is 20% above average usual when a marketing campaign kicks in? Should I be expecting more?
There are three obstacles that stop these tools from being more helpful. We need to connect data, contextualize data, and explain data.
Connected Data
First, the tools crunching data and generating reports simply don’t have access to all the pieces of information required so as to create a more complete narrative. At best, what happens is that someone will notice a change and a hunt will start across different groups and departments to attempt to understand why the change has happened. This generates questions, interrupts people who were performing other tasks, and can often lead nowhere.
To achieve richer narratives, multiple data sources need to be more tightly integrated and, crucially, the activities behind the generated data also need to be surfaced. For example, if you are building a product you should be able to see a timeline of how major releases connect to changes to your key performance indicators.
A path toward more useful activity data collection and integration is through the project management tools or technical code deployment tools. They can already broadcast their activities. If those messages are treated as activity data sources, you can start connecting key pieces of information through more careful overall knowledge management. Conversational applications can also assist by proactively reaching out to people and asking for that information, and identifying key moments that could be connected.
Now, don’t get me wrong. None of this is easy or simple. It will take effort to marshal the resources needed (not just financial) to put in places applications like this. We will discuss approaches in the upcoming chapters. For now, let’s enjoy the possible bright futures.
Contextual Data
We talked about notifications in the previous section and how it is so hard to get them under control. Notifications about key data and metrics is certainly one of the reasons we are inundated with information. There are so many metrics to follow, and we get hit with so many reports, that it all becomes a bit of a blur. The irony is that when we then actually need a piece of data, either because we are discussing next actions with a colleague or are planning activities for the next quarter or we just got asked by our boss about a report, we can’t find it.
Conversational applications can help by acting as our assistant to interact with business intelligence tools in order to provide us with the reports we need when we need them—namely, in the context of a conversation.
Requests such as “Can we see sales over the past 6 months for product Y” that lead to a report delivered in a group within out conversational collaboration platform for the entire team to see are within our grasp technologically. However, they require organizations to invest in identifying where they can best benefit from these opportunities. It is no surprise that large tech companies such as Microsoft are directly investing in adding conversational capabilities to their business intelligence tooling. Simply asking for the data we need when we need it in natural language is incredibly powerful and much better suited to how we work and think as humans.
Explainable Data
Finally, even if all the data was accessible and always not more than a few clicks or words away, we as humans are really bad at handling complex, interrelated pieces of data in our head. We are particularly bad at looking at different reports and effectively drawing the links between them.
Conversational applications can play a transformative role, acting as a more helpful interface through which we not only retrieve data but interrogate data. Rather than having to analyze charts to see what is going on, perhaps we should just ask the question:
“What happened today that was out of the norm?”
We could then follow that up with:
“Has this happened before?”
Instead of having to remember how to correlate information and build charts, we can ask:
“Can you compare this data to the same period last year?”
Organizations that are investing now in tooling to provide humane explanations are building the infrastructure for their future and setting themselves up with a significant competitive advantage. The use of natural language generation to provide narratives around data so that users don’t need to interpret complex charts and related figures can make access to information far more democratic across an organization.
To achieve these rich narratives, it will be necessary to combine data sources and also capture activities that influence data results in a consistent, coherent, and low-cost way. In Chapter 11, where we discuss AI strategy, we will delve deeper into what it takes to enable solutions such as the preceding one to develop. What could be useful at this point is a thought exercise for yourselves. What would it take to have all the necessary pieces of information in one place within your own organization? If you could construct clear narratives over sets of data (from marketing data to financial data and anything else you need to measure), how much time would that save in terms of having to go dig for the information?
Support and Collaboration
As we already discussed, integrations with conversational collaboration platforms can allow us to complete activities directly through the platform, saving us the need to change context. A simple, yet incredibly effective, demonstration comes with the Google Drive integration with Slack. When a user requests access to a document, the integration sends a notification via a dedicated bot. Within that same notification it allows you to select the level of access you want to give and approve the request. Previously, this action involved finding the notification within a heap of e-mails (provided one reviewed e-mail in a timely fashion) and then accessing the document in order to provide access. In most cases, the person requesting would have to message explicitly, as they were running out of time and needed the information urgently.
Our challenge, from an automation perspective, is to identify how to support more activities and streamline and automate specific junctions in those activities. We will look at three different examples to provide a sense of the level of automation possible.
Automated Helpdesk
With business to consumer interactions, conversational AI is most widely used for helpdesk support automation. There is a clear need, with people wanting support as quickly as possible at any time of day. There is also a clear return on investment, with support center costs reduced and the ability to increase the number of users served.
The same principles can apply to internal support across all levels of the organization: from IT questions—“what browsers do we support?,” “what is the Wi-Fi password?”—to HR questions—“what is our policy around sick days?,” “who do I contact about issues with colleagues?,” and so on. Putting in place a conversational application that acts as the first port of call for internal support means that the various teams can reduce the questions that come directly to them and instead focus on the more complicated cases.
Capturing Decisions and Completing Tasks
We converse so that we can explore a problem, share information, come to a decision, and then plan out how we will get work done. Conversational applications and deep integration between our conversational platforms and project management tools (Trello, Jira, Asana, in-house solutions, etc.) means that we can directly feed that information into the tools that manage tasks and vice-versa.
It can be as simple as being able to right-click on a message to convert that into a task (something that Slack already supports), or it can be a more sophisticated process where the conversational application proactively intervenes to create discussion summaries, identify key decision points, and capture tasks.
Capturing and Sharing Process Knowledge
Being able to capture single tasks and monitor their progress can be very beneficial. What is even more valuable from an organizational perspective is the ability to capture, share, and help enact multistep process knowledge. Any organization necessarily has a number of processes or, simply, “ways it get things done.” There is a lot of value in being able to create and curate these processes, even in something as simple as checklists.5
Conversational applications can be incredibly effective in helping us both capture processes, curate them over time, and share them more widely. Imagine a scenario where a new colleague is looking to organize a meeting with clients for the first time and is able to call up a checklist with the simple request “How do I organize a meeting with clients?” Then the colleague not only gets the necessary information (here is how you book a room, what to tell reception, how to order food and coffee) but also has an automated assistant that will work with them to contact the appropriate people (reception, room booking, security, etc.), send out reminders, and more.
Organizational Collaboration Operations
Conversational applications are the means through which we can connect to the rest of the world and extend our conversational collaboration platform with functionality that is specific to our needs. In this chapter we’ve discussed the range of issues to consider, as well as given examples of the types of application one could develop.
Something that each organization should now start considering more deeply is what processes they will put in place in order to constantly be thinking about how they can improve and extend their digital environment. Organizations that fail to do so will be less efficient and effective, and far more likely to lose their competitive advantage as a result.
It is quite easy to run a few pilots within any company that demonstrate how value could be created. It is much harder to do this in a consistent manner over time. There are at least two avenues to follow to tackle this challenge.
First, it is about creating a culture that supports constant introspection into how things are done and enables people to take issues into their own hands in order to improve the way they work. This is a bottom-up approach that is a crucial precondition to anything else. People have to be open and welcoming to change, and they have to be able to instigate change.
Second, the organization as a whole needs to ensure that it invests the necessary time and financial resources to provide people the space to implement change.
Inspiration can be drawn from the technical space, where investing in development operations (DevOps) is now a well-established practice. DevOps describes the processes that support development teams in creating code and releasing new features. It focuses on providing as smooth an experience as possible, since it recognizes that that will lead to better outcomes. Organizations need collaboration ops that focus on ensuring that people have the best possible experience when collaborating with each other. Investing in conversational collaboration platforms and conversational applications can be a significant aspect of that effort.