Skip to content

How it works

Scan → request → queue → owner → completed.

This is the whole path of one request through Odazivo, with every state the guest and the team see. The views are illustrative, with demo data; the flow matches how the application works.

The complete flow of one requestIllustrative view · Demo data

The path of one request

  1. 0120:41:52

    The guest opens their table's page

    They scan the QR code or tap their phone on the NFC tag. The link already knows the venue, zone and table — the guest chooses and types nothing. The page carries the venue's name, logo and colours, the menu, Wi-Fi and opening hours if the owner has enabled them.

    No app, no account, no sign-in.

    Guest page · Table 12 · TerraceIllustrative view · Demo data
  2. 0220:42:08

    The guest chooses what they need

    Three actions: Call a waiter, Bill please, I need help. The owner decides which are enabled. The server checks the venue, the table and the repeat rules before the request exists.

    The 'sent' confirmation comes from the server, not from the button.

    Request sent · confirmed by the serverIllustrative view · Demo data
  3. 0320:42:09

    The request enters the team's queue

    Every team device with the app open receives the request in real time: table, zone, type, time created, waiting time, status New. If the device allows it, a push notification arrives as well.

    Request queue · team viewIllustrative view · Demo data
  4. 0420:42:31

    Someone accepts

    One tap on Accept. The server records the owner, every other device sees that the request is accepted, and the guest sees Accepted on their phone. Two people cannot own the same request at once.

    Visible to everyone. Owned by one.

    Request status on the guest's phoneIllustrative view · Demo data
  5. 0520:44:05

    The service is completed

    The request's owner presses Complete once the guest has been served. The request leaves the queue, the guest sees Completed, and the times of creation, acceptance and completion stay in the venue's history.

    Meanwhile, Floor Pulse shows which tables need attention most.

    Floor Pulse · the tables that need attention mostIllustrative view · Demo data

Request states

Five states the team sees.

Every request records, when it is created, the response threshold that applies to its type. That is how the system knows when a request is approaching its threshold and when it has crossed it — and says so with words and time, not colour alone.

  • New

    The request has arrived and nobody has accepted it yet.

  • Accepted

    A team member has taken responsibility and is visible as the owner.

  • At risk

    The waiting time is approaching the threshold set for that type of request.

  • Over time

    The threshold has been exceeded. The request goes to the top of the list and is clearly marked.

  • Completed

    The service has been delivered. The request leaves the queue and stays in the history.

At risk and Over time are urgency states — they can apply to a new request and to an accepted one.

The guest page

Fast, in the venue's identity, no instructions needed.

The page that opens after the scan is not an app but a light mobile page tied to the exact venue, zone and table.

  • Venue name and logo, a chosen visual preset or custom colours
  • Page language: Serbian or English
  • Menu from a PDF or an external link, as the venue chooses
  • Useful venue links and contact
  • Wi-Fi details, if the venue enables them
  • Behaviour outside opening hours, if the venue enforces them
  • Only the actions the owner has enabled
  1. 01

    Understandable without instructions and usable with one hand

  2. 02

    Honest confirmation: 'sent' only once the server confirms

  3. 03

    Resistant to accidental repeated submissions

  4. 04

    Secondary to real hospitality — it does not replace the waiter

Guest page · Table 12 · TerraceIllustrative view · Demo data
Request status on the guest's phoneIllustrative view · Demo data

Notifications

Real time while the app is open. Push when the device allows it.

Two related but separate capabilities. The app works even when only one of them is available.

  1. 01

    Real-time updates

    While the team app is open, new requests and status changes arrive without reloading the page.

  2. 02

    Web Push notifications

    When the device and browser support it and the team member allows it, a new request also arrives as a notification on the phone.

  3. 03

    If notifications are not allowed

    The app shows that clearly and keeps working through real-time updates. Nothing is pretended.

Web Push notification · when the device allows itIllustrative view · Demo data

Abuse protection

An open page, a controlled entrance.

A guest without an account creates real work for the team. That is why every request passes server-side checks before it enters the queue.

  1. 01A unique, unpredictable link per table
  2. 02A check that the venue and the table are active
  3. 03Opening-hours enforcement, when enabled
  4. 04Individual actions switched off per venue
  5. 05Muting a table when necessary
  6. 06Preventing two identical active requests from the same table
  7. 07A maximum number of active requests per table
  8. 08A pause before repeating the same request type and a gap between different types
  9. 09A limit on the number of requests within a time window

The exact values are technical venue settings, not a sales message. The point is that the team receives requests, not noise.

Want to see this on the example of your venue?

Book a demonstrationAll capabilities