Smart ETA: a trainer lesson

Edition 1.1 | 22 October 2026 | For owners, reception teams and technical readers

Start with these three different times

Imagine a patient reaches reception at 10:00, starts consultation at 10:20 and finishes at 10:30.

ETA means Estimated Time of Arrival in general usage. In InCue's queue screens, read it as estimated time until your turn/service can start. It is not the time by which the work will be finished, an appointment guarantee or the amount to collect.

Trainer's line: “Avg time mein ek customer ka kaam shuru hone se khatam hone tak ka usual time dalo. Line mein khade rehne ka time mat dalo. ETA batata hai bari lagbhag kab aayegi.”

Why the service duration matters

When the business has little usable history, InCue needs a sensible starting estimate. Enter the usual working time for one service: for example Consultation 10 minutes, Haircut 20 minutes, or Vehicle handover 5 minutes. These are teaching examples, not recommended times for every business.

Watch several ordinary visits and estimate the typical time from Start to actual finish. If five consultations take 8, 10, 12, 9 and 11 minutes, their simple average is 10 minutes. Enter 10, not 10:00, 600, the doctor's full shift, a day's total workload or the patient's current wait. The current service form accepts whole minutes, at least 1; a new form starts at 15.

If a usual ten-minute consultation is saved as 30, early estimates can become too late. If a normal thirty-minute repair check is saved as 5, estimates can be too optimistic and unusually long samples may be excluded from learning. Start with an honest normal duration; do not deliberately shorten it to make the queue look fast.

Quick check: open Services, read each active service name and its Avg time aloud: “One normal [service] takes around [minutes] after we start.” If that sentence sounds wrong, review the value.

What Smart ETA considers, in everyday language

The engine builds an estimate of the work ahead of a waiting token. It considers the selected service(s), usable completed-visit timings, recent operating speed, called/serving work, queue priority/order, counter compatibility/capacity, and the saved business schedule.

1. Choose a working duration for each service. With no usable history it falls back to the configured duration. With history it gives more weight to recent completed work, while retaining part of the configured value.
2. Check how today is moving. Enough valid recent completions can make the working estimate faster or slower than its historical baseline.
3. Account for work already called or serving. A called person still needs to arrive and receive the service. A serving person still occupies a counter; elapsed time helps estimate what remains.
4. Place waiting work ahead on eligible counters. Emergency-priority work is considered first, then token number order. Different compatible counters can work in parallel; a worker who cannot provide the selected services is not interchangeable with one who can.
5. Apply operating time. If the work crosses a saved lunch break or closing time, the expected turn can move to the next working interval.
6. Show an estimate with uncertainty. A range communicates that real services vary. A longer queue or limited history can produce a wider range.

This is an estimate from recorded operations, not a sensor watching the doctor, mechanic or customer. It cannot know an unrecorded absence, a conversation after work, a missing staff member still marked available, or an unexpected job complication until available data changes.

A clinic example you can explain at reception

Assume one counter, no break, no emergency work, no speed/no-show adjustment, and a working service estimate of 10 minutes. These assumptions isolate the arithmetic; a live account can give a different range.

If reception completes the active consultation earlier, the next calculation can reduce waiting estimates. If a more complex case continues well past the usual duration, the engine can allow additional remaining time rather than claim the counter is already free. Complete should therefore mean work actually ended.

What to tell the patient: “This is an approximate turn estimate. It can move if an earlier consultation takes longer or an urgent case is added. Keep your token and follow the live status.” Do not promise an exact minute from a range.

Two counters, different services and long jobs

Two genuinely available haircut workers: waiting jobs can be distributed across compatible capacity. Two workers can reduce the wait, but not always by exactly half because jobs have different lengths and one worker may already be busy.

Clinic doctor and lab desk: a lab worker is not a second consultation counter just because both are online. Map their real services. In service-aware routing, a counter must cover the token's full selected service set. Where no full matching counter mapping is available, the estimator can fall back to configured virtual capacity; that fallback is an estimate, not proof a real eligible worker is available.

Service centre repair plus washing: multiple selected services contribute to estimated work. The system does not automatically prove that repair and washing happen in parallel. Use service definitions that describe the work you actually run. A week-long workshop job should not be modelled as a five-minute quick counter service just to shorten the displayed queue.

Held / Cancelled / No-show: these do not occupy an ordinary waiting position in the live waiting-list simulation. A held customer's later return can affect the queue again. No-show probability adjustment and actually marking a token No-show are different things; see below.

Lunch, closing time, Pause and Resume

Saved break example: it is 12:50, the work ahead needs 30 working minutes, and lunch is 13:00-14:00. There are 10 working minutes before lunch and 20 after it, so the central expected turn is around 14:20, before any range variation.

Small spillover exception: the schedule helper allows up to 10 remaining working minutes into an ordinary break if some work in that calculation was already consumed before the break. For example, 12 minutes of work from 12:50 can estimate 13:02 instead of jumping past a one-hour lunch. This models a short wrap-up, not a promise that staff will skip lunch. It does not apply when the calculation starts inside an already ongoing break, or to a configured hard scheduled pause. Ask reception if the displayed turn is near a break boundary.

