What we’ve learned from 150,000+ hours developing a virtual waiting room

However we quantify it, the last 10 years have been quite the journey.

We confess we’ve encountered our fair share of challenges along the way. But by leaning into our niche and learning constantly along the way, we’ve emerged with a better company and a stronger product.

That said, if we could go back and talk to our 2010 selves, here are the 5 lessons we’d share after spending 150,000+ hours developing our virtual waiting room.

1. The value of a laser focus on our product

There’s a strategic approach in software development known as domain-driven design. It proposes that software domains should align with business objectives. Software has primary, secondary, and general domains, and their order of priority should be in line with the business’s value proposition.

Let’s take a company that builds an online ticketing platform. The primary domain would be the ticketing platform. The secondary domain would be ancillary services that support the ticketing platform—for instance, a seat selection algorithm. The general domain would be additional services that help support the business—for instance, an invoicing or accounting system.

For us, our virtual waiting room is at the center of the bullseye. It is always our top priority, and never gets sidetracked by competing priorities. In short, we’re able to give it the attention and resources it deserves.

We have current enterprise customers who tried for years to build in-house virtual waiting room solutions they couldn’t get to work. And why wouldn’t they be destined to fail? A virtual waiting room is at best in the secondary domain for the companies we work with, if not the general domain. When businesses must choose between developers supporting their core business product or spending time on a non-critical side project, we know what the decision will be.

When businesses must choose between developers supporting their core business product or spending time on a non-critical side project, we know what the decision will be.

That’s why we don’t spend energy developing our own accounting, project management, or CRM platform in-house. These tools require ongoing maintenance and are critical to the function of our business. So we outsource them to companies with those core competencies to free us to devote time to our core mission.  

The biggest lesson we’ve learned from 150,000+ developer hours is the value of constantly verifying we’re spending those hours on the right priority.

Discover the virtual waiting room that’s right for you

Get my free guide

2. The need to evolve with tech & the market

Technology and the market are changing constantly. But because the virtual waiting room is in our primary domain, we can assess trends on the horizon and allocate resources ahead of time.

Here are just two examples of where we’ve needed to evolve:

Mobile

Back in 2011 less than 10% of worldwide consumers had a smartphone. In the U.S. mobile accounted for just 7% of overall ecommerce sales. Fast forward to 2021, mobile drives 42% of North American online purchases and has a 67% retail mcommerce share worldwide. That’s a drastic shift in consumer behavior.

When we started developing our virtual waiting room, we focused on desktop. But we quickly realized we’d need to emphasize support for mobile. And that meant we needed to accommodate the unique challenges of mobile queuing.

Applying a virtual waiting room to mobile involves much more than making waiting room pages mobile responsive.

Are mobile browsers, progressive web applications (PWAs), and native apps all included? What should happen if a phone goes to sleep or powers off? What about if the visitor browses other sites/apps while waiting? How can we allow on-the-go visitors to keep their same spot in line when they switch from mobile to desktop, or vice versa?

Solving these challenges took significant developer investments. In general, we’re quite pleased with the results. If we couldn’t get ahead of the curve and prioritize resource allocation up front, we risked having our product become obsolete.

If we couldn’t get ahead of the curve and prioritize resource allocation up front, we risked having our product become obsolete.

RELATED: Learn Why Top Enterprises Turn to Queue-it to Manage High-Demand Sales

Edge computing

When our co-founders started Queue-it in 2010, they knew they wanted to develop a cloud-based software solution. Cloud computing had been around for just a few years (AWS as we know it launched in 2006). They saw its potential both as a promising technology and as a framework for building a scalable, global platform.

But edge computing—and in particular being able to run code and applications at the network edge—didn’t exist when we started. In fact, as Varghese and colleagues noted in their 2019 article in the journal Computer, “edge computing” wasn’t even proposed until 2009. It didn’t gain traction until years later, after Cisco’s Fog computing in 2012 and AWS Lambda in 2014.  

