How we count — KPI methodology

This page is the receipt for every number on your InTimeQ dashboard. If a figure on your dashboard doesn’t match what you would compute from the raw events, write to hello@intimeq.com and we will fix either the number or this page.

The metrics on your dashboard

Your InTimeQ org dashboard shows one tile per metric below. Each tile is computed daily in the property’s local timezone and rolled up to the org level. The definitions here apply to every surface — tiles, trend charts, per-property ranking, and operator scorecards.

Hours saved

For every customer who was served, we measure the time the app saved them by not asking them to sit in the waiting area. We take the difference between two moments:

• When the customer tapped “Join” in the app — from wherever they were.
• When the operator tapped “Call next” to call them forward.

The sum of those differences across all served customers is your hours saved for the day.

Edge cases.

• Pre-joins. If a customer joined before the queue officially opened — for example, tapped Join at 8:50 for a 9:00 queue — we measure from 9:00, not from 8:50. The minutes before opening were not spent waiting in line because the line didn’t exist yet.
• No negative values. If our arithmetic ever comes out below zero (rare — it needs clock skew or an unusual sequence of events), we count it as zero. The total only grows when we actually saved time.
• Walk-ins count only if they joined through the app first. If the operator added a customer manually at the counter, there is no “joined” timestamp to subtract from, so that customer contributes zero to hours saved — we don’t credit ourselves with time the customer never saved.

Customers served

A customer is counted once they complete service — i.e., the operator marked them served after calling them forward. Customers who joined but then left before being called, or who were marked missed, do not count.

Both self-joins (scanned the QR) and walk-ins (added by the operator) count, as long as they were actually served. A customer who was re-queued after missing their first call and then served still counts once.

Digital adoption

The percentage of customers who joined through the app, out of everyone who joined that day (self-joins plus walk-ins added by the operator at the counter).

A higher number means more of your customers are using their own phone to join — which is usually what frees your counter staff from the queue-management work.

Walk-ins added

Customers the operator added at the counter by typing a name and phone. These are typically customers who don’t have the app on hand at that moment. We count them fully toward customers served — the operator was still doing the work of running the queue — but they reduce the digital-adoption share.

Active properties and cities

A property is counted as active for a day if it ran at least one queue that day, in the property’s local timezone. Properties that exist in the system but had no queue activity do not count.

A city is counted as active for a day if at least one property in that city was active that day by the rule above.

Timezones

Every daily figure is computed in the property’s local timezone. A customer joining a queue in Mumbai at 8pm is counted in that property’s 8pm slot — not in a UTC slot, not in the org owner’s timezone. When we roll values up to org-wide or platform-wide totals, we sum the per-timezone numbers; we never silently shift a timestamp.

What we don’t count

• Test queues and internal QA traffic, marked as test by the team that ran them.
• Anomalous traffic patterns that we exclude from totals so the figures stay trustworthy.
• Pilot periods before the vendor officially went live.

How to verify your own numbers

Every tile on your dashboard has a drill-down to the underlying daily detail. If a number on this site or on your dashboard doesn’t match what you would compute from your raw events, that’s a bug on our side — tell us.