Apigee best practices for Contact Center AI

By now, you’ve probably interacted with a customer service chatbot at some point. However, many of those interactions may have left a lot to be desired. Modern consumers generally expect more than a simple bot that answers questions with predefined answers—they expect a virtual agent that can solve their problems.Google Cloud Contact Center AI (CCAI) can make it easier for organizations to efficiently support their end customers with natural interactions delivered through AI-powered conversation. In this guide, we’ll share seven Apigee best practices for building fast, effective chatbots with secure APIs using CCAIand Apigee API Management.This blog post assumes you have basic knowledge of CCAI and Apigee API Management.Good conversation is challengingOne of the many challenges organizations face is how to provide a bot experience to customers when information resides in more places than ever. Creating an optimal virtual agent generally involves integrating with both new and legacy systems that are spread out across a mix of on-premises and cloud environments, using REST APIs.Dialogflow CX is a natural language processing module of CCAI that translates text or audio from a conversation into structured data. A powerful feature of Dialogflow CX is webhook fulfillments to connect with backend systems. Once a virtual agent triggers a webhook, Dialogflow CX connects to backend APIs, consumes the responses, and stores required information in its context. This integration can allow virtual agents to have more informed and purposeful interactions with end users, such as verifying store hours, determining whether a particular item is in stock, and checking the status of an order.Developing APIs for CCAI fulfillment is not a straightforward task. There can be many challenges associated with it, including:Complexity: You may need to access APIs that are not exposed externally, which can require significant collaboration and rules to enable access to existing data and systems. This can easily lead to technical debt and more inefficiency without an API Gateway that can translate the complexities of data systems in real time and forward them to a customer.Increased customer frustration: Contact centers often act as one of the primary drivers of customer experience. Improving the speed of response can enhance experiences, but any friction or delays can be magnified. Caching and prefetching data are some commonly used flows to enable faster virtual agent responses. API Orchestration: APIs generally require more than just exposing an endpoint as they need to change often in response to customer needs. This flexibility can require API orchestration, where APIs are decoupled from rigid services and integrated into an interface tailored to the expected consumption patterns and security requirements of interacting with Dialogflow CX. Without an API platform, translating complexities of data systems in realtime and forwarding to the caller is not efficient.How Dialogflow and Apigee deliver better chatbot experiencesCCAI can be more effective when woven into the fabric of the business via APIs. The more functionality (and therefore more APIs) you add to the agent, the more critical it can become to streamline the API onboarding process. You need to consolidate repetitive work, validate security postures, and identify and implement optimizations to ensure a great end user experience.Apigee API Management can pave the way for faster and easier fulfillment. Apigee is an intuitive platform for bot designers and architects to incorporate key business processes and insights into their workflow. More specifically, it enables Dialogflow to speak with your backend systems. You can use Apigee’s built-in policies to inspect Dialogflow requests, set responses, validate defined parameters, and trigger events in real time. For example, if a call meets a defined business criteria, Apigee can augment a “360 degree view” in a data warehouse like BigQuery, add a customer to a campaign list, or send a SMS/text alert—all without any material impact on the routing time. By pairing CCAI with Apigee, you can leverage a greater portion of Google Cloud’s transformation toolset, reduce the amount of time needed for conversation architects to integrate APIs, and create a more cohesive development environment for solving call center challenges.Seven ways to get more out of Contact Center AI API development with ApigeeThe following are several best practices for Apigee API development for Dialogflow CX API fulfillments:1. Create a single common Apigee API proxy Let’s assume we have a Dialogflow CX virtual agent that needs three fulfillment APIs that will be fronted by Apigee:get list of moviesadd movie ticket to cartorder item in cartTechnically, you can create a separate Dialogflow CX webhook for each of these APIs, which can point to three separate API proxies. However, because Dialogflow has a proprietary request and response format, creating three separate API proxies for those fulfillment APIs results in three non-RESTful proxies that are difficult to consume for any clients other than Dialogflow CX virtual agents.Instead, we recommend creating a common Apigee API proxy that is responsible for handling all the fulfillment APIs required by the agent. Dialogflow CX will have just one webhook that is configured to send requests to the common Apigee API proxy. Each webhook call is sent with a webhook tag that uniquely identifies the correct fulfillment API.2. Leverage Dialogflow policies as much as possibleApigee provides two Dialogflow-specific policies: ParseDialogflowRequest and SetDialogflowResponse. It is highly recommended to use these policies whenever possible. Doing so not only adheres to the general best practice of choosing built-in policies first over custom code, but also ensures that parsing and setting of Dialogflow request and response is standardized, hardened, and performant.As a general rule:ParseDialogflowRequest is required only once in an API proxy and placed in the PreFlow after authentication has taken place.SetDialogflowResponse may be used for each distinct fulfillment response (i.e., for each unique webhook tag). If the SetDialogflowResponse does not meet all of the requirements, either supplement or replace it with AssignMessage or JavaScript policies.3. Use conditional flows for each webhook tagConditional flows should be used to separate the logic for different fulfillment APIs. The easiest way to implement this is by placing a ParseDialogflowRequest policy in the PreFlow. Once that policy has been added, the flow variable google.dialogflow.<optional-prefix>.fulfillment.tag will be populated with the value of the webhook tag. This variable can then be used to define the conditions in which a request enters a particular conditional flow.Here is an example of a conditional flow using the same three fulfillment APIs from above:4. Consider utilizing proxy chainingDialogflow CX webhooks have their own request and response format instead of following RESTful conventions such as GET for reads, POST for creates, PUT for updates, etc. This makes it difficult for conventional clients to easily consume an API Proxy created for DIalogflow CX.Hence we recommend using proxy chaining. With proxy chaining you can separate API proxies into two categories: Dialogflow proxies and resource proxies. Dialogflow proxies can be lightweight proxies limited to actions specific to the Dialogflow client. These might include:Authenticating requestsTranslating a Dialogflow CX request into a RESTful formatSending a RESTful request to the resource proxyTranslating the response back from the resource proxy into the Dialogflow formatAnd any tasks that involve connecting to the backend and exchanging data should fall to your resource proxies. You should create resource proxies just like any other Apigee API proxy, without considerations for Dialogflow in mind. The focus should be on providing an eloquent, RESTful interface for all types of clients to easily consume.Proxy chaining provides a way to reuse proxies. However, it can incur some additional overhead as the call moves from one proxy to another. Another approach you can use is to develop components that are expressly designed to be reused, using Reusable shared flows. Shared flows combine policies and resources together and can be abstracted into shared libraries, allowing you to capture functionality that can be consumed in multiple places. They also let security teams standardize on approach and rules for connectivity to trusted systems, assuring security compliance without compromising the rate of innovation. Proxies you want to connect in this way must be in the same organization and environment.5. Improve performance with cache prefetchingWhen creating a chatbot or any other natural language understanding-enhanced application, response latency is an important metric — the time it takes for a bot to respond back to the user. Minimizing this latency helps retain user attention and avoids scenarios where the user is left wondering whether the bot is broken.If a backend API that a Dialogflow virtual agent relies on has a long response time, it may be useful to prefetch the data and store it in Apigee’s cache to improve performance. You can include tokens and other meta-information, which can directly impact the time elapsed between customer input and a return prompt from Dialogflow. The Apigee cache is programmable, which can enable greater flexibility and thus a better conversation experience. You can implement prefetching and caching data using Response Cache (or Populate Cache) combined with Service Callout policy.6. Prefer responding with a single complex parameter instead of multiple scalar parametersWhen responding to a virtual agent with the SetDialogflowResponse policy, one can return multiple values at once via the <Parameters> element. This element accepts one or more children <Parameter> elements. If possible, it’s generally more effective to return a single parameter as a JSON object instead of breaking up the response as multiple parameters, each containing a single string or number. You can leverage this strategy via <JSONPath>.This approach is recommended because: Parameters will be logically grouped.Dialogflow CX can still easily access the composite parameters using dot notation.The agent can use a null value for a single parameter to erase previous response parameters and delete the entire JSON object instead of having to specify a null value for many different individual parameters7. Consider responding with 200s on certain errorsIf a webhook service encounters an error, Dialogflow CX recommends returning certain 4XX and 5XX status codes to notify the virtual agent that an error has occurred. Whenever Dialogflow CX receives these types of errors, it invokes the webhook.error event and continues execution without making the contents of the error response available to the agent.However, there are scenarios where it is reasonable for the fulfillment API to provide feedback on an error, such as notifying the user that a movie is no longer available or that a certain cinema ticket is invalid. In these cases, consider responding with a 200 HTTP status code to provide context around whether the error was expected (e.g. 404) vs. unexpected (e.g. 5XX).Get startedApigee’s built-in policies, nuanced approach to security, shared flows, and caching mechanism can provide a smoother way to implement effective virtual agents that deliver speedy responses to your end customers. By applying these best practices, your Dialogflow engineers can have more time to innovate and focus on building better conversation experiences rather than integrating backend systems.Try building a sample Contact Center AI workflow with Apigee or visit Integrating with Contact Center AI to find out more.Related ArticleContact Center AI reimagines the customer experience through full end-to-end platform expansionGoogle Cloud extends Contact Center AI with Contact Center AI Platform, adding CRM integration for end-to-end management of customer jour…Read Article
Quelle: Google Cloud Platform

