Ticket State Evolution
During its life cycle, a ticket goes through a series of states, identical for all the APIs used (Booking, Validation, or Display API).
In a complete cycle, the ticket starts with a "booked" state, passes through three or four transient states and ends with a "done" state.
These states are useful for:
- The User: Ticket states inform users of their progress in the queue, either via a notification on the mobile application, or via the Operator.
- The Operator: Ticket states help the Operator track the ticket and perform some actions at the right time, such as changing a ticket state or validating it manually.
All these states are associated to codes in the Lineberty API.
Diagram
Below is a diagram of the evolution of the ticket states in the Lineberty API.
Ticket State Definitions
1st State – Booked
Initial state of the ticket.
A user books a ticket on your system, the ticket is then created.
2nd State – To Confirm
Transient state of the ticket meaning that it's almost the User's turn and that s/he must confirm that s/he is ready to pass (by clicking a button on the mobile application, or by informing an operator in charge of the application).
This state is used only for some specific queues.
3rd State – Alerted
Transient state of the ticket when the User has been warned that it's almost her/his turn. Triggers exit the ticket of the ALERTED status automatically.
4th State – Called
Transient state of the ticket when the User is the next to be called at the endpoint.
In this state, the endpoint name to which the ticket is linked is displayed automatically on the mobile application, and the User can even receive a notification.
The ticket state changes to CALLED either through the triggers or through a manual call of the Operator (in the case of a 3-steps validation process).
On Hold
Transient state of the ticket. The ticket becomes ON HOLD when the Operator suspends it because the User has not shown up at the specified endpoint. The tickets in the ON HOLD state are visible on the endpoint validation interface.
No Show
Transient state of the ticket to which the ticket changes after a given time (settable) in the ON HOLD state.
The change is triggered automatically and the NO SHOW tickets are not displayed on the endpoint validation interface. However, the tickets can still be (manually) validated by the Operator if the User finally shows up.
5tht State – In Progress
Transient state of the ticket, when it is being processed (i.e. validated) by the Operator.
6th State – Done or Canceled
Final states of the ticket.
The ticket state becomes DONE following a validation:
- The ticket has automatically been validated by the triggers (1-step validation process).
- Or the Operator has validated it (2 or 3-steps validation process).
The ticket state becomes CANCELED following a cancellation:
- The User cancelled the ticket manually (on her/his mobile application or by sending an SMS).
- Or the triggers cancelled the ticket automatically, for example because of a too-long delay in the NO SHOW state