Your key takeaways
Learning more about the CrowdHandler product by getting hands-on with our dashboard as quickly as possible
Developing a waiting room proof of concept or internal demo
Projects where the server load is the primary consideration
Projects where the security and fairness of the queue is critical
I need to set up a basic waiting room without securing other dependencies first (no need to raise a ticket to Engineering!)
I want to pitch using CrowdHandler to the team—I need a low effort way of developing a demo to show them
I want to get up and running so I can learn the platform—we’ll do a full integration later
We just need to slow some of the users down a little—we’re OK with people being able to bypass the Waiting Room as this isn’t a sensitive queue
Users can access the webpage (the server has to stay up)
We’re aware that managing traffic peaks is a key reason why you want to invest in our Waiting Room–and we strongly encourage you to explore our other integrations to have the best success with CrowdHandler in these scenarios.
Whilst we would expect only a small number of users to skip the Waiting Room based on these scenarios, the fact is that each scenario breaks the fairness of your queue. This is why we offer our other integrations.
Your next steps
We recommend that entry points to your site are well cached; you can even consider specific landing pages which funnel users into the Waiting Room.
Be aware that some campaign links, which you may be using to drive traffic, can work against caching strategies if they add unique user tracking parameters.
If loading via Google Tag Manager, be aware of when the GTM calls are being made; many developers place the GTM container last, so it can be worth manually installing the CrowdHandler script in these cases.
Use the Waiting Room link in your marketing communications rather than the page on your website—this ensures the load stays off your page until the user has been queued.
Keep in mind that the key metric in terms of directing users to the Waiting Room is TTFB (Time to first byte)—this is the time it takes for your webserver to send the user the webpage.