Due to the special circumstances of 2020 some stores and services have implemented restrictions on the number of people allowed inside at one time. This can make it harder for your customers to get in touch with your staff or get the supplies they need. A solution to this could be a digital queue. By entering their phone number, they could have a queue number and the estimated wait time sent to their phone. This way they could enter the queue, go outside, and be notified when it’s time to enter the store.
We have built a simple version of this workflow that you can download and try yourself via the Workflow Library in the Workflow Builder (“Digital Queue“). This workflow uses two different Synchronized Counters to keep track of the queue number being served right now and what number new registrations to the queue should get.
There are four different flows in the example workflow; queue, next, leave_queue, and reset. The workflow starts on the trigger “Queue” and in our example, we use an Executing Workflow Trigger. This is so that you can test the workflow directly via the WFB interface but this also means that you can run it using a regular REST-API straight out of the box. As the workflow doesn’t know who the message should go to it is important to add the metadata key “phonenumber” and the user’s phone number in the value for this to work.
If you want the users to register themselves using a text message, the trigger could be replaced by an incoming message trigger and a job to get the sender’s contact details added.
When the workflow is executed, we determine a queue number using the Synchronized Counter job. This counter is synchronized across all users and processes on the account. In this way, we can ensure that two recipients do not receive the same number even though the two processes may be started at the same time.
We also retrieve the queue number currently being served by retrieving the value from a second counter.
After the value of these two counters have been found, we send an SMS to the recipient number that was specified in the metadata “phonenumber“. This SMS contains information about which queue number the recipient was assigned, which number is currently being served, and a link to a form for leaving the queue.
When it is time for the next person in the queue to come up to the counter, run the trigger “Next“. Both counters are retrieved and the current number value is increased by one.
We then make a comparison with a Route From Metadata job to ensure that there is someone in line. If there are no more people in line, we reset the counter’s current number to the previous number and no further actions are done.
Assuming the queue is not empty, we get the unit next in line and send a message stating that it’s their turn. In this simpler variant of the workflow, we only send a message when it is the recipient’s turn, but you can build upon this solution and send messages even before it is their turn to let them know that it will soon be their turn.
Leaving the queue is done by submitting the form included in the original message. This triggers the “Leave_queue” trigger. The unit of the respondent is loaded into the workflow, we remove them from the queue, and send a message saying “You have left the queue”.
The fourth and last flow is triggered by the “reset” trigger. It is recommended that this is automated to run every night with the help of a scheduling trigger so that the queue starts at number 1 each day.
This is one example of how we can tackle a problem and allow more people to do what they need to do despite the current situation, but there are many more ideas and solutions to everyday problems that can be achieved with the help of Bosbec WE!
Feel free to use this workflow as a starting point for your own ideas, use Help as a resource to learn how to build, and do not hesitate to contact firstname.lastname@example.org to get answers to questions and thoughts when you build your solutions in workflow builder!Sign up