How do virtual waiting rooms actually work?

What does a virtual queue do?

Our virtual waiting room and queuing system takes all the visitors or customers your website or selling system can’t manage and moves them into a virtual waiting room—safely away from your website. When each user’s turn comes, they’re moved back to your website or payment process to complete their transaction.

Why? To prevent system overloads and crashes; keeping your website running smoothly through peak traffic times and unexpected visitor surges. Simple, right?

Fortunately for our customers, we’ve made it precisely that—with an easy to implement system that works flawlessly. Having said that, we won’t lie; we’ve been working with queuing systems for years and have continued to develop our products with every last snippet of experience we’ve gained. We’ve put a lot of hard work into creating a system that keeps your life simple, your website fully operational at all times, and the payments rolling in—however busy you get.

How does our virtual waiting room work?

We’ve made it as easy as possible for our clients and their customers to access what they want without a hitch, matching top technology with best psychology practices to prevent dropping any confused or impatient visitors.

1. A visitor arrives at your website or hits the link to enter.
2. If the site is busy, the user is queued in a virtual waiting room away from your website and kept up-to-date with all the information they require to stay in the queue.
3. When they reach the front of the ‘first come, first served’ queue, the user returns to your website.

That’s the simple version. Here’s a bit more detail into what goes on behind the scenes.

1. We keep your websites safe from overloading, crashing, preventing a loss of income

The SafeGuard Rate Limit is the number of visitors your website can manage without putting stressful loads onto your servers and their systems. The SafeGuard Rate Limit is your web-traffic safety net.

Your Queue-Fair Portal allows you to measure your traffic volume in real-time, allowing you complete control of your Queue Rate (the number of visitors fed back to your website each minute).

In SafeGuard Mode, your queue is always active, but your visitors won’t know that until numbers exceed your SafeGuard Rate Limit. The way we measure user rates is the magic of our system and has been since 2004. Traditional methods of measuring the number of active users are flawed, often producing inaccurate figures or leaving users stuck behind visitors who may never complete the transaction.

2. Queue Rate and SafeGuard Rate

Queue Rate controls the outflow of visitors to your website from the virtual waiting room.

Safeguard Rate manages the inflow of visitors to your queue. This is also the activation threshold that determines when your Queue Pages are shown.

Outflow rate and inflow threshold are measured in visitors per minute and typically set at the same quantity by default.

The benefit of having two separate rates means if you’re transferring visitors from one site, your main website for example, to another where your booking or buying system operates, it’s quite possible that they have different limits to how many users they can manage at any given time. By setting your inflow and outflow rates accordingly, you choose precisely when the queuing system automatically takes effect, providing a steady and measured customer flow to the payment site. This guarantees the optimum visitors to your sales and bookings area at the rate it can operate the most efficiently.

3. Setting up your queues

Setting up a queuing system takes two simple steps: configuration and integration. We’ll talk about integration adapters in section 6.

Activating a queue

Activating a queue is a simple process governed by defined rules. If you’ve ever applied rules within your email software, or used Google Tag Manager, you’ll already feel comfortable with our system.

The activation rules can be dictated by the domain, a path, a query-string, or cookies detailing visitor’s page visits. Once all of the rules deliver a match, the user drops into the queue.

How many queues do you need?

This depends on the architecture of your site or sites and their bottlenecks.

If you have separate sites using different machines, you’ll need multiple queues and virtual waiting rooms. If, on the other hand, you have several webservers drawing from a single database machine, then a single queue should be all you need.

The other factor in play is what the business requires from its queue. This can cover a range of eventualities.

• A simple safeguarding solution to protect busy websites and server performance.
• When serving the same content to differently branded domains or in different languages.
• You have allocated VIP status to visitors you want to receive the fastest service.
• Various campaigns run from the same set of machines, using different brands, countries, or promotions.
• Specific events that require their own queues and virtual waiting rooms.

Customising your queues

As with all of our deliverable pages, customisation is simple and straightforward. Branding, colours, and text are only the start. We give you access to the HTML code so you can take as much control over the look and feel as you want.

4. Joining a queue

Joining a queue is managed by the inflow and integration method: server-side adapter, client-side JavaScript adapter, or by direct link. You can combine these methods to cover multiple means of access.

For example, a direct link from an email campaign and a server-side adapter on your website can drive users to the same queue. You can even use client-side and server-side adapters on the same page!

5. Leaving a queue

Visitors leaving a queue or joining the site directly without seeing a Virtual Waiting Room (Queue Page) are labelled as Passed. Passed visitors don’t stay that way forever. They receive a passed string or a cookie with a given lifetime that you decide. This protects them from having to re-join a waiting room they’ve already been through while allowing you the ability to have them join the same waiting room on subsequent visits in the future.

6. Server-side and client-side adapters

Server-side adapters

Server-side adapters require a small amount of library code installed on the webserver. This code downloads and stores the Queue-Fair settings you decide and set up using the Queue-Fair Portal. The code manages HTTP requests for the pages on your site, redirecting visitors to our Queue-Servers whenever they qualify.

Client-side adapters

A client-side adapter requires no server-side code, but a simple single line of HTML code added to the section of the desired web pages. However, a visitor with advanced technical skills can disable JavaScript, which provides a route to jumping queues. It makes little difference to most customers in practice, as the percentage of users with such knowledge is so low. That said, where SafeGuarding is a priority, we’d always suggest a server-side adapter, utilising its secret keys as protection.

7. Direct links

A direct link sends a visitor straight to the queue they need to join. If fewer visitors arrive in the queue than the SafeGuard Rate, they are sent directly to the target page without ever seeing the Queue Page.

If you’d like even more information, get a copy of our Technical Guide

Despite labelling this article as a deeper-dive into our system, we have to admit it’s barely scraped the surface. There’s only a limited amount of information we can deliver in one short article, after all. The details provided in this article are merely a summary of our Queue-Fair Technical Guide.

You can download a full copy of the guide from our website. If you’re considering joining the Queue-Fair family, we’d heartily recommend it.

There’s a host of information that will put both beginners' and tech-experts' minds at rest, giving you the confidence that with Queue-Fair in place, your systems are safe from overloading and costly losses from system crashes.