Closing example: a wait longer than the workable minutes left today can continue into the next selected working day. A 0-minute work backlog outside an open interval can still be scheduled to a later opening. Correct hours matter even with an apparently empty queue.

Manual Pause: there may be no known end time, such as the doctor being called away. The ETA formatter switches to a paused message, and optional ETA WhatsApp messages are suppressed while paused. Other screens may still retain their last number or show their own paused state. Do not tell customers a live countdown proves work is progressing during a pause.

Resume: the engine has a short return-to-work allowance: source defaults add 3 minutes during the first 5 minutes after Resume. It allows staff time to get back rather than assuming immediate service. This is a server rule, not a merchant slider verified in the app.

Closing intake is different: Accept walk-ins controls new intake; Pause concerns the current queue. Neither button is a substitute for saving the real daily hours and lunch breaks.

What changes automatically, when and why

Automatic no-show is not the two-minute called allowance

The ETA calculation allows 2 minutes for a called customer to approach, then includes the service and transition work. This two-minute allowance does not itself mark the person absent.

The separate no-show job has a source default of 10 minutes since Called, checked on a default two-minute schedule, and requires the merchant's explicit backend opt-in (autoNoShowEnabled, default false) as well as the server job being enabled. Therefore it is neither on for every merchant nor guaranteed to run at the exact ten-minute second. It does not automatically mark every old Waiting token absent. Do not tell a customer “after two minutes your token is cancelled.”

Appointment conversion is not an exact appointment-time promise

The source includes an every-minute eligible-appointment job and an on-demand catch-up before ordinary token creation. It compares the projected queue serving time with the appointment start, with a past-due safety path. Only eligible active appointments are candidates; completed/cancelled/already-converted records do not become new tokens again through the ordinary conversion path. Failed conversion has bounded attempts and needs attention if it cannot recover.

This is a separate conversion scheduler using its queue projection; it is not a promise that every Smart ETA range, calendar slot and WhatsApp time is identical. Staff should inspect the generated token when checking in a customer. Do not create a second walk-in solely because the appointment view has not refreshed.

WhatsApp: when a waiting customer may hear from InCue

First understand calculation versus communication: the displayed estimate can change without a new WhatsApp. Message selection deliberately avoids sending on every small change. It can be skipped for a closed/paused token, recent messages, uncertain shifts, exhausted optional budget, contact/withdrawal restrictions, wallet or provider failures.

Deployment configuration read on 22 October 2026: the ETA alert job is scheduled every 5 minutes. The deployed ETA/notification source hashes matched the source reviewed for this guide. The following values are configuration evidence, not a promise of scheduler uptime, successful delivery, a per-account grant or a permanent timing contract. They are server controls; this guide does not invent Merchant settings for them.

Each reminder window has a configured plus/minus 4-minute tolerance, requires a positive remaining wait, and can be missed if work changes suddenly or a job/check cannot run in that window. The plan is based on the original estimate, not a request to send all four reminders to everyone. Source fallback for the long-wait boundary is 60 minutes; the inspected deployment overrides it to 120. Do not copy the source fallback as the active deployment value.

You're next: considered first when no eligible waiting work is ahead and ETA is 25 minutes or less, subject to cooldowns, deduplication and budget. Being first in Waiting does not mean a busy counter has finished; this message does not call or start the token.

Delay / earlier-turn changes: small variations can be silent. The inspected deployment uses a 20-minute delay threshold and a 15-minute earlier-turn threshold, together with a 10-minute smoothing/range buffer, at least 15 minutes useful notice, confidence and decision checks. An extremely large early jump above the source's 90-minute plausibility limit is suppressed. A large numerical change alone does not guarantee a message.

Avoiding repeated messages: the inspected deployment has a 10-minute optional-notification cooldown and a separate 3-minute conflict window. Normal reminders, early updates and delay updates have additional duplicate/sequence rules. After a delay, a final around-15-minute reminder may qualify; a routine final reminder after an early update is disabled in this deployment. After an ordinary reminder, the normal selection path does not promise every later shift update; “You're next” has its own earlier priority check.

Budget: source/configured maximum is 6 customer messages per token in the ETA budget policy, with a target of 4. That is an internal policy target/cap for the tracked flow, not a bundle promise or a guarantee of four deliveries. Optional ETA sends reserve room for later core service/feedback events. Appointment, transfer and other message classes have their own paths; do not treat this number as a universal global cap on every communication. A failed provider attempt does not intentionally consume a successful-send slot permanently.

Called / serving / completed: ETA waiting notifications close when the token leaves the relevant waiting phase or the serving update closes the notification state. Event-based call/serving/feedback messages are separate. A TV announcement uses its own settings and the TV's unlocked audio, even if WhatsApp is disabled.

Technical notes: what the current implementation actually does

