Cognigy CEO and Co-Founder Philipp Heltewig was recently a guest on Mobile Interactions Now, a podcast hosted by Jean Shin, Director of Strategy & Content for our technology partner tyntec. 

In part 2 of Mobile Interactions Now , Philipp takes us through the front and backend of Cognigy's renowned enterprise-grade AI platform: Cognigy.AI. He also helps listeners with what it takes to provide fast and frictionless customer interactions that go beyond basic FAQ use cases.

Did you miss part 1? Listen here!

 

Listen to part 2 of the podcast here:

 

Transcript:

Jean: Welcome back to the show Phil. In our previous episode, we talked more about the end user experience, me complaining about some of those experiences and how businesses can think about it. And throughout the whole episode, I was keep thinking, "Okay, I know how to put together a dinner party. I know what goes into making a good conversation, meaning you’ve got to have some kind of sitting arrangement. Who's going to talk with whom." And you sort of have these plans, what to serve, in what group, what topic to start with, what topic not to start with. You sort of know how to make a good engaging conversation, like a little dinner party that we all like. This time I really want to peel back the layer a little bit, what really goes into, even in the backroom, to make these interactions we talked about.

OK, we shouldn’t think of it as a human interaction, but at least a satisfying interaction. I came here to get this done and I got it done and I'm happy. Let's talk really about what goes into making that happen. I'm not shy about saying this, I'm rather impatient. But I love when service agents help me really quickly get to what I want to get to. So tell me, what goes into, a little bit on the back end, what really needs to happen with a conversational automation to provide that experience?

Phil: I think you mentioned something important that I also alluded to in our last session, which is that, what's important here is that you were helped fast and frictionless. You got service fast, your problem was solved quickly for you. And it's great if a human can do that but I think a lot of customers don't care whether it is a human or a bot, as long as they can get the help they need quickly and without hassle. Now, the requirements for a cognitive bot, actually, rather similar to the ones for a human agent, which is access to data, access to backend systems. Because let's say you're calling a call center, you're speaking with a human agent and you have a question about the order that you placed last week, and you want to follow up on that order. Well, if that agent doesn't have a kind of interface to look into the ordering system, then they won't be able to answer your question.

And it is very similar for a cognitive bot. If you're coming in and you say, "Well, I have a question about my order." The bot understands, okay, you have an order question and you haven't given me an order number so I'm going to ask you for one. You provide the order number. Now, if the bot doesn't have access to the older system, they have to make something up. And that is not helpful. So what they need, is they need the means to access the systems that contain the data that you a querying about. So in this case, it would mostly be an API, like a programming interface to interact with that ordering system. Now, what bots actually do quite a bit is they ask you, how can I help you? And you are providing a sentence in human language in any language that you might speak and the bot then assigns meaning to that.

So for example, if I say, I have a question about my last order, the bot understands, okay, this is a order status request, for example. And now the bot tries to gather all the bits and pieces it needs in order for them to be able to answer my question, just like a human agent work. If I said to a human agent, I have a question about my last order. He or she might say, "Okay, what's your order number." Or if I'm already authenticated, because I called in and they can somehow see my phone number, that's also, by the way, then a backend connection. Where they can correlate my phone number in a CRM system, for example. They could say something like, "Oh, is this about the order from last week which hasn't been delivered yet." And a bot can do a very similar thing if they have excess to the same data, usually using APIs on the back end.

That's the kind of connectivity that is required in order for a bot to be smarter than what we call an FAQ. A lot of bots in the early days were so-called FAQs. You have FAQs is on your website, frequently asked questions. And you have an FAQ that has 100 questions and 100 answers. Now, for example, where can I track my order status? That's a typical FAQ question, and then the answer is something like, you can track that status on our order status page, and then there is a link to it. That's what you have on your website. Now, what a lot of companies in the early days with chatbots did, they just took these FAQs and pulled them into the bot. And now if I say to the bot, "Hey, what's my order status?" It's going to say, "You can track your order status at this and that page."

Now that's somewhat helpful. I could have also found that out on the website, I guess. I'm essentially just using the bot as a search engine. But wouldn't it be much better if the bot then had an interaction with me saying, "Oh yeah, sure, I can help you with your order status what your order ID?" And then I give it the order ID and so on and so forth. So that's what we call an end to end automation. And in order to do that, you need to have access to the systems that actually have that information in them.

