When buyers compare queue ticketing systems in Kenya, they are usually considering more than a machine that prints numbers. A dependable plan connects the token-issuing point, service selection, customer waiting area, counter calling process, displays or announcements, staff controls, reports and an agreed procedure for faults.
The right arrangement depends on the facility. A small clinic may need assisted ticket issue and a simple calling screen, while a busy bank, hospital or government service centre may have several service categories, floors and counters. This guide explains how to scope the ticket journey and physical components. For the broader software and operating model, see the ZES queue management system guide.
Define what the ticket represents
A ticket may represent a place in one line, a request for a particular service, a confirmed appointment arrival or a step in a multi-department journey. The organisation should define that meaning before choosing a printer or kiosk. Otherwise, customers can receive numbers that staff cannot route consistently.
Choose a token format that gives enough information without exposing personal details. It may use a service prefix and sequence number, but the numbering pattern, reset schedule and duplicate handling need to be agreed. Avoid printing names, phone numbers, diagnoses, account information or visit reasons unless there is a documented operational need and appropriate handling plan.
Choose paper, digital or assisted issue from the user journey
A physical ticket can be familiar and visible, but it needs a functioning printer and consumables. A digital token may reduce paper use, but it depends on an approved joining interface, device access and connectivity. Assisted issue lets a receptionist select the correct service for the customer, though it can create a bottleneck if staffing and desk design are inadequate.
A blended approach may be assessed where different customers or services need different routes. It should not create two unexplained queues. The workflow must specify when each token becomes active, how arrival is confirmed, whether appointments and walk-ins share an order and what happens if a digital or paper reference is lost.
| Issue method | Planning questions |
|---|---|
| Self-service kiosk | Are the service choices clear, accessible and available in suitable languages? |
| Reception-assisted | Can staff verify the need without creating a second long queue? |
| Digital joining | How is presence confirmed, and what is the non-smartphone alternative? |
| Appointment check-in | What reference is accepted, and how are early or late arrivals handled? |
Specify kiosk and printer requirements at model level
A generic requirement for “one ticket machine” is not enough for procurement. Record the expected issue volume, service buttons, touch or non-touch interface, mounting position, customer reach, language needs, paper width, cutter, roll capacity, power supply and connection method. The selected device must then be checked against the software and site.
Agree who stocks compatible paper, replaces rolls and invokes the manual fallback after a jam, cutter fault or unavailable printer.
The equipment schedule should name the proposed model, quantity, accessories, warranty position and support responsibility. Hardware shown in a demonstration should not be assumed to be the final or included model. Its functions, drivers, network method and compatibility need written confirmation.
Design the waiting area, displays and announcements together
A screen helps only when customers can see and understand it from realistic waiting positions. Survey viewing distance, sight lines, daylight glare, mounting height, seating orientation, pillars and separate waiting zones. Decide whether one display can cover the space or whether routing across floors and departments requires several endpoints.
Audio calls may support customers who are not watching the screen, but audio is not automatically included and should not be the only channel. Assess ambient noise, speaker placement, spoken language, volume control and the effect on nearby consultations. A visual-only design can exclude customers with low vision; an audio-only design can exclude people with hearing loss. Staff assistance and an accessible alternative should be part of the operating plan.
Map the counter-calling workflow
Each service point needs a clear way for an authorised user to call the next eligible ticket, recall it, begin service, transfer it or close the outcome. The organisation should define whether a user signs into a fixed counter, selects an available desk or works from a shared device. A display should direct the customer to an understandable location such as “Counter 4” rather than an internal code.
Agree how many times a ticket may be recalled, how long staff wait, and what happens if the customer does not appear. A missed token might enter a short grace status, return under an approved rule or close as a no-show. Staff should not need to invent a different approach during each busy period.
Plan power, network and mounting before installation
Kiosks, printers, displays, media players, calling stations and network equipment require suitable locations, power and connectivity. A survey should record outlet positions, cable routes, counter devices, Wi-Fi or wired-network conditions, available backup and any restrictions on drilling or mounting. Relevant ICT and network infrastructure can be assessed as a separate confirmed part of the project.
Do not assume that every component communicates wirelessly or that existing Wi-Fi reaches the public area reliably. Device-specific network requirements, addresses, segmentation and security controls should be agreed with the organisation’s ICT team. Electrical and mounting work must be assigned to the appropriate competent providers under the written scope.
Write an outage and manual-ticket procedure
A queue can fail operationally even when only one small part is unavailable. A printer may jam, a display may lose power, the network may drop or a calling device may stop responding. The site should have a simple documented procedure for each likely interruption.
Define who declares the fallback, how temporary references are issued, how order and approved priority are preserved, how customers are informed and how events are reconciled after restoration. Keep any manual record limited to necessary information and protect it from casual viewing. Offline ticket issue, local calling and automatic later synchronisation are specific functions; they should be claimed only if the selected solution supports them and acceptance testing proves the intended behaviour.
Test real scenarios before acceptance
A successful test is not just one printed ticket and one screen call. Use a written scenario set that covers opening, peak issue volume, multiple services, simultaneous counters, wrong selection, ticket reprint, recall, no-show, transfer, desk closure, paper replacement, power interruption, network loss and end-of-day reports.
Compare quotations on total responsibility
The visible kiosk and display do not represent the whole cost. A quotation may need to separate discovery, software, licences, custom configuration, printers, kiosks, screens, mounting, network or power work, consumables, integrations, training, travel, warranty, support and taxes where applicable.
What ZES can assess
ZES can assess the ticket issue point, counter layout, display and audio coverage, mounting, network and power readiness, accessibility needs and manual fallback. The exact kiosk, printer, display, calling device, software, consumables, licences and maintenance responsibilities remain model- and site-dependent and must be listed in the written scope.
For discovery, provide the facility location, services, expected daily and peak volumes, issue methods, counter count, waiting-area layout, accessibility needs, operating hours, existing screens or printers, network and power conditions, report expectations and required interfaces. Photographs and a floor plan can help identify survey questions, but they do not replace on-site verification where installation work is proposed.
Frequently asked questions
Does every queue ticketing system need a paper printer?
No. Paper, digital and assisted issue routes can be assessed. The choice should reflect customer access, the service process, connectivity and the required fallback rather than an assumption that one method suits everyone.
Can an existing television be used as the queue display?
Possibly, subject to compatible inputs, resolution, control method, placement, operating condition and the selected software or display device. The exact model and connection should be checked before reuse is included.
Will a system work when the internet is down?
That depends on the selected architecture and components. Local or offline functions must be specified and tested; they should not be assumed. Every site still needs an agreed manual contingency.
Can the ticket show a customer’s full name?
It may be technically possible, but it is often unnecessary and can expose personal information. Use a neutral token where it meets the service need, and confirm any identity fields, access and display rules during discovery.
What should be included in the handover?
Request the confirmed equipment and licence schedule, configuration record, user and administrator guidance, acceptance results, consumables instructions, warranty details, support contacts, exclusions and any agreed maintenance responsibilities.
To plan a queue ticketing system in Kenya around your real customer flow and premises, request a scoped ZES quotation. Include the locations, services, volumes, counter plan, issue method, existing equipment and infrastructure so the proposal can confirm each component and responsibility.