Virtual Waiting Room: Elevating Your Customer Experience

My name is Aditya and I'm one of the founders and CTO at LumaHealth. We partner with over 500 healthcare systems across the United States to deliver a platform that they use to build their own patient journeys. Starting last winter, we launched our vaccine operation solution, which is a full suite of solutions that let healthcare systems craft, deliver, and manage their COVID-19 vaccination strategies. We partner with Cook County, Illinois, the second largest county in the United States, with a population of over 5 million residents. As demand ramped up, our platform began to see over 500,000 requests per second. Hundreds of thousands of patients were looking to get scheduled for their vaccines, getting checked in at clinics and mass vaccination sites, getting texts or email reminders about their upcoming vaccinations, and more. At LumaHealth, we've been a customer of Cloudflare's for over six years, but to continue to scale further, we partner with Cloudflare's Project Fairshot to utilize their waiting room. We were able to integrate the Cloudflare waiting room within 72 hours. We're able to fine tune the number of concurrent users within the Luma patient experience and provide accurate information about vaccine availability for users who are waiting. Layering the waiting room with Cloudflare workers has allowed us to scale up to virtually unlimited demand. The result, over 1.5 million vaccines have been scheduled via LumaHealth, and we're not done yet. We continue to work closely with our health systems and clinic partners to help address vaccine hesitancy, ensure vaccine access to all Americans, and to help all of us chart a way out of the pandemic. My name is Aditya, and I'm one of the founders and CTO at LumaHealth. We partner with over 500 healthcare systems across the United States to deliver a platform that they use to build their own patient journeys. Starting last winter, we launched our vaccine operation solution, which is a full suite of solutions that let healthcare systems craft, deliver, and manage their COVID-19 vaccination strategies. We partner with Cook County, Illinois, the second largest county in the United States, with a population of over 5 million residents. As demand ramped up, our platform began to see over 500,000 requests per second. Hundreds of thousands of patients were looking to get scheduled for their vaccines, getting checked in at clinics and mass vaccination sites, getting text or email reminders about their upcoming vaccinations, and more. At LumaHealth, we've been a customer of Cloudflare for over six years, but to continue to scale further, we partnered with Cloudflare's Project Fairshot to utilize their waiting room. We were able to integrate the Cloudflare waiting room within 72 hours. We're able to fine-tune the number of concurrent users within the Luma patient experience and provide accurate information on vaccine availability for users who are waiting. Layering the waiting room with Cloudflare workers has allowed us to scale up to virtually unlimited demand. The result? Over 1.5 million vaccines have been scheduled via LumaHealth, and we're not done yet. We continue to work closely with our health systems and clinic partners to help address vaccine hesitancy, ensure vaccine access to all Americans, and help all of us chart a way out of the pandemic. Hello, good morning, and thank you for joining the virtual waiting room Cloudflare webinar series. My name is Chrysanthi Kaling, Head of Partner Enablement, and today's host and moderator. Just before we start, I would like to share a few reminders. First, this session is recorded for future viewing. Two, presentations that will be sent to all the participants in the next few days. Three, for the questions, please use the Q &A button. Our speakers will be answering them at the end of the Q&A sessions. And then last but not least, we will also be giving gift cards to the first 50 who register and attend the session in this whole webinar. At the end of the sessions, there is a webinar survey that we encourage all of you to participate in. So we have a guest speaker joining us all the way from Germany, and we are very grateful and honored that he can join us at this early hour. So take note that it is 3 a.m. in Germany. And our guest speaker is Masanori Higashi-san. He is the Managing Director for ClassMethod Europe, the EMEA arm of Japanese Cloud Integrator ClassMethod. Prior to his role, Higashi was in sales and consultant positions in the enterprise software and telecom companies in Japan and Germany. ClassMethod Europe started a partnership with Cloudflare in February 2020 and has since expanded into Japanese market. ClassMethod has been very instrumental in rolling out Cloudflare waiting room solution, empowering organizations and governance, thereby making a huge impact, most especially in nationwide vaccination efforts in Japan. Such endeavor would not have been possible with the support of Higashi-san and his team. We will be hearing from him shortly when he speaks about implementation, use cases and best practices on vaccination effort. Also joining us all the way from San Francisco and our first presenter today is Cloudflare's very own Brian Batraski, Global Product Manager, managing a number of our solutions, waiting room, load balancing, just to name a few. He is a self-taught web developer, always excited about technology and apps, a product manager at heart and love solving complex challenges. So what we are going to talk today? Today our speakers will share Cloudflare waiting room offering and together we will explore why it is getting gaining traction, how organizations are of different sizes can implement virtual waiting room practices and how Cloudflare waiting room is making an impact globally, especially with our partner class method. Over to you, Brian. Thanks so much, Chrysanthi. Really, really appreciate it. Thank you everybody for joining today. I'm very excited to speak to you about waiting room. So let's start with a recap. A waiting room is a reliability solution here at Cloudflare that above all else is aimed to protect your infrastructure and specifically your origin servers from being inundated or brought down by too many requests from legitimate users or end users. But that's not it. We always have to keep the customer experience first in mind and thus waiting room also while protecting your infrastructure also protects your customer journey experience by maintaining a stellar and seamless experience from waiting room to your application. And so there are two main use cases that waiting room solves today. The first, which is mainly our bread and butter or unplanned spikes. And so since the emergence of COVID-19 and the global pandemic, we've seen a massive shift, not like we've seen before, from in-person brick and mortar traffic moving to digital online traffic. And the result of this has left businesses unprepared for the massive surges of traffic that normally they would have expected to take place in their local shops. But waiting room solves this through and through, make sure that there are no errors for the customers and that your infrastructure as it stands today can handle the influx of new traffic while not having to spend an arm and a leg on buying a fleet of new origin servers, auto scan clusters, whatever it may be. The second main use case that is solved by waiting room is scheduled events. Now, scheduled events, our traffic operates and behaves differently than unplanned spikes. When people are organically coming to your website versus when they are being funneled and geared towards your application. And so just in a few weeks, we're going to have scheduled events in product ready to go, where you can actually schedule up to five events at any given time. So you can set and forget those events in your waiting room, provide custom, different, behavior and queuing methods from your default or unplanned spikes waiting room, and make sure that seamlessly you can set and forget and make sure that above all else, that Cloudflare is going to protect your infrastructure and allow you to focus on your table stakes. Now, moving a little bit more into some more details, let's go into why our waiting room is so wonderful. Now, first off, it's simplicity. Setting up a Cloudflare waiting room takes no more than just a few minutes. And as you can expect, through all other Cloudflare products on our platform, we have UI and API parity for every single feature that takes place in waiting room. Now, waiting room is a cookie-based solution here at Cloudflare. There are no JavaScript tags necessary to implement into your front-end pages that could cause performance degradation or no added deployments or unnecessary deployments at all, in which a unknown bug could be introduced to your architecture. And so we make it very, very easy to not only set up, but to maintain and continue forward with. The next is visibility. You need to know what is happening with your traffic at all times. And so within our dashboard, in the Cloudflare dashboard, also through our APIs, we have a status endpoint in which you can always see how many folks are in your waiting room concurrently, how many folks are already on your origins or in your application, and, of course, the maximum wait time presented to users so you can make the correct and informed decisions moving forward as people funnel into your application. Lastly, integrated service. Waiting room already and out of the box works seamlessly with other products on our platform, such as DDoS mitigation, our WAF, our bot management, and other products, such as load balancing, rate limiting, and page rules. There's no needed configuration, updates to your infrastructure, nothing at all. Go ahead and set up waiting room. And the way that it is situated in our pipeline, it will already seamlessly work with DDoS mitigation and the other products. Now, setting up a waiting room is massively important nowadays to find a cost-effective solution to make sure that your customers are protected and have the best experience possible. And so the image here on the right is our default Cloudflare branded waiting room, in case you want to get something up and running quickly. But maybe you want to customize that waiting room. Maybe you want the look and feel to align perfectly with the messaging and brand alignment of your overall business. And so we provide you the CSS and HTML for the default template that you see here. So you have a starting point not only to customize your template, but also make sure that what your users see directly couples with the brand and messaging of your overall company. On top of this, we have mobile support as well. And so regards if you have an iPhone, an Android, or anything between native apps or web browsers, as long as those native apps can handle JSON, we look at those accept headers. And if we see application JSON as the accept header, we'll go ahead and send those JSON values over to your template that you've set up in your native mobile app. And again, waiting room works seamlessly across native mobile, mobile web, and regular browsers that we're using today. Now, waiting room takes place in every single metal in every single pop across our entire massive Anycast network. Cloudflare has the largest Anycast decentralized network in the world. And as you can imagine, we are always syncing data across all of our different data centers to make sure that we always have a handle on where your traffic is coming from, no matter where in the world it comes from, to make sure that number one, we always have a handle on who goes to your application, who goes to the queue. And number two, we roll that up to a global aggregate to make sure that we keep estimated wait times as low as possible and accurate as possible. On top of that, we have cookie-based solutions. So once we see that someone has been accepted into your application, they are never re-queued for the duration of their session while they go ahead and browse around and execute whatever purchases, orders, or services that are taking place on your application. On top of that, we have a number of different queuing methods. You might want to determine how democracy or fairness is characterized during different events or for specific segments of your application. And so we already have a FIFO, first-in-first-out queuing method, along with random, where we either let them in based on the time that we see them and the request came to your application and showed up at Cloudflare, or a random assortment, doing coin flips, making sure that folks have an equal way of getting to your application or getting to your products or services, regardless if they are living in a geographically aligned area or if they chose to wake up early. If you want to make sure everyone has the absolute fairest possibility of getting your services or products, you can go ahead and use our random queuing method as well. One other item to mention is that because we are a cookie-based solution, we look at every single cookie individually. So if one person leaves your application or a thousand people leave your application, we then let in as many people as possible while, above all else, respecting the limits and thresholds that you've set for your individual waiting room to make sure that your application remains up, available, and performant, but at the same time making sure that we keep the customer journey and customer experience in mind, making sure we give the most accurate and lowest estimated wait times possible. Now, let's go over a real-world scenario in which waiting room can solve and see how those challenges are mitigated. Now, let's pretend that the very real emergence of COVID-19, as we talked about before, has left a massive shift in traffic from in-person to digital, and businesses are left unprepared. And so let's say the problem that we have for a business, bryan.com, one of my tweets or market materials has gone viral much more quickly than expected, and so we're seeing large multipliers of traffic inbound to bryan .com. And the result of this, because I'm not prepared, is that I'm seeing errors being sent to my users, which in turn is leading to abandonment rates increasing, churn off my application increasing, a breach of trust for my application overall. And so these are all bad things, things that none of us would want. So some of the solutions I could have is I could go add some more origin servers, which is very, very expensive for ideally what is a temporary problem in nature. I can go set up a number of auto-scanning clusters in AWS or GCP or Azure to meet the demand of that spike in traffic, but again, very, very expensive, and also could lend to a massive swing in my bill at the end of the month. I could add a rate limiter to bryan .com, which is a fantastic option, but the one thing that the rate limiter doesn't do is that it doesn't handle the customer experience. It doesn't provide a seamless user journey from when they get to the waiting room, then to your application. Or I could put up a static page saying, hey, things are a little busy right now, we're having some problems, hold tight and we'll be right with you. But again, that's static. It's not dynamically updating, not giving a feedback or response back to your users, making sure that they feel heard and making sure they understand that the pages are just frozen, but that things are happening in the background and they will get to that product or service soon. And so we recommend adding a waiting room that you can brand easily. You can set up in minutes, set up multiple events with custom logic of determining how you want to queue, what is fairness and democracy in that scenario. And all the power, again, is in the tip of your fingers. Now I'm going to pass it over to Higashi -san. Yeah, thank you very much. I'm Masanori Higashi from ClassMethod Europe. Why the person in Europe or Germany talking to Asian market is the ClassMethod Japanese company, actually. We are software developer and also the very famous in AWS premium consulting partner. And AWS have the unofficial turnover ranking, and obviously we are number one in Japan. And in Asia, we are the second position next to the FPT in Vietnam, and globally, number eight position. We are starting from the software house, but current business is a cloud integrator, mainly focusing on AWS. But we originated in a developer group. So still, we are really a developer-focused company. So we support creative engineers and spread technical knowledge. And also, we're bringing some of the affordable and effective services to the Japanese market. We have our own blog media, the Developers .io, which is, I suppose, the biggest tech blog media in Japan. We have got more than 25,000 articles and almost 3 million monthly page views and half a million monthly unique visitors. So really trusted tech blog media. And half of that is regarding the AWS new product or just went through the new product or something like that. But we, of course, are writing about the Cloudflare. So the number of the Cloudflare article, I suppose it's almost 20 or something like that. So we are also on track. So how our journey together with Cloudflare started? Since we are AWS company, we have got a huge conflict in Cloudflare CDN. So the journey started in early 2020. The before the Cloudflare Japan established. And the Japanese support team in Singapore contacted me to sell the Cloudflare core CDN and the DNS. But at that time, I said, we have got the CDN product from AWS CloudFront. So it is really hard to partner with the Cloudflare. But in Europe, we have got a really nice free hand to the local market. So apart from the CDN, we implemented the Cloudflare gateway, which is the gateway filtering solution using the DNS. And it is alternative for the Zscaler ZIA. And also Cloudflare access, which is the VPN alternative solution. So apart from CDN, we somehow started the business in early 2020, starting from Europe. And then the COVID hit. So we have got the campaign for the remote working from home solution with the Cloudflare access and also the Cloudflare gateway to implement the gateway filtering solution regardless of location. So we have got the signature customer, NTT Docomo, for Cloudflare gateway in Japan. So I suppose it is the first customer in Japan, and the first customer was a really huge customer. Then the time goes on, and now 2021, the vaccination campaign is ongoing. So we are thinking about the website protection and slaughtering or queuing to protect the massive access site for the vaccination campaign. So we started from the network solution, so the not mainstream product of the Cloudflare, but the new product to the market. So I talk about our way of thinking and the way of business and the motivation to the society. So from the left, it is the early 2020, the German government have got the financial aid for some of the industry hit COVID-19. And Germany have got 16 Bundesland, which is the sort of the states. And each Bundesland implemented the QEIT for the financial aid application form. So I already thinking about the vaccination campaign for the year ahead during that time. And also we have got the experience with the QEIT for the queuing solution. But we know QEIT is also built on the AWS. So thinking about the diversity, it is not a really good solution because most of the backend, the server would be working on the AWS. So at that time, I already thinking about the QEIT is not good enough for the vaccination campaign ahead. And also the very early stage of the vaccination campaign, it's some of the hacking or cheating to get the reservation for the jab. So it is definitely need a really effective bot and the DDoS protection. Then the project FairShot coming up from US. And I immediately after I get this news, I put it on the Slack. We have got the core channel with the Japan team. And in that message said, regarding the waiting room, we never know how the Japanese vaccination campaign going on, but how about get the single page or campaign page from class method and seeking the opportunity. So right after that, I made the landing page. So the cloud for a waiting room part of my class method. So somehow gathering the attention from the market, of course, I put it on the blog, developers.io. So the market just clicking some of the solution coming up from the class method. So for the vaccination campaign, there's no super bullet to effective or fair the booking site. But the bottom line is don't crash down the servers. So the pain point would be the massive simultaneous access in particular time such as the application start in 9 a.m. or 8 a.m. Really the massive spike, access spike coming in. So the backend system is not only view, but read and write to the database. And the reloading from the multiple devices. So some of the user, we started in older people, 75 years old or over, but the son or the grandchildren helping the grandpa and mom making the several window and pushing the F5 to reloading. So it is really easy to crashing down the site. So there's a lot of the pain points. So first idea should be reinforcement for the origin server. Just making the 16 Excel something for the AWS or something like that, or using the load balancer. But it's still the database network and disk.io can't be helped. And also the subsystem is of course not supported. So second idea should be a CDN. So let CDN respond in the front line, but still the dynamic content would not support it. Then before the CDN, the name resolution. So the Cloudflare have got the proxy DNS. So let proxy DNS respond in first line, the queuing available in the waiting room. So it is actually using the workers technology. And still the security or the anti-cheating is not implemented. So the waiting room for the vaccination campaign has provided by Cloudflare for free, but we sell some of the CDN and the WAF function as a subscription. So the waiting room solution itself was free, but the customer would like to have got a more feature originally have the Cloudflare has. So firewall and anti-dedos and bot, especially for the bot, it is really effective in the WAF in the DNS. And sometimes we can do the user authentication using the Cloudflare access. So the last problem that's problem existing would be how much money do you have, the customer have. But Cloudflare waiting room was provided for free for the vaccination campaign for the cities or the medical institute. So only the Cloudflare business subscription would be enough for the firewall protection. So the cost is almost nothing for users. And users can implement only three parameters, the origin server capacity and the new coming users, new coming visitors per minutes, and also the session configuration, only three. So most of the user even doesn't need the consultation or any support, they can do by themselves. And in right-hand side, we provided the translation of the template of the the waiting room itself. So most of the visitors might saw the Cloudflare and the Cloudflare logo, which is a huge advertisement to the market. So how we develop that market? So marketing and campaign. So we starting from the friendly existing customers. So Shikoku Joho, Shikoku is the fourth island in Japan, and they have got the local system integrators, Shikoku Joho. And they developed 10 cities and municipalities vaccination site. So we already help for the AWS infrastructure. So we propose the Cloudflare waiting room to them, and they immediately accept it. So the first user is the Shikoku Joho, and the first end user is the 10 cities. And next, we contacted some of the AWS integrator and also the Salesforce commerce partner, who is making the home service of the some of the cities, big cities vaccination site. So Tokyo Nerima and also Sapporo is a signature customer in early stage. Most of the other integrator, system integrator know the Sapporo has, in very early stage, they implemented Cloudflare waiting room. So next, we approach the Akamai user. So a big system integrator have got the vaccination site for the big cities, such as Osaka, Kobe, and Nagoya, and they are using the Akamai CDN. But the Akamai have got the very similar waiting room solution, but it is very expensive. And we can provide for free almost. So we approach the Akamai users one by one. And successfully, Osaka and Kobe and Nagoya, the median cities accepted that the Cloudflare waiting room. Then we start door-to-door call for the developer and municipalities. And in the same time, clinics and other medical institute, the service follows. So I related all the municipalities and cities, which is 1,713 in Japan. And the outcome, we successfully 223 cities and municipalities out of 1,700 cities. And just thinking about the population cover, only for this municipality vaccination site, 25% of total Japanese population was covered by the Cloudflare waiting room. And other bodies, 360 clinics, and two joint ventures vaccination center in Tokyo and Osaka. So together with the 28%, maybe half of the population, so the waiting, Cloudflare waiting room when they book the vaccination timing. So that is a waiting room is quite new to the market. And it is not the first solution such as the QEED, but market perception is immense. So we looking forward, this is the new market leading solution for massive access and spike website. And after we implemented the vaccination site, we have got some lead. So which is the coming use case is the theater ticket site and the landing page for the video games. So some of the video games starting exact 10 p.m. UTC worldwide or something like that. So it have got the obvious spike for the base. So we will implement the Cloudflare waiting room to that site to ease the access. And some of the rare site, that is the actually the airline, the mileage shop. So yeah, this kind of the massive spike could be predicted to that site. That would be the potential customer. And we already have got the lead in those kind of industries. And at the same time, the waiting room is the quite important component for the very front edge stack development standard. So I suppose the waiting room should be a jumpstart component for developer. And the DNS level website protection is really effective and it is differentiate to the other CDNs, just Akamai or AWS CloudFront. So we are AWS partner, but I personally the spreading the Cloudflare CDN followed by the waiting room, the success of the waiting room. So that is my part. And I bring back to the Brian. Thanks so much, Higashi-san. Fantastic work with waiting room. So happy to see the immense success that class method and Japan and surrounding areas have been able to achieve with our technology. We are very much looking forward to continuing to partner together. So one thing to kind of mention is, Higashi-san had spoken about is Project Fairshot. A Project Fairshot was Cloudflare's response to being able to take some part in addressing the COVID-19 pandemic around the world. And so we saw that we couldn't drive the frozen trucks that are carrying the vaccinations. We couldn't open vaccine centers to create more awareness or outreach to be able to handle the influx of people that needed to get vaccinated. But what we could do, what we did identify is that the process of trying to sign up and reserve the spots for to go get your vaccine was very, very difficult. As Higashi-san had just told us. And so Cloudflare's response was Project Fairshot, right? A fair way to get your vaccination shot. And so for any government, municipality, public or private business, anyone responsible for the scheduling or dissemination of vaccine, we provide our waiting room for free. And so we've had a lot of success being able to help the world and be able to move past this very, very difficult time for us personally, for our family and for our friends. And so let's take a second to see how we're doing. So first off, we originally stated that Project Fairshot would extend until July 1st, 2021 and provide it for a year. But we saw that the pandemic was not only a year-long item in our lives. It's going to continue to be here for some time further. And so until at least July 1st of next year, 2022, Project Fairshot will continue in our waiting room for those identified areas. If you are responsible in any way for dissemination of the COVID-19 vaccine and following booster shots, waiting room will be available for free at no charge. So today we have over 100 customers, specifically just on Project Fairshot, spanning over more than 10 countries around the world. And as of now, to our estimations, we've been able to book at least and more than 100 million vaccinations booked and disseminated. And that number is still counting across multiple countries around the world. And so as one of these posts I love to share is from a county located here in Southern California in the United States, the county of San Luis Obispo. They had stated at the bottom line that Cloudflare saved lives. The county will forever be grateful for their participation in getting the vaccine to those that need it most in a very elegant, efficient, and ethical manner. And so we have more blog posts, more case studies available to read on how our customers and further customers have been leveraging Project Fairshot and our waiting room technology. There's two in particular that I wanted to kind of cover today. And so at the very beginning of the webinar, we saw a video from the CEO of LumaHealth at DTF. And so LumaHealth is a healthcare provider across the United States that partners with different companies trying to make sure that access to health services is fair and available. And so they approached us needing to provide a solution to allow a large population of individuals to be able to get access to the vaccine. And so the second largest county in the United States, Cook County, located in Illinois, has 5 million people. And so they were seeing that they had over 500,000 requests per second trying to get access to the vaccine. And so in a very efficient and quick manner, we were able to spend a waiting room with LumaHealth, partner with them hand in hand, along as we have done with class method as well, and be able to handle virtually unlimited demand to make sure that as folks and surges of hundreds of thousands of people want access to the COVID-19 vaccine, they have a feedback loop to have an understanding of when they're going to access the application, when they're going to get their chance to book the reservation, and make sure that they can move forward to staying healthy and protect those that they care about, their loved ones. And in less than 72 hours, we were able to integrate waiting room with LumaHealth and Cook County's technology to make sure that the infrastructure was protected. Another company that we have partnered with recently was a company called Fan Hero. Now, this was not within a COVID-19 or Project Fair Chicago use case. Now, Fan Hero is a wonderful company that helps provide sports entertainment and streams to a massive, massive million-plus audience across the world. And so they had a very time-sensitive event taking place for European football, or in the United States, what we call soccer. And so we were expecting over a million people to view this, I believe, as the championship league finals. And so they needed something very quickly. And then very late at night, they had approached us. And within the very next day, we were able to get waiting room up and running, and we were able to help over 375,000 online viewers simultaneously, and be able to make sure that not only are Fan Hero servers kept available, performant, and make sure not even a single error is provided to their end users, but also make sure that their end users have a very seamless and a great experience getting access to that content. And so this is just a few examples, along with the wonderful partners that we've been able to achieve with Cost Method, and where we're able to protect customers' infrastructures in a very seamless and in a very cost -efficient manner. As Higashi-san had mentioned, we are built on our workers and durable objects products, thus providing us, one, building Cloudflare on top of Cloudflare, because we believe so deeply in our products, and two, showing the elastic scale that waiting room and underlying technology can achieve. Now, we'll go ahead and open it up to some questions. Thank you, Brian and Higashi -san. I see a lot of interest in the contents that you shared and see the questions coming in. So just before we move to the Q&A, just a gentle reminder to our attendees to participate in the short survey at the end of the sessions. So let's take a look at the questions here. The first question, I think it can be addressed by Brian. How does Cloudflare waiting rooms licensing and pricing work? Do you build by the number of requests received in the queue or based on bandwidth, based on the volume of requests taken and direct that to the waiting room? That's a great question. Thank you so much for asking. So we had looked at the market and seen how a lot of the incumbent waiting room solutions had provided their go-to-market or pricing strategy, and we see almost fully across the board everyone charges based on some form of usage. And as we understand that aligning usage and consumption with the amount charged is a great way to drive value. But at the same time, the nature of your traffic when it comes to waiting room is going to be off baseline. It's going to be very spiky and likely some of the largest amount of traffic that you're seeing. And so we didn't feel it was the right way to somewhat punish customers by having a very, very high bill at the end of their month for driving what is, to be frank, lots of success. The more people you have to your application, the larger your customer base, we at Cochlear wanted to help promote that. And so we didn't feel at the end of the month having you see a very, very large bill is the right way to go. And so waiting room is priced without any consumption or usage. It is purely priced on the amount of waiting rooms across the number of zones that you have on Cochlear. And so at the end of what this means is that, number one, there is no swinging or fluctuations in your bill month to month. Your bill will be the same every single month. And two, whether you have a one person in your queue or a hundred million people in your queue, the amounts charged per month will not change. And lastly, we take the waiting room product very seriously. This is not a sideshow here at Cochlear. This is a high value core product. And so we have a roadmap already spanning two plus years. And so as we continue to add more advanced capabilities, more integrations, more notifications, and robust capabilities within the product overall, that will not increase or change the price for those customers. And so it is a fixed price based on the number of waiting rooms you have total. Thank you, Brian. There is a next question. So you mentioned that waiting room is seamless to application, easy to implement and cost effective. So how difficult it is to updating the template or the waiting room config work? And when you propagate, is there any delay in propagation? So how fast the propagation is? Great, great question. I'm really glad someone asked this. So first off, setting up of the waiting room is literally minutes. There are two technical prerequisites to be able to leverage the Cochlear waiting room. Number one, you must proxy your traffic through our CDN. This is how we are able to see the traffic in those requests to make sure we know when to queue and when to let those requests go directly to your origin. Number two, you must have some level of DNS records, CNAME records in Cochlear's DNS to make sure that as those requests come into your application, that they have a valid DNS resolution. Otherwise, other than those two items, there's nothing else required to set up a waiting room. Set up a waiting room is five required fields, a name, the two vectors in which we determine the total active users or the total news per minute, the spike of users coming in, the URL, the hostname, subdomain or path. Again, subdomains work right out of the box for waiting room. And lastly, the session duration that we default to five minutes. So it's five required fields, very, very easy to set up and setting up your template. Other than those two things, waiting room is ready to go and it can be deployed in seconds. And so when you make an update to either your config or to the waiting room template itself, that propagates within every single metal across every single data center in Cloudflare's 200 plus data centers around the world within a matter of seconds. And so Cloudflare does not have this notion or idea of when we hit an 80%, 70%, 90% propagation, that we then call it complete. That doesn't exist for us. When it's 100%, it's 100%. And so because of our massively quick propagation speed, when you make an update to your Cloudflare template, wanting to interact with your users in real time, update them in the amount of vaccines available, the amount of products or services available in your supply chain, that will propagate to every single metal, to every single user in one second. And make sure on their next automatic page refresh, because we do populate the refresh header with a 20 second refresh, every single user in your queue will see that new content right away. And we today have many, many customers who use this method of a very, very quick propagation time to be able to interact and provide updates to their users in near real time. Great question. Yes, thank you, Brian. And just to mention that it so happened that today is 9 September in Asia, and there is a lot of online promo, online shopping events that is going on. So I wonder if everyone in the audience, you know, do online shopping spree due to a lot of promos and you might see Cloudflare waiting rooms are being presented there. Next question is actually directed to the class method, which I believe Brian has a bit answer it previously. But the question to class method, since you already implemented Cloudflare waiting room, so we also want to get your view. What do you think about the implementation of this feature compared to other vendors, because their challenge is always been a complex configuration? Yeah, compared to the other solution, obviously the Qt or Akamai prioritization manager, the Cloudflare is obviously easiest because it is handled by the proxy DNS, which means once the DNS is delegated, or you can also using the CNAME setup to using the existing name server, you don't need any change to the origin. So the waiting room itself is totally working on the very front end, which is the DNS. So the cost of implementation is the, I suppose, almost zero compared to the other two. So, yeah. So I can recommend it is the easiest. Then the next question is, how does it support integration with native mobile apps? Because nowadays people shopping is using mobile, using apps, seldom using desktop. Yeah, we have got some of the tips throughout the vaccination campaign. Some of the vaccination campaign is implemented as the form service, such as the Salesforce Commerce. So even for that, the form configuration, they just directed to the form's actual URL, and in front of that, implementing the waiting room. So it is the simplest way to implement that. So you can minimize the change for the form services. I see. So there is a way to identify, and that is really seamless, even with the mobile apps as well. Yeah. And I just wanted to add just a little bit of extra context on that. Thank you so much, Adarshism. A little bit more on to how it works is we look at the accept headers, whether they accept headers of that client state, text HTML, or application JSON. And so if you have users who are trying to access your application from a native mobile app and a mobile web browser, and also a regular desktop browser, and the desktop browser and in the browsers, they will ask for text HTML. And so we will send the regular HTML template over to that client. But for the native mobile application, it is going to ask for application JSON. And thus, we will then, as the user has already created a template in their native mobile app, we then send the information for those JSON values, and again, very seamlessly allow different users across different clients to all be within the same waiting room, adding multiple things. Number one, ease of use and setup for you as the customer, and two, a very seamless experience for your users, as it does not matter if they are coming from one client or the other. And so waiting room already abstracts that issue away from you, and just allows you to focus on your table stakes on your customers, knowing that Cloudflare's waiting room is protecting your origin servers and providing a wonderful experience to your users. Great answer. So the key question here, the key answer here is seamless integration, even with the native apps. So another question we have is, we have a current project, a gaming application, which we already use Cloudflare as a CDN. So what additional security or perhaps a feature that they need to add in their application as they are interested in this waiting room feature? It's a great question. You know, not knowing as much of the specific goals you have in mind makes it a little bit more difficult to answer. But from a high level, first, you can definitely put in a waiting room from a security perspective of protecting your infrastructure and keeping it reliable and resilient. In regards to security and making sure that malicious users, that actors are not accessing your application or trying to do some malicious intent, we absolutely have DDoS mitigation, our WAF, our bot mitigation, along with a number of other products. What I recommend is getting in touch with our sales team or your existing, depending on what plan on Cloudflare you're on, your existing CSM or account executive, and they'll be able to very easily help you determine what are the correct solutions to help you reach your goals. But at worst case, feel free to email me at bimtrowski at Cloudflare .com, and I'll happily make sure that you're connected to the right folks. Awesome. A follow up for that question is, does the waiting room kick in automatically, or do you need to manually turn it on? And on what are the factors or parameters you need to look at to determine if it is working, queuing? Great question. So the last few minutes that we have, waiting room is a fully automated solution. Unless you want to manually intervene, it is not necessary whatsoever. And so we look at two independent vectors to determine when we queue, and these are completely independent, not related. So we look at the first item of how many users are concurrently in your application. We know that if there are too many users on your origins, that could use too much compute power to consume too much memory, and therefore take down the origin, in turn serving errors to your users, which is something we don't want to happen. The second vector we look at is new users per minute, or another way to think about it is the incoming traffic spike. So let's say you don't have a lot of people on your origins spending a lot of time on it. They come in, they purchase whatever they need, or execute the service that they need, and then they leave. But then you have an influx of users, 100,000 people at once, coming and trying to access your application. That could, again, turn over your origins. And so we look at whichever comes first, and then stagger that traffic and start queuing folks to make sure their origins are protected. But again, we do have manual controls necessary, such as our queue all feature, where you can drive everyone to the waiting room if you'd like. But again, it is all 100% automated. Once we see the 95th percentile of those config values reached, waiting room kicks in. And once your traffic goes back down to a regular baseline, then waiting room turns off automatically and lets those users directly to your origin. Interesting. And I think the last question is pretty interesting. So this is the last question for the session. You mentioned about we measure based on the traffic request. But nowadays, in the Internet, there are a lot of automated traffic that is not really human. So previously, you assume that everyone is human, but what if half of the traffic is not from human, but from bots? So how can you identify bots from the genuine human traffics and show the trends? That's a great question. So in the last few minutes here, what we highly recommend is to leverage our bot mitigation product. And so DDoS mitigation, our WAF, and bot management all run very early in our pipeline. And so by leveraging our bot management solution, that would actually remove all bots or suspected bots from even reaching your waiting room altogether. That's making sure, number one, spots are not taken by automated users that should go to real users. And number two, it makes sure that your estimated wait times are kept as low and as accurate as possible. And so we highly recommend coupling together waiting room and bot management as they absolutely go hand in hand for a full solution to making sure that your events and your application is actually serving real traffic. Interesting. So these two solutions are fully integrated. There is no complex configuration to activate. And then there is no change required from the application itself. So it's like turn on solution and that's it. All right. So I think we are at the end of the hour. So for the gift card qualifiers, your gift card will be sent to your registered email after we check the webinar logs. So thank you very much for all the interaction and questions. We look forward to hosting you again soon. Thank you, Brian. Thank you, Higashi-san, for the great presentation. Thank you very much. Yeah. Thank you. Thank you.