Jean: Is there a nice average number of systems your bots touch to make this happen somehow?

Phil: Well, it really depends on the bot ride. I mean, most bots are not integrated with more than two or three systems at the same time, because again, they usually have a relatively narrow purpose. If I have a bot that works in customer service for an insurance company, then it's maybe the claim system. And maybe it's a CRM system where I have information about my customers and maybe that's it.

And if I work in retail, then maybe it's my e-commerce system. And again, it's a CRM system or an ERP system of some sort. There is of course the big enterprise software companies that provide a lot of that functionality like Microsoft, like Salesforce, like Oracle, like SAP, and if you have connectors to those, then you're already covering a large part of the requirements, a large part of the projects and all of the integrations that actually need to be built. But of course, sometimes there's also very exotic systems that are very use case specific that we've never heard about, but of course, you need to have the ability to integrate with anyways. And most of the time these systems have standard APIs as well.

Jean: Let me just get a little deeper. Take us through some of it because I heard about some exciting things about Cognigy in terms of natural language processing prowess and things like this. Because I think the market is getting bigger in a way. The whole conversational AI, the space is becoming a thing. It used to be like, "What are you talking about?" And I was very impressed that there are actually now some figures and market size data out there and it is becoming a real space. From business point of view, it's hard to understand the differences. And if you were to kinda go through your own platform and what's different from let's say, Google platform and other platforms, can you just give us a little bit of how to think about this, evaluate even?

Phil: You're right. The market is getting bigger and as such, you have a lot more entrance into the market as well that are trying to serve customers and that are calling themselves a conversational AI platforms, conversational automation platforms. We've been in the market for a number of years now. And we've always solely been focused on enterprise. And we come from an enterprise background as well. Most of us have worked for large enterprise software companies in the past. And as such, we understand the requirements that enterprise have or enterprises around the world have for a system like Cognigy or a conversational automation system. Because you have to see the data that is flowing through our system can be highly sensitive. It's PII data, if it's governmental data. When you talk with these bots, you are giving up a lot of privacy related data that you really don't want to get out.

And so a part of being enterprise grade is I guess, being compliant to GDPR and not just compliant, but enabling our customers to stay compliant as well. There's questions that come up with, "Okay. How long does the the brain memory that a bot has?" So a bot has a short term memory of the conversation that we're currently having in order to facilitate better conversations. How long does that survive? Does that live for an hour? Does it live for 24 hours? What about persistent information we've saved? Can a customer come to my enterprise and demand all the chat data we have on them. And the answer is yes, they have to be able to provide that kind of data, because this is one of the compliance requirements under GDPR. Then there is things like security, encryption, single sign-on integration with authentication systems in the enterprise and so on.

And if you look at it from that perspective, the market becomes a lot narrower. There's really only a handful of vendors in the market that can take all of those boxes. The boxes of being able to integrate with any enterprise system there is without having to come back to the vendor. Boxes of scalability. I mean, we have customers that at one moment might have 100 people conversing with a bot. And at the next moment, might have thousands of people conversing with a bot at the same time. So the solution must be very scalable in that sense. The security tick box and the compliance tick boxes.

If you look at it from that perspective, there are really not a lot of vendors on the market, especially when you look at a requirement that is coming up more and more often, which is the ability to run on dedicated hardware. Meaning, to pull the whole platform essentially on premise or on their own cloud infrastructure so that no data leaks out. This for example, is one of the reasons why a lot of European companies are stopping working with Google Dialogflow, which is Google's natural language understanding offering, because Google can not guarantee that the data is staying in the European union.

They are then moving to other solutions, like for example, Cognigy. Now, if you were to ask me to name the companies that actually comply to all of these things that I've just mentioned, I would not mention the large platforms like a Microsoft LUIS, Google Dialogflow, IBM Watson, and so on because they are only really delivering a part of the solution. And you might ask, what part is that? So I need to explain first, what are the parts that make up an end to end conversational AI platform. On the front-end you have what we call channel connectors, because the customer sits on a channel. A channel can be WhatsApp, channel can be Facebook messenger, a channel can be Microsoft teams, a channel can be phone call. Now, every one of these channels uses different formats and when the data comes in, the system somehow needs to understand these formats in order to continue working with the data from that channel.

