![]() ![]() Our services watch for failed dependencies and auto-heal once the failed services are back online. Self-healing: The bot has the ability to detect a failing service/API and escalate it to the respective DRI team, while providing an exceptional user experience to let them know of failing or failed services. Design considerations for bot implementation: The Finance Digital Assistant interface provides a simple and intuitive way for the user to interact with the service. A corresponding support ticket is auto-created for the user-bot conversation, allowing the agent to perform offline follow-up or post-call quality analysis.įigure 2. The live agent has the complete context of the user’s inquiry and can start the conversation when the bot fails to answer. Our objective is to make the support experience so seamless that users won’t be able to tell when they’re interacting with a bot or a support engineer.īy using cognitive-sentiment analysis to detect the user sentiment, we built a seamless experience to transfer the user to a live agent. Moreover, if the support bot can’t quickly resolve the issue, it will silently shift to a human supervisor who can interact with the user within the same support window. The Finance Digital Assistant (Figure 2) integrates into Procure to Pay services to monitor user activity and proactively offer guidance when deemed appropriate. To create this automation, our architecture incorporates a Procure to Pay support layer underneath all services. Microsoft LUIS (aka Language Understanding)Ī critical aspect of providing an end-to-end experience is automating the front- and back-office operations (such as support) as much as possible.The following technologies were used for implementation: Finance Digital Assistant architecture model is designed with scalability in mind and integration with many other vertical services. In addition, we defined an overarching End-to-End User Experience layer that created a singular, unified experience.įigure 1. Each service has a unique set of functionalities, presentation layer, APIs, and master data (Figure 1). Technical goals and implementationĪs part of this initiative, we are consolidating all 16 discrete services that make up our Procure to Pay platform. We had to consider how the power of conversation can eliminate or automate some process tasks, remove friction, and transform how we address customer needs and give them a memorable experience. Conversational AI enables a new model for engaging customers through fluid and frictionless conversations. Bots have the potential to change the way our business engages with customers we don’t think of a bot as something that simply replaces a human agent and works 24/7. Provide a seamless experience for users seeking information from a separate but related context.Determine the intent of the user, especially when multiple contexts or a wide range of user personas can be expected.We started with a few fundamental goals and objectives: It’s a challenge to create a truly conversational and interactive bot that’s able to seamlessly shift from one context to another and perform actions based on searching and on data. ![]() Our goal with bots is to simplify the user experience and provide important information with fewer clicks. Strategic approachĪ connected user experience is what our employees are looking for. The Procure to Pay process would focus on the end-to-end user experience and would replace the system-centric view of services. Ongoing efforts by Core Services Engineering and Operations (CSEO) to move toward a user-centric approach gave the Microsoft Finance Engineering team within CSEO an opportunity to rethink the Procure to Pay process by designing an AI-first, services-oriented architecture for it. This in turn slowed completion of every Procure to Pay instance, making the feature expensive to maintain. That forced users to learn to navigate and complete manual steps between certain apps, making the process even more cumbersome. Employees had to work within several apps-each with its own interface-to complete a task. The employee experience suffered because there wasn’t a single end-to-end process for Procure to Pay. These complex and unwieldly apps required significant resources to maintain. Without a unifying, overarching strategy, each of these apps evolved independently without considering user experience in what we call the Procure to Pay process. Each of these apps was in its own silo, often disconnected from each other. At Microsoft, many of our core business processes (such as procurement and payment) were built around a system-centric approach. ![]()
0 Comments
Leave a Reply. |