Freebee end-to-end flow

Who does what, in what order, from an advertiser signing up to the report the next morning. After the main flow: the links and logins, the metrics we collect, the booking flow, bidding for busy windows, what happens when something fails, OTP and coupons, upload rules, where AI fits, the native player for Android, Windows and Mac, and how we talk to the advertiser. Anything marked proposed is not built yet.

The flow

Ops can add and pair screens at any time; an ad only reaches the wall once it is approved and booked. The highlighted boxes are the Hit for Six loop in the mall: the wall shows a QR code, the shopper gets a code on their phone, enters it at the kiosk, rolls the dice ball by ball, and a prize lands in their phone wallet. The camera and the play record count everything, and both the advertiser's report and the ops Today page fill in the next morning.

Links

Everything runs at https://freebeeads.com. The demo campaigns are booked on the screen "Escalator Court — North Portrait".

Logins: demo advertiser demo@dooh.local / demodev123; ops ops@dooh.local with the ops password shared one to one. Friends can also sign up with their own email (password of 8 characters or more, plus a business name). There is no password reset yet.

Metrics we collect

Every number comes from one of three sources: the play record written by the screen, the camera on the screen, or the game itself. Nobody is identified; the camera keeps counts only and the phone number of a wallet user is stored encrypted and never shown to an advertiser.

Numbers land in the dashboards the next morning for the previous day; Live right now and Playing now update every 5 seconds.

Booking flow

There is no bidding: every screen has a fixed rate per slot per day set by ops, and an hour window costs its share of the day. A game ad holds its window exclusively (one brand on the wall at a time); a video or image ad shares the loop. The booking can be cancelled before it starts and future dates are freed; a booking that has already played cannot be cancelled from the portal.

Bidding for busy windows

Today every window is first come, first served at the fixed rate, which is right for most screens and most days. On a main screen on a busy day (weekends, Diwali week, a mall event) several brands will want the same evening hour, and the first click should not decide it. The proposal keeps the fixed rate as the floor and adds a short, sealed bidding round only where ops turn it on.

What the advertiser sees: the hour grid marks busy windows with the floor and the current high bid, and the booking summary rail shows "Bid ₹X, closes Fri 18:00" instead of a fixed price until the round closes. Ops see the open rounds on the Bookings calendar with the bidder count. Messages on close go out through the channels in "How we talk to the advertiser".

When things fail

The rule behind all four rows: a number that was never measured shows as a dash or a labelled sample, never as zero, and a play that was never recorded is never billed. The gap today is reach, not detection: ops only learn about an offline screen when they open Today, and the advertiser only when they open Home. The proposed push messages in "How we talk to the advertiser" close that gap.

OTP and coupons

The one-time code is the only moment we ask a shopper for anything personal, and only because the coupon has to live somewhere they can find again. The number is kept as a hash plus an encrypted copy, used for nothing else, and a shopper can erase their wallet from the /w page. Codes are minted on the server and expire in minutes.

What is not connected yet: the SMS or WhatsApp sender. On the test site the code is shown on the page itself so testers can continue. Before launch, delivery goes through WhatsApp Cloud API with SMS as the fallback, and the test shortcut is switched off. Daily prize budgets per tier ("max wins per day") already cap how many coupons a campaign can hand out.

Upload rules

A file is checked the moment it is uploaded, before anyone sees it. A wrong file is refused with one plain sentence and nothing is saved; a file that passes goes to our team for approval.

Proposed, not built: convert common mistakes instead of refusing them. A .mov or .webm is transcoded to mp4; a 15 s video is offered a 10 s trim with a preview; a landscape video is offered a portrait crop; an oversized image is resized. The message then reads "We converted your file to the screen's format; check the preview" with a side-by-side before and after.

AI in the flow

What AI would do for an advertiser: take a phone photo of a product and return a clean, upright, 9:16 image with the background removed; turn a 10 second video into a mock-up of how it looks on the wall; suggest three headlines from the brand name and the product. Each suggestion is shown beside the original and the advertiser picks; nothing is applied silently, and our team still approves the final ad.

What AI would do for the wall: catch the names the block list misses, such as slang spelt in English letters, a brand or a real person's name used as a joke, or a mixed Telugu and English phrase. The block list stays as the first, instant check; the AI check runs in under a second behind it. A blocked name always gets the same message as today, and nothing typed is kept beyond the innings.

The game footage itself (bowling, batting, the dice) is generated once by us and shared by every cricket campaign; sponsors add their packs and logo on top. A proposed extension is a per-brand pack render, so a new sponsor's pack appears on the shelf without a designer.

Native player instead of a browser

A browser tab works for a demo but fails in a mall: it needs someone to open it, it can be closed or navigated away, it cannot start on boot, it loses the camera permission after a reboot, and a wifi drop stops the loop. The app wraps the same web engine (one codebase, the same play record format), so the server and dashboards do not change and the browser player keeps working for tests.

What the app does that the browser cannot: start itself after power loss, keep playing from its cache for hours offline and upload the queued play records afterwards, restart the engine if it stalls, pull engine updates in the night, and report its health (temperature, disk, camera) in the check-in. Pairing stays the same six-character code shown on the screen and entered in Ops, so nothing changes for the ops person. Build order: Android first (one app covers the wall box and the kiosk tablet), then Windows, then Mac.

How we talk to the advertiser

Today every message lives inside the dashboard: a status badge, an alert strip, or a note under a number. Nothing is sent to the advertiser's phone or email yet, so an advertiser who does not open the site does not hear about an approval or an outage. The proposed channels add WhatsApp first (the market's default) and email as the record.

Ops are told the same way today: alerts on Today and badges on Approvals. The proposed ops channel is a WhatsApp group fed by the same alerts, with offline screens first.

What is still missing

The flows above are the product. A mall-screen business needs the pieces below too, and most of them are not started. Ordered by what blocks a real paying launch first.