So you need those channel connectors. That's the first of three pieces you need. The second piece, is the natural language understanding. So that's the AI component that assigns meaning to what the customer has said. So for example, if I say, I need a bank statement from the 3rd of January, 2020 to the 17th of February, 2020, that sentence has a lot of information in it. And the natural language understanding is able to comprehend that meaning. It's like a bank statement request, and it has a starting date and an end date in it. With that information, I can then go into a backend system and retrieve that bank statement. So that's the natural language understanding component, which is the second.

And the third component is the conversation logic. Now that I have understood, it's a bank statement request, and I have a start and an end date, what do I do now? What if someone only made a bank statement request, and I only have a stop date, do I just assume the end date is now? Or do I ask back, is this until now or do you want to specify different end date for your bank statement? So that's what the conversation logic does. It determines what do we say back to the user and do we interact with backend systems in the meantime. For example, if I already have all the information for the bank statement, I could pull that information and let's say, I get a PDF link back, and then I can provide that instantly to the user going like, "Oh yeah, he has your bank statement, click for a download." So again, the three components are the channel connectors, the natural language understanding that actually analyzes and assigns meaning and the conversation logic that then that then determines what we answer back.

Now, the big systems like Microsoft LUIS or Google Dialogflow, they only offer limited channel connectors. They all offer really good NLU and they all offer very limited conversation logic, if any. Some of them don't offer any conversation logic, or you have to write a lot of code, programming code, in order to get anything done. Now, a system like Cognigy, uses a low code approach for the conversation logic, because we believe that the knowledge about the process that you want to automate, does not sit inside the IT department. If you are automating processes in customer service, then you need to have people from customer service build out these processes and not a developer that codes them. And if a change needs to be made, then everyone needs to go back to the developers to change it. Whereas in Cognigy, they can just go in and change it themselves.

So we are using a little bit of a different approach shifting the ownership of the conversational solution directly into the customer service department, all the respective department that is building a bot. So summarized, Cognigy is an end to end solution that has all three components, the channel connectors, the native NLU, so we have Cognigy NLU, which can be plucked in and out for other NLUs as well. And the conversation logic and all of this can run completely disconnected end to end on a dedicated infrastructure, or it can be consumed on SAS as well, if you want, but that's what truly makes an enterprise solution. And of those, there are only very few on the market.

Jean: Thanks for clarifying those differences because somehow, the general tech industry made this whole natural language processing part such a stand in for AI in general and how accurate a chatbot conversation is, making it like a sport. Who is doing it better? And people are talking about this, but those layers involved really help, but it's not as easy. I think it does require some understanding of the landscape of what's doing what and how to put it together because you do have to work with the larger IT structure, the enterprise side. In your experience, because in tech industry it is really super helpful to have somebody inside championing it, adoption is kind of painful sometimes, so in your case, who are some of the champions who are making this possible to bring you in and start integrating it system wide?

Phil: Yeah. It's interesting and it has also evolved and changed over the past couple of years. When we started Cognigy in in 2016, hardly anyone had ever heard of conversational AI or conversational automation, everyone was thinking about a Siri as being conversational AI and chatbots are fun on Facebook and you can have small talk with them and so on. So at that time, conversationally AI really only started entering the minds of people in the enterprise. And oftentimes, it was either techies that wanted to play around a little bit, or innovation managers that are like technical scouts that are always on the lookout for the next big thing and how they can then take this and apply it at their enterprise. Now, this has changed significantly over the past couple of years, also probably, partially due to the emergence of robotic process automation we now have essentially two different personas we're working with.

One is what we call the automation hero. Because automation in general has seen a massive uptake inside large enterprises. And those that have previously focused on RPA, are now starting to focus more and more on conversational automation. This is definitely one of the groups that we are working with a lot these days, people that have experience in automation technologies, whether that's RPA or also some previous experience by dabbling around with a Google Dialogflow or something like that and now want to take the next step of really applying this in the enterprise.