QuintoAndar becomes largest housing platform in Latin America with help from Google Cloud

Stanford University classmates Gabriel Braga and André Penha knew the real estate market in Brazil was plagued by bureaucracy and steep fees, and they were sure they could build something better. They envisioned a digital marketplace that could connect potential tenants and homebuyers to landlords and sellers to streamline real estate transactions in Brazil. In 2012, they founded QuintoAndar, a housing marketplace that connects property owners, residents, brokers and agents in Brazil. The company, which began with a small team of developers, has now the largest valuation of a proptech in Latin America at $5.1B as of August 2021, after raising another $120M on top of the $300 million in Series E funding they raised in May 2021.Building a PWA at Google for Startups Accelerator: BrazilQuintoAndar started out with four projects in two stacks for their front end main products: Android and iOS mobile apps and desktop and mobile websites. The brand wasn’t well-known, so users were hesitant to install its apps. To meet their aggressive traffic and growth goals, QuintoAndar decided to participate in the Google for Startups Accelerator: Brazil program. Their Google mentors introduced them to the concept of Progressive Web Apps, which use modern web capabilities to deliver an app-like user experience, and described a long-term strategy for QuintoAndar using a PWA. QuintoAndar’s leadership could see that a PWA would allow them to evolve the product on multiple platforms by unifying the production and support of new features.To help focus developers on a main stack and offer users a great web experience, the QuintoAndar team decided to go all-in on a PWA written in React, using Chrome for the browser and Chrome DevTools to develop and debug the app. They used WorkBox to improve the offline experience and Google Material Design to unify the desktop-app cross-platform experience.The PWA served as QuintoAndar’s main web digital channel, and three apps met the needs of three user categories: home buyers and renters; sellers or landlords; and real estate agents. Home buyers and renters used QuintoAndar’s main PWA to search for homes, schedule virtual or on-site visits, negotiate, and complete all the steps of the rental or sales process. Homeowners used the homeowners’ app to list properties for sale or rent, monitor visits, negotiate with potential buyers or tenants, and close deals. Real estate agents used the agent’s app to manage their schedules, book visits, contact clients, and manage deals.QuintoAndar’s four years of focusing on its PWA helped the company shape its product and drive growth. Traffic increased to 30 times its initial rates. By 2021, with a larger engineering and product team and a well-known brand, QuintoAndar decided to invest in mobile app development, to offer a better user experience. After researching mobile development options, the company built a native app with Flutter, and QuintoAndar’s app score went up from 3.9 to 4.5. The company continues to invest in both web and native mobile app platforms.Leveraging Google Cloud to get results Now, QuintoAndar has dedicated platform teams to improve its tech stack and build developer tools for stream-aligned teams, like design system, web performance, and native teams. On the stack side, they use Next.js for web and Flutter for native apps. They also use YouTube, Google Maps Platform, Firebase, Cloud Firestore, Cloud Functions, and Analytics to real time sync in features such as favorite lists and negotiations (which are back-and-forth messages between the tenant/buyer and the homeowner/seller). When QuintoAndar launched, none of the players in the proptech market in Brazil showed exact locations of their listings, which had a negative impact on user experience. QuintoAndar uses Google Maps to show the exact location of properties, which forces the market to change accordingly.Looking forward to growthQuintoAndar has grown steadily, and today, the company employs over 4,000 people, with technical teams of more than 600. QuintoAndar is available in all five 5 regions of Brazil and more than 60 Brazilian cities, and is expanding internationally, starting with Mexico. Taking its lead from Google mentors, the company has adopted guiding principles of innovation, keeping customers at the center of decision-making, working collaboratively, and delivering results.  If you want to learn more about how Google Cloud can help your startup, visit our pagehere to get more information about our program, and sign up for our communications to get a look at our community activities, digital events, special offers, and more.Related ArticleHow Google Cloud is helping more startups build, grow, and scale their businessesLearn how Google is investing in startups at the 2022 Google Cloud Startup Summit.Read Article
Quelle: Google Cloud Platform

