Console Settingss
- Former user (Deleted)
- Former user (Deleted)
Log in to your company account at https://console.omborigrid.com/
Click on the name of the queue you’d like to edit
The sidebar menu contains links and QR code images for important items related to the Queue app.
Sidebar menu
Queue manager - send this link to staff members who manage to queue
Download Ticket QR code - you can put this QR code on a poster or digital signage, it allows your visitors to join the queue
General settings:
Timezone: Add where the queue is installed
Queue title: The name of the queue, will be shown in the Queue manager and the customer ticket.
External identifier: Used for integration when the Client wants to have any kind of integration.
Show serving tab: Add a step in the customer journey flow. Every ticket will be served by a Queue manager and checked out when serving is completed. Gives serving time in the analytics.
Logo URL: Add your own logo on the customer ticket.
Add brand guidelines with CSS: Enable your design on ticket UI.
Login method
Choose pin code or emails to your users. If you use the email method, add all email addresses that should have permission to the queue in the field.
Settings for ticket UI
Enable registration will reveal the Registration flow, allowing you to collect user information before continuing with the ticket creation for the user.
After choosing what type of field you want to add to the registration flow, press the plus button.
In the input field, you enable the information you want to register
Input Example: You have a coupon and you would like to collect coupon numbers. The number has to have only digits.
Name: The internal name of the field. Used for analytics and integration purposes. Shouldn’t be changed after the queue is created. Should be the same within the tenant so later we will provide the analytics on the tenant level. Example: “coupon-number”
Label: Customer visible name. Example: “Please provide your coupon number”
Placeholder: Customer visible placeholder if no value is specified by customer “12334”
Value: Value that is used before customers specify any information. If customers do not change the value, the value will be used. For example, value is omitted, there is no predefined value for all customers
Validation rules: Applied for checking if the information is valid. Example: Regular expression (Regexp) pattern is specified (please reach technical team to support here).
Required field: The customer has to provide information before the ticket is created
Add field - if you want to add more than one registration flow press the plus button.
Checkbox
Example: You want to ask the customer if the person agrees with the terms.
Name: The internal name of the field. Used for analytics and integration purposes. Shouldn’t be changed after the queue is created. Should be the same within the tenant so later we will provide the analytics on the tenant level. Example: “agreed-with-terms”
Label: Customer visible name. Example: “Are you agree with the terms?”
Prechecked: If the value is preselected or not
Validation rules: Not used for this case
Required field: The customer has to check the checkbox before the ticket is created.
Add field - if you want to add more than one registration flow press the plus button.
Radio
Example: You want to ask the customer to choose one of the options. For example, you are asking which help the customer is looking for, for example, “Customer service” or “Personal support” or “General questions”
Name: The internal name of the field. Used for analytics and integration purposes. Shouldn’t be changed after the queue is created. Should be the same within the tenant so later we will provide the analytics on the tenant level. Example: “question-type”
Label: Customer visible name. Example: “What kind of help are you looking for?”
Options:
Label: what customers see in the UI. For the first case, it will be “Customer service”
Value: Value which will be presented in the analytics and visible to the Queue manager
Validation rules: Not applied here
Required field: The customer has to check the checkbox before the ticket is created.
Phone number/Email:
Example: You want to collect phone numbers/email
Name: The internal name of the field. Used for analytics and integration purposes. Shouldn’t be changed after the queue is created. Should be the same within the tenant so later we will provide the analytics on the tenant level. Example: “phone-number” / “email”
Label: Customer visible name. Example: “Please provide your phone number” / “Please provide your email”
Placeholder: Customer visible placeholder if no value is specified by customer “+46999999999” / “test@email.com“
Value: Value that is used before customers specify any information. If customers do not change the value, the value will be used. For example, if value is omitted, there is no predefined value for all customers. Usually, you do not want to provide it
Validation rules: Applied for checking if the information is valid. Example: Regular expression (Regexp) pattern is specified (please reach technical team to support here). Default validations always will be applied to check that provided value is the phone/email address
Required field: The customer has to provide information before the ticket is created
Will be used for user notification: The Queue system will automatically use collected phone/email for sending notifications if SMS / email notifications are enabled
Categories
Note: please specify Console Settingss | Categories first
Example: You want the customer to select under which Category ticket should be created, for example which type of questions the customer has
Name: The internal name of the field. Already fixed. Used for analytics and integration purposes. Shouldn’t be changed after the queue is created
Label: Customer visible name. Example: “Please choose service the service”
Placeholder: Not applied
Options: Will be taken from the Categories section: Console Settingss | Categories .
Validation rules: Applied for checking if the information is valid. Example: Regular expression (Regexp) pattern is specified (please reach technical team to support here). Default validations always will be applied to check that provided value is the phone/email address
Required field: The customer has to provide information before the ticket is created
General settings
Enable Admin UI ticket printing: To use printed tickets in addition to the mobile-only solution.
Enable check-in by scanning QR code from ticket: This lets the staff manager use the camera on their personal device to check people in, by scanning a QR code on the visitor’s phone ticket or printed ticket. If you have a steady flow of people coming in, you can use this feature to speed up the process.
Customers can cancel ticket: Enable cancellation
Automatically check out tickets when calling in a new ticket (Serving mode and Email login are required): When the Queue manager calls the next ticket in and still has another ticket under the Serving (Serving column) which is assigned to the Queue Manager, the ticket from the Serving will be checked out automatically.
Notify X pending positions*: Notify someone waiting that it will soon be their turn to approach the entrance, based on the number of tickets in front of them in the queue. For example, if only one person is in front of you, you will be called to approach the entrance.
A maximum number of people per general (A-type) ticket*: Set a limit on how many people can register on a single ticket.
Walk-in ticket prefix: You can set a custom prefix label for general (walk-in) tickets. By default, these tickets get the A prefix (eg. ticket number “A23”). If Categories are specified, labels from Categories will be used instead
Admin UI ticket prefix: You can set a custom prefix label for manually issued tickets. By default, these tickets get the M prefix.
Stations (Queue can have multiple stations. Define them here): Enabling stations means that one queue can hold multiple endpoints, for instance, multiple cash registers in a single store.
Custom information for tickets: You can add a custom information text field to your tickets, for examples safety instructions or information to your email, etc.
Auto checks out after minutes (only when the Show serving tab is enabled): if the Queue manager doesn’t Check the ticket out manually, the system will check it out automatically after a specified amount of minutes.
Categories
Enable the categories to registration flow for the customer information.
Example: You want the customer to select under which Category ticket should be created, for example, which type of questions the customer has.
Full title: How the category will be visible to the customer
Ticket prefix: which prefix will be used if the category is specified
Color: which color will be used for the left border of the ticket in the Queue manager interface
(Screenshot how a ticket with a category looks in the queue manager)
Notifications
Enable native notifications on Android using web push notifications for the customer when the ticket is called/rejected / etc
Enable native notifications on iOS devices using Apple Wallet for the customer when the ticket is called/rejected / etc
Enable SMS: Notify via SMS. You will get separate invoices for SMS. If you do not want to have SMS notifications, you should not enable this option.
Get a ticket through SMS
Code – set the keyword (short phrase, like “Q1“ that will be used to create an SMS ticket.
Phone number used for getting a ticket through SMS. Important: it’s not the same number from there customers will be getting notifications
We recommend printing out QR codes for scanning instead of getting through SMS. With QR code no extra costs for the SMS
Set the default phone number country: The country code that will be shown as default when customers create a ticket.
Allowed phone number countries: In case you want to restrict some phone numbers. Used for some specific cases, you don’t need to update this if Ombori provides the phone number for you
Enable email notifications: In addition to text messages and web push notifications, you can also send updates to visitors via e-mail. Should be configured by Ombori team
Email sender: Set the email “from” address for email notifications
From which phone number to send SMS (Sender ID or Sender name): If we have custom SMS notification integrations, we can specify which Sender ID / Sender name we need to use. The exact sender name will be handled by the SMS Provider, we will just provide it for integration purposes from our side. Please reach the Ombori team for support here.
How many minutes before the appointment end should notification be sent: Leave after minutes – if set will notify customers that they should leave the store. We’ll send the message in X minutes after the ticket was created. Won’t notify if not specified. Example of the message which customer receives: Please leave the store now, your time is up.
Send a notification to customers (Minutes before their appointment time is up): Leave a reminder notification after minutes – if set will notify customers in advance that they need to leave soon. Will send the message in X minutes after the ticket was created. Won’t notify if not specified. Example of the message which customer receive: You have {{leaveSoonNotification}} left at {{locationName}}. Please be ready to finish your visit soon
Staff notification
Enable email notifications to staff: add all email addresses that should get a notification. (Email addresses need to be added under Admin → Users). The email service configuration should be provided by the Ombori team or aligned with the Client.
When waiting time is higher than X seconds.
Amount of people in queue is more than X people
How often the emails are getting sent in minutes.
Sms Customization
Enable customization to the SMS notification to customers.
Digital Call - Bambuser
Enable integration to have Digital Call with our Partner Bambuser.
Please reach the Ombori team for support here.
Enable or disable digital call
Agent base URL - received from Bambuser (a page to open a call for agents)
API token - token received from Bambuser to make API calls
Customer URL template - Url which redirects the customer to the call page
Routing timeout - optional parameter, which determines interval time for searching next available agents
Digital call queue type - Default or Global - for single queue/store it should be Default. When we have a queue responsible for calling multiple queues/stores, we should select Global
Global queue ID - when it’s the Default digital call queue type, and you want to have your queue connected to the global digital call queue, then you should type the id of the global queue here.