Diagram of the edge computing timeline from "Cloud Futurology" by Varghese et al. from a 2019 article in the journal Computer.

Because of the focus on our primary domain, we had our ear to the ground in the cloud computing space and understood the implications of edge computing for us.

Specifically, the ability to run code and applications at these edge servers opened the door for our virtual waiting room to intercept web traffic before it arrived at origin servers. This shielded the origin servers from website overload even better than with other integration options.

Strategically, we prioritized creating Connectors to leading edge computing providers. Beyond bolstering protection from website overload, the edge-based Connectors enhanced security, simplified troubleshooting, and improved performance.

Again, pivoting to these new needs wouldn’t have been possible without a single-minded focus on our product, evolving technology, and market trends.    

Pivoting to these new needs wouldn’t have been possible without a single-minded focus on our product, evolving technology, and market trends.  

3. The benefit of learning from our customers & partners

If we only developed the virtual waiting room for our own use, we’d have lost priceless experiences and feedback from our wide customer base and worldwide partners.

If we only developed the virtual waiting room for our own use, we’d have lost priceless experiences and feedback from our wide customer base and worldwide partners.

Our customers use Queue-it on a daily basis, so our system is constantly under the microscope. Our development team gets ongoing feedback on what’s working, what’s not, and what functionality is missing.

If we were developing this for in-house use, we might only use the virtual waiting room a handful of times throughout the year, stress testing here and there. It would be very easy for our ecommerce team to introduce a bottleneck between sales, a bottleneck that we’d only detect during the sale itself once problems arose. This is a real problem from the companies we know who’ve attempted their own in-house solution.  

With continual customer feedback, on the other hand, our development team makes incremental changes all the time, so we’re alerted quickly if something’s amiss.

Our focus on the virtual waiting room space also opens us up to collaboration and knowledge sharing with complementary services in the web performance space. We’ve learned a ton over the years from partner experts in bot mitigation, online ticketing, and load testing, just to name a few.

A case in point of the value of customer and partner learnings is the development of our Proof-of-work challenge for bot mitigation.

Proof-of-work challenge

By working closely with our customers across retail, ticketing, and government industries, we noticed alarming trends in bot behavior around 2018-2019. Bot makers were shifting from data center IPs to residential IPs, sometimes using proxies, in an attempt to mask their identity.

With inspiration from our partners, we turned to developing a proof-of-work challenge. It would raise the bar for bots’ complexity and create a cost hurdle by increasing the demands put on computing processing power.

The results were promising. For one major concert onsale in October 2019, about 11% of visitors failed the Proof-of-Work challenge, meaning these were bots that had even made it through existing bot mitigation solutions. In another example, Proof-of-Work blocked 39% of users in a January 2020 airline ticket sale.

Our biggest customers helped us improve our product, and then all customers big and small reaped the rewards.

Our biggest customers helped us improve our product, and then all customers big and small reaped the rewards.

4. The centrality of online fairness to our product & users

Core to our development of Queue-it was the idea of online fairness. Sure, our virtual waiting room would help websites and apps stay online when faced with overwhelming traffic. But what’s always driven us is delivering a fair, first-in-first-out experience to visitors online, just like in the real world. No cutting the line, no unfair advantages, and no cheating.

But what’s always driven us is delivering a fair, first-in-first-out experience to visitors online, just like in the real world. No cutting the line, no unfair advantages, and no cheating.

First-in-first-out was a tough nut to crack technically. A FIFO virtual waiting room needs a centralized register of all traffic requests to your website, wherever in the world they come from. A virtual waiting room is certainly not the only website traffic management solution out there. The biggest players in the web performance space have other solutions that don’t focus on a first-come, first-served principle, for example assigning quotas per edge location so that visitors get in faster depending on where they’re located. But we thought FIFO was the right decision, and it’s been a backbone of our platform ever since. 

What’s interesting is that over the last decade online fairness has been one of our biggest competitive advantages. It’s appealed to product managers and ecommerce directors, as well as fans buying concert tickets or sneakerheads getting the latest pair of shoes.