And the second one, the second group of people in the enterprise we're interacting with, come from the contact center space. And it's not usually the contact center managers, but it's more the contact center technical VPs. Because contact centers are rather technical operations anyways. Of course, you have a lot of human capital in there. You have a lot of agents, but you also have quite involved IT systems in the contact centers already. The likes of Genesis or Avaya, RingCentral, audio quotes equipment. Different types of technologies that are already in place and the people dealing with those types of technologies are now turning towards the conversational AI and conversational automation technologies championing the introduction of those technologies in the enterprise to reap the benefits in terms of ROI cost savings that we've discussed in the last session.

Jean: That helps me to see it from their angle, what they are looking at. And I think the conversation we had in our previous episode kinda works within that framework as well. The whole ROI discussion and the backend and related systems it's connected to. One more thing, this could be my last question. I'm wondering, let's see, the technical capability is progressing fast and the consumer experience is accumulating now. I mean, it's not hard to find somebody who interacted with conversational automation now, not as novel as before. So let's say this is becoming more common discussion in enterprise business meetings. If you were to give them helpful tips, how to begin to have this conversation, how to get started and how to get really serious about it. What would you say?

Phil: Well, maybe a couple of points, I guess, if you want to get started with conversational AI technology, the first thing I would say is just get started. You don't need to be scared of the technology or think that your own technical skills might not be sufficient. Just sign up for a platform of your choice. You can sign up for ours on the website or any other. Play around with it. Contrary to common belief, many tools out there now let nontechnical users build very advanced bots actually, without needing any development skills. Well, we just had a case, for example, with one of the major airlines here in the region where a manager builds a whole bot while being confined to the home office due to the crisis, and he had never programmed before. It's really a lot easier than you might think.

And I think it's also very satisfying. Actually building something that you can then speak with. It's actually the reason why we started the company in the first place. We're a big sci-fi fans and we thought, "Okay, let's do something really cool." And I still love it. I mean, I build bots at times in our platform, and I think it's a very satisfying experience. Maybe as an overarching theme, I would say, well, just get started. But if you want some more concrete tips, I would say, pick your use case well. Because you're going to just get started and play around and that's fine. And you can build a bot that pulls the cafeteria menu and like this. And it's a nice to have, and it's cool to show your friends and you are going to love it, but your boss is not going to love it.

He'll say, eventually, he or she, and then higher up in the hierarchy will say, "Okay, so how can we apply this, what's the ROI." Pick your use case well. That the use case that you are then going to parade around the enterprise and look at the ROI. Look towards the customer service department in your organization if you can. Now, the other thing I would say is don't start too small. Pick a bot that can deliver actual value. And it's not just an FAQ. FAQ, they are nice. I don't know why, but almost everyone starting with an FAQ. We want to build an FAQ bot. You go like, "Well, why do you want to build an FAQ bot?" It's like, "Because we already have the FAQs." Great. But you can build an FAQ bot maybe to start with, and then you take one of the questions and you're fully end to end automate that.

So maybe the question, where can I check my order status that then no longer leads to a website. So the bot no longer just gives you the URL, but you automate that one end to end by integrating with API. Don't start too small. Don't make an FAQ bot your goal, that should not be the goal. But don't start too big either. We have seen customers that say, "This technology is great. We've done the training. It's so easy to use. We're going to automate everything. We're going to build a bot that can answer any question and automate everything. And we have mapped out these 80 journeys, and now we're going to build them." I can tell you these projects hardly ever succeed. Don't start with 50 things your bot can do. Pick your top five things, maybe three things, and start on those. For all the others, send the people where you're sending them now, to the FAQ page, to an email, to a human agent. Automate the top three things.

Now think about this, say you're building a voice bot. And do you want to automate some queries that are coming in and you figure out, "Okay, half of my queries that are coming in are about finding the closest location of a supermarket." Let's just say. Now you automate just that one case. In total, there's 100 cases, but you're only automating that one. Now all of a sudden you've automated 50% of all the queries. So if you take the top five, well, let's say top 10 features, you can automate upwards of 80% of the queries that are coming in. So don't start too big by trying to automate everything, pick a couple and iteratively, add more features to the bot afterwards. And maybe last but not least, this is something that you just mentioned but that's why I would like to pick it up.