These details are for administrators and developers. Owners can operate correctly using the examples above. Tuning values below are source defaults unless explicitly labelled deployment overrides; they are not additional customer-editable fields.

Historical duration and current speed

• Historical profiles inspect up to 120 recent completed tokens within 90 days of the merchant, with a real serviceStartedAt. Samples below one minute are excluded. A sample above max(3 minutes, 3 x the configured service duration) is excluded for that service.
• The service baseline is 60% average of up to the latest 10 usable samples + 30% average of up to the latest 30 + 10% configured duration. The sets overlap intentionally; it is not 40 separate visits. With no usable history, use the configured fallback. Missing-service/global fallback can be 15 minutes.
• A historical multi-service token's entire elapsed visit can be attributed to each included service. This is a limitation: it does not measure separate per-service stopwatch segments and can overstate combined work. The live-speed per-service attribution is stricter and uses single-service tokens only.
• Today's speed compares actual versus baseline duration for up to 50 completed tokens in the last 60 minutes, within today's date, needing at least 3 usable samples. Valid actual elapsed time is 1 minute to 4 hours. A per-service factor wins with enough single-service samples; otherwise the global factor applies. The factor is clamped to 0.5-1.8 times baseline, so an outlier cannot scale it without bounds.
• Historical profiles cache for about 5 minutes; speed profiles for 60 seconds. Config/service/queue invalidation paths and cache availability can affect freshness. A newly completed visit is not a guarantee of an immediate visible recalculation of the learned profile.

Active work, priority and uncertainty

• Called work contributes its estimated service time plus 2 minutes to approach and a 1.5-minute transition. That arrival allowance is not a no-show timeout.
• Serving work uses elapsed time and a minimum remaining allowance (source defaults 3/5/10 minutes for short/medium/long work). When overdue, a ramped/proportional extra estimate is capped at twice estimated duration. It is deliberately not a stopwatch countdown to guaranteed zero.
• Waiting contributions include service duration plus 1.5 minutes transition. Emergency tokens sort ahead of ordinary work; otherwise token number sorts ascending. The target's own service duration is not added to its pre-service waiting time.
• Active service-aware counter mappings include linked active busy staff, or online/available staff accepting work, with compatible services. Where a matching full-service pool is unavailable, configured concurrent/virtual capacity can be used; it does not prove physical availability. Increasing a capacity number must not replace correct staffing.
• No-show history uses completed/no-show outcomes in a 30-day lookback, at least 10 outcomes and a default 40% probability cap. Its expected-work discount applies only to ordinary waiting entries from the third eligible position onward, not the first two or emergency work. It does not change those tokens' real statuses or declare any particular customer absent. The rate cache is 5 minutes.
• Confidence is a heuristic: at least 20 usable samples across the inspected service profiles with fewer than 10 ahead can be high; fewer than 5 samples or more than 20 ahead produces low confidence. Otherwise it is medium. Paused queues force low confidence. This is not a certified statistical confidence interval.
• Ranges use 5-minute buckets by default. Width is at least 5/10/15 minutes for high/medium/low confidence, and can widen with the wait (12%/20%/35% rounded to buckets). Business schedule adjustment applies to the range endpoints. Notification smoothing may keep the last displayed range while a new raw value remains within it; ordinary live queue overlays do not necessarily use that notification-state smoothing.

Sources and boundaries for maintainers

Reviewed paths: services/queue.service.js (duration profiles and intake projection), services/eta.service.js (live simulation/ranges), services/queue_snapshot.service.js (ETA attachment and sync), services/eta_notification.service.js (gates and message policy), services/auto_skip.service.js, services/staff_assignment.service.js, services/appointment_auto_generate.service.js, and the related jobs/scheduler. Server configuration was inspected with an allowlist of non-secret timing flags; no customer records or settings were changed for this training revision.

The intake/appointment projection and live existing-token engine are separate code paths. Do not promise identical estimates before issuance and after the token joins the live queue. The accepted token's current live status and tracking estimate should be explained to the customer.

Train your team in five minutes

1. Ask: “Does Duration mean time in line or time doing the work?” Correct answer: doing one customer's service after Start.
2. Give a ten-minute example with two people ahead. Ask why the wait can be longer than ten minutes and why two compatible workers can help.
3. Ask staff to demonstrate Call, then Start, then Complete and explain the physical moment each represents. Do not trigger a real charge just for a demonstration.
4. Explain the lunch example and when to Pause versus close intake.
5. Ask: “If ETA changes, must a WhatsApp be sent?” Correct answer: no; timing, material change, confidence, cooldown, budget and delivery conditions apply.

If ETA looks wrong: check the token's status, current connection, service durations, forgotten Serving work, real staff availability/service mappings, saved hours/breaks and pause state. Confirm whether you are reading waiting time or expected clock time. Record the token/reference, IST time and a redacted screen if the discrepancy remains. Do not shorten every service duration or mark unfinished work Complete to force a pleasing number.