And it’s tied into discussions on the internet more generally. Tim Berners-Lee, architect of our modern-day internet, recently released a “Magna Carta for the web”. In his Contract for the Web, he introduced principles and reforms he feels are critical to ensuring the internet’s existence as a force for good.

He underscores the importance of a web infrastructure based on the principles of fairness and freedom. He fixates on accessibility—making the internet as a whole accessible to everyone, and ensuring fair access to all traffic on the internet (aka net neutrality).

Our decision on first-in-first-out means we’re also able to do our part in ensuring equitable access to websites and apps regardless of an individual’s physical location or technical savvy. In this way, FIFO has not just helped our bottom line, but also helped us contribute to the larger conversation and movement for a fairer internet.

5. That there’s more to a virtual waiting room than putting people in line

Put people in a line. That’s it. Sounds pretty simple, right?

What such a view lacks, however, is an understanding of how important the big picture is.

We knew companies would use our virtual waiting room to offload online visitors from their infrastructure during overload situations. But what we learned is the context and experience of those situations is incredibly important. 

Bot problems

What types of situations frequently experience website overload?

Sales of high-value products, products with high resale potential (e.g., sneakers or concert tickets), and limited quantities of products all generate massive hype and demand.

And what often accompanies such sales?

Bots and malicious traffic.

When we realized the context in which our customers used our product, we realized we needed to expand our abuse and fraud protection. We’ve since dedicated enormous developer resources to this. And now we boast an arsenal of abuse and bot mitigation tools that have become some of our most popular features.

Queuing psychology

When it comes to waiting in line, academic studies show that how we feel while waiting is much more important to the overall experience than how long the wait is.

While this might not seem immediately obvious, it becomes clear if you think about the last time you made a call and were put on hold. Compare your stress level in each of these situations: 1) You’re told what number you are in queue and how long you can expect to wait, or 2) You hear hold music on a loop. Which is more stressful? Situation 2, of course.

In fact, there are well-studied rules that govern how we experience waiting situations:

1. Unoccupied time feels longer than occupied time
2. People want to get started
3. Uncertain waits feel longer than known, finite waits
4. Unexplained waits feel longer than explained waits
5. Unfair waits feel longer than fair waits
6. Anxiety makes waits feel longer

RELATED: The Psychology of Queuing Revealed in 6 Simple Rules

These facets of the user experience might not be thought about if an in-house virtual waiting room is prioritized as a side project. And yet they have an enormous impact. They’re largely responsible for the difference between a basic waiting page and a virtual waiting room.

These facets of the user experience might not be thought about if an in-house virtual waiting room is prioritized as a side project. And yet they have an enormous impact.

With this academic research in hand, we focus on developing robust real-time communication into our platform.

Transparent wait information, like place in line and estimated wait time, shows visitors the wait is finite. A communication pane updated with real-time messages creates an explained wait. Customizable waiting room pages that include embedded videos, games, and content occupy visitors' time. A progress bar shows people the wait has started and reconceptualizes waiting into progress. And by operating under the first-in-first-out principle, we create a fair wait that goes by faster.

We’ve learned that building a functional virtual waiting room entails more than meets the eye. But by dedicating our time, energy, and resources to continuous innovation, we’ve been able to ensure our product delivers value in areas like security and customer experience that are most important to our customers.

We’ve learned that building a functional virtual waiting room entails more than meets the eye.

6. Conclusion

Having our virtual waiting room placed in the primary domain has been key to prioritizing our 150,000+ development hours. It’s served as our guiding compass for what to focus on and allowed us to stay flexible and adapt to shifts in the tech landscape and market.

In the end, building a functional virtual waiting room, as with any product, entails more than meets the eye. It’s a lesson we’ve seen others learn as they tried to build their own virtual waiting room.           

The past 10 years  have been a fun ride, and we’ve come out the wiser for it. We look forward to reflecting again in another 10 years to review everything we’ll come to learn.