The natural language understanding. You said that natural language understanding technology is kind of a stand in for AI in general. And I think it's because it's very relatable. Yeah, sure their is AI that analyzes when a component in a certain machinery will fail and that's not that relatable. A natural language understanding somehow personifies AI and makes us able to interact with it. And I think this is why there's a lot of focus on that. But I'm saying, don't just focus on the NLU. The NLU is but one piece of a successful board experience. And the way you can think about it is, the NLU only understands what you're saying, okay? So let's say I have a bank, and in this bank I have an employee and he understands all the customer questions. And then he does something to actually help the customers. Now let's say, I don't have a bank, the bank is my channel. I don't have a channel. I only have this guy. He stands there, he understands every question you ask, but he doesn't know what to do then. That's pretty useless.

Now, if you have a guy who sits in the bank, which is this channel and you go there, he understands every question you ask. And he can then actually action that as well, which is the conversational logic. Then, you actually have a very well-working system that provides good service. And it's the same here. You need the proper channel that your customers are using. You need a well functioning natural language understanding. It doesn't need to be perfect. Don't spend an extra six months getting extra 2% performance out of the NLU. Spent that on conversational design. Your return is going to be much higher. And then you need to have that conversational design, that conversational logic that actually can action those understandings that NLU gives it.

Only if the three pieces work in unison and work very well, then you're going to get somewhere. There's way too much focus on performance of NLU in the market, as you are saying. And I believe there should be a lot more focus on good conversational design. How do we guide the user? How do we get them back on track? How do we get the user to feel that they have received fast and frictionless service. That's what we should really care about because that's what conversational AI is really all about.

Jean: I love the conversational logic part of it. Are you saying that an average business person can actually play in a visual way to redesign the logic and change the action? The person can actually redesign it, like a workflow, changing it visually, is that where we at?

Phil: That's where we're at. We have a lot of business users. I mean, we are training business users on a weekly basis that can then go. They can not just redesign the logic, they can also redesign the NLU. They can review the sentences that have been said by users that were not understood, can assign the meaning, retrain the artificial intelligence models with a click of a button. So there's no rocket science to that. If you can use Excel, then you can use that as well.

Same in the conversational logic, you can go in and change texts and images and move things around similar to a content management system of sorts. Of course, if you need to interface with the API off your SAP HRM system, then that might require someone a bit more technical minded. But that is, I guess, always the case, if you building interfaces between systems. But more general tasks, as I said, improving the natural language understanding, changing the flow of a conversation, changing the content that comes out that is shown and so on. These are things that don't require any development skills anymore when using the right tool set.

Jean: I'll take that as a wrap. That was perfect. Thank you very much.

Phil: Yeah. Thank you very much.

Jean: But I almost lied. There's a little segment that we play, before I let you go. And this is getting a little personal. Feel free to be totally 100% honest. What are the three things you use the most on your phone?

Phil: Oh, that's interesting. So I'm using my phone mostly for two things. First being communication, and the second being photos. I mean, if you have kids then you probably know you're taking a load of photos and videos. So I guess the photos app is the one that I'm using almost the most and then closely followed by WhatsApp for messaging. And I'm also using line messenger quite a lot because my wife uses a line messenger. Those are the ones I'm using most.

Jean: That was fun. Thanks again. Actually, if you want our audience to follow your work, what you'll be doing next, or what you are doing at Cognigy, is there a place you want to point them to?

Phil: I guess the easiest will be just to go to the website and then if you go to the bottom, we are present on various social channels, LinkedIn, Facebook. We have a newsletter as well. We have a community and really, if you want to just give it a go, come to the website, click on, start your free trial on the upper right and you'll get your login data within a very short time frame and then you can just play around and build your own conversational bots and you can have some fun with that.

Jean: Thanks again.

Phil: Thank you very much.

 

About tyntec

tyntec is a cloud communications provider enabling businesses to communicate easier with their customers, workforce and machines. tyntec has built its global connectivity from the ground up and developed cloud APIs on top to provide the full advantage of cloud communications on a global scale. Building on its heritage of tier-one global SMS messaging provider, tyntec continues to advance how today’s enterprises utilize the universal services of messaging, voice and phone numbers to connect and perform transactions with people around the world.

More information on www.tyntec.com

 
image119-1
image119-1
image119-1