Amazon EMR Serverless ist ab sofort allgemein verfügbar

Wir freuen uns, die allgemeine Verfügbarkeit von Amazon EMR Serverless, anzukündigen, einer neuen serverlosen Bereitstellungsoption in Amazon EMR, die es Dateningenieuren und -analysten einfach und kostengünstig ermöglicht, Datenanalysen im Petabyte-Bereich in der Cloud durchzuführen. Amazon EMR ist eine Big-Data-Lösung, mit der Sie umfangreiche verteilte Datenverarbeitungsaufträge, interaktive SQL-Abfragen und Anwendungen für Machine Learning (ML) ausführen können, die auf Open-Source-Analyse-Frameworks wie Apache Spark , Apache Hive, und Presto basieren. Mit EMR Serverless können Sie Ihre Spark- und Hive-Anwendungen ausführen, ohne Clusters konfigurieren, optimieren, abstimmen oder verwalten zu müssen.
Quelle: aws.amazon.com

Amazon Route 53 gibt IP-basiertes Routing für DNS-Abfragen bekannt

Heute gab AWS die Einführung von IP-basiertem Routing für Amazon Route 53 bekannt, den Cloud-Service für das Domain Name System (DNS) von AWS. Route 53 bietet Kunden mehrere Routing-Optionen, z. B. Geolocation-Routing, Geoproximity-Routing, latenzbasiertes Routing und gewichtetes Routing, um seine Endbenutzer zu optimalen Endpunkten zu leiten. Mit dem zusätzlichen IP-basierten Routing sind Kunden nun zusätzlich in der Lage, ihren DNS-Routing-Ansatz auf der Grundlage des CIDR-Blocks (Classless Inter-Domain Routing), zu dem die IP-Adresse, von der die Anfrage ausgeht, gehört, feinabzustimmen, sodass sie das Wissen über ihre Endnutzerbasis nutzen können, um die Leistung oder die Netzwerkübertragungskosten zu optimieren.
Quelle: aws.amazon.com

Amazon RDS bietet Unterstützung für die Veröffentlichung von Ereignissen in verschlüsselten Amazon-SNS-Themen

Amazon Relational Database Service (Amazon RDS) können jetzt Ereignisse in Amazon-Simple-Notification-Service (Amazon SNS)-Themen veröffentlichen, für die die serverseitige Verschlüsselung (SSE) aktiviert ist, um Ereignisse mit sensiblen Daten zusätzlich zu schützen. Amazon RDS gruppiert Ereignisse in Kategorien, die Sie abonnieren können, sodass Sie benachrichtigt werden, wenn ein Ereignis in dieser Kategorie eintritt, was Routing und Automatisierung ermöglicht.
Quelle: aws.amazon.com

AWS Step Functions startet einen interaktiven Workshop zur Erstellung und Bereitstellung von Anwendungsworkflows

Sie können jetzt die Verwendung von AWS Step Functions in einem neuen Workshop namens AWS-Step-Functions-Workshop erlernen. In diesem Tutorial zum Selbststudium lernen Sie anhand einer Reihe von interaktiven Modulen, wie Sie die wichtigsten Funktionen von Step Functions nutzen können. Jedes Modul enthält Unterrichtsmaterial, das Sie in Ihrem AWS-Konto bereitstellen können. Es behandelt Themen wie die Koordination und Orchestrierung von Anwendungsworkflows, die Verwaltung von Workflow-Status, die Erstellung von SDK-Integrationen mit anderen AWS-Services und vieles mehr.
Quelle: aws.amazon.com