Turn a screen network into sellable media

A channel is something a seller sells through. Every account has a private channel for its own screens. A seller that sells other owners’ screens has a public channel; each screen in it is a listing with a quota (a share of the break slots, or a number of slots per break) and the rights the seller has on the device: status and screenshot by default, reboot, display power or loop switching only when the owner grants them.

The sum of all channels’ quotas on one screen can never exceed the screen’s slots, so two sellers cannot overbook the same break. Products, capacity and the planner treat a listed screen exactly like an own screen; the plan goes to the owner’s device, and every play record carries the listing, so revenue per owner falls out of the same rows as the advertiser’s report.

There is one mechanism, no copies: the owner places the seller’s channel item into its own playlist or schedule, and the listing is created from that act. Removing the item ends the listing; ending it stops the seller’s leases on those screens from the next plan and proposes a make-good to the seller.

Consent per campaign is decline-only: the owner is told what will play on its screens and when, with a countdown to the first play, and can decline with a reason before or after the first play. There is no approve button to wait for, because a waiting click is what stalls campaigns. Owners who prefer standing rules write them once (see “Rules in the owner’s own words”).

A face is created for every device and kept in sync by signals: a changed resolution or rotation, a moved tag or a new display schedule rebuilds the affected plans the same cycle, so a campaign never keeps playing the wrong size on a screen that changed.

The migration sets a break profile per account from the cadence its screens play today, so a network that switches keeps its number of plays; the account can change the profile later without a deploy, and a single screen can be given its own break settings by an admin when a venue needs it.

A customer carries legal name, kind (advertiser, agency, partner, own), company code, VAT number, country, payment terms and contacts; you can create one from the campaign form. A customer page shows contacts, brands, campaigns, lines, plays and pace.

A brand is one record for everybody on the platform, with your own alias if you call it differently. Its advertiser domains and categories feed the competitor check, so a sales house and a venue owner selling the same screen cannot put two car makers in one break by accident.

Each file becomes a creative with a preview and a play button. For every screen size the targeting reaches, the form shows one of: measuring the file, ready, needs a converted copy (press Transcode), converting, conversion failed (try again or upload another file), not adaptable (the file is far too small for the screen). A campaign cannot be scheduled while a creative is not ready for a screen it will play on.

A picture fits every screen type and needs no copy; you set the seconds on screen. For LED strips, old 1366×768 TVs and other non-standard sizes you choose how the file is adapted: fit inside without bars, pad with black, crop to fill, or stretch; the converted copy is a normal rendition and the plan carries the right file for each screen size.

In the campaign form, “Add a variant for a group of screens” lets you upload separate creatives for screens carrying a set of tags. Those screens play only that group’s creatives; every other screen plays the main creatives. Screens matching no group and without a main creative are left out, and the form says how many.

The planner resolves the set per screen when it builds the plan, so the screen receives only the creatives it will play, in its own size.

Rotation decides how several creatives share a line’s plays. Take turns plays them in order; take turns by weight lets you set a weight per creative; story keeps a fixed order across consecutive breaks so a three-part message is seen in sequence; different creatives on synchronized screens shows a different creative on each screen of a synchronized group at the same moment, for a video wall or a row of screens in one aisle.

The engine on the screen applies the mode locally, so the rotation holds even when the connection is down, and every play record names the creative that actually played.

Open it with the Ads button on any screen. It shows whether the screen is online, its player release and break settings in force; the plan it has confirmed (version, number of campaigns, valid until); a newer plan on its way (made, sent, confirmed, refused or replaced); what the player reports (a missed control message, no own content so breaks are timed by the clock, an untrusted clock, files not on the screen yet, play records held back).

The forecast is computed in your browser from the plan the screen holds, with the same engine the player runs: break by break, slot by slot, what plays, and for every campaign that is not in a break, why: outside its time window, paused, daily or hourly ceiling reached, ahead of its pace, no file for this screen type, kept apart from a competitor, break full, a higher-priority campaign took the slots, screen off. Nothing is sent to the screen.

Alerts are raised from what the screens report and from what the plans expect: a plan sent but not confirmed, a screen silent beyond the account’s threshold, a loop so empty that breaks are timed by the clock, a screen whose size had to be assumed, a delivery that falls behind its pace, a screen online that has not played an ad in an hour, a panel off during opening hours.

Each alert carries urgency, first and last seen, and the object it is about; routing (e-mail, chat, webhook) is set per account. The list is the operations team’s morning page and the agent’s input for triage.

Played counts every play the screens recorded; counted only those with the panel on and the device online; due by now is what should have played so far. Open a campaign to see it by screen or by hour, pick the dates and download the CSV. You always see planned and delivered numbers, whatever the billing mode.

Share report makes a link the customer opens without logging in; under planned billing the delivery counts are hidden on that link, under delivered billing they are shown. Every number can be traced to the play records behind it.

Tasks come from three places: alerts that need a person (a plan not confirmed, a delivery behind plan), checks the platform runs itself (a screen without a listing, a spec change, a creative whose licence ends soon), and people. Each task has a priority, an assignee, a due date, a lifecycle from new through assigned and in progress to resolved and closed, and a corrective action.

A task is tied to its object, so the campaign page shows its open tasks and the screen page shows its own; closing a task that came from an alert closes the alert. The agent can open tasks from what it finds, run the safe reads (screenshot, logs) and propose the fix; a person confirms anything that touches a device.

Each customer has a 360 page: master data, contacts, opportunities and quotes, campaigns and their delivery, activities (notes, calls, meetings, e-mails, tasks), documents and KPIs. The pipeline board shows stages with probabilities and cards with value, close date and owner, with flags for an overdue activity, an expiring quote or a suspected duplicate.

A quote turns into a campaign without retyping: the lines, screens and dates carry over, and the campaign keeps the link back to the opportunity. The forecast is the pipeline weighted by stage probability next to the booked campaigns, and it is versioned when a person locks it.

The portal is the seller’s site for its customers, white-labelled per channel. Home lists what needs the customer (an offer waiting for a decision, a creative that needs a portrait version, a campaign that ends in three days) and what is live now. Campaigns show where and when, expected plays, delivery by hour where the billing mode allows it, the creatives with their readiness per screen group, the order and the activity history.

Offers are accepted or declined with a reason, and acceptance is recorded with date, name and page as evidence. Orders show lines, VAT and the invoices with their payment status. An agency sees its advertisers side by side. An assistant drawer answers questions over the customer’s own objects only.

The owner’s shell shows upcoming and running campaigns on its screens with a countdown to the first play, a single action (decline with a reason), the screens with online state and connection details the venue’s IT asks for, documents (consent records, screenshots, listing agreement) and settings for the venue, people and notifications.

Money is a switch per owner account: off, and no amount appears anywhere in the owner portal, only plays and slots; on, and the owner sees earnings, revenue share and statements. Owners who want standing rules instead of per-campaign notices write them in their own words.

For every campaign and billing period the portal produces the billing basis: ordered plays, delivered plays, counted plays, the mode (planned, planned with credits, delivered), the resulting units and the campaign reference. The accounting system issues the invoice; its number and payment status come back and are shown on the order, never typed by hand.

Anomalies are flagged before the export: plays above capacity, a large provisional share, pending make-goods. The reconciliation report compares what was exported with what the accounting system holds, so finance sees one list of differences instead of two spreadsheets.

The owner types a policy as a sentence: no alcohol, no other gyms, no political ads, fast food only after 11:00, nothing with strobes. The platform compiles it into structured rules (categories, competitor sets, time windows, creative attributes), shows them back as cards in plain words, and the owner confirms the version. A test box answers “would this campaign pass?”, and a backtest over past campaigns shows what would have been rejected or sent to review.

Rules are enforced the moment a campaign, a lease proposal or a creative touches the owner’s screens: a hard match (a category, a named competitor, a time window) is rejected with the reason; a semantic match goes to review unless the owner switched on “reject without review”. Every decision is logged with the rule and the evidence, shown to the seller and the advertiser as a reason without exposing other advertisers, and the owner can overturn it in one click.

A policy can only narrow, never force-accept; it cannot override legal or platform rules; the seller’s channel rules stack with the owner’s and the strictest wins. Advertisers can write their own placement policy the same way: never next to another coffee brand, not in the same break as alcohol.

The agent panel is aware of the open record. On a campaign it drafts the plan from a brief (where, when, how often, with two alternatives and the reasoning), explains why a screen is left out, and proposes resolutions for a conflict; on a screen it reads the plan, the device state and the logs and proposes the fix; on a customer it summarises the history and drafts the offer text in the customer’s language.

Proposals are cards: what, why, impact, Accept, Reject, Edit. Anything that books capacity, spends money, pushes a plan, changes a price or sends something outside is applied only on confirmation; reads, explanations and digests run on their own. Every accepted proposal is written as the person’s action, marked as made through the agent, and the panel is fully keyboard operable with live-region announcements.

Weekly, the agent writes a commercial digest from the ledger: campaigns behind pace, customers who have not booked against their usual cadence, offers about to expire, unsold inventory for the next weeks.

Every switchable feature is in one registry with its dependencies and a minimum role. Whether it is on for an account, and for which roles, is data in the account settings; navigation, forms, API fields, the planner and the agent’s tool list all read the same switch, so a disabled feature leaves no trace in a form or a tooltip.

Presets exist for a seller that only needs campaigns and reports, for an owner that only needs its screens and consent, and for the full platform. Switching one feature on also switches on what it needs, and the page says so.

Everybody in the account can read the settings; only an admin saves. Each save becomes a new version with the person, the time and the note; the versions can be compared. Settings merge from the platform default through the account to a tag, a channel, a listing and a line, so a venue or a single campaign can deviate without copying the whole document.

Numbers that steer the platform (break defaults, when a screen counts as sellable, separation gaps, alert thresholds, default billing mode, report limits) live here, not in code; a change applies to new campaigns, and applying it to open campaigns is an explicit, audited action.

Every field and every choice has a help text that answers what it does and what it is for in one or two sentences; derived fields name their source and where to change it. The same text is the tooltip in the form, the description in the API schema and the glossary the agent uses, so there is one wording everywhere.

Tooltips open on hover and on keyboard focus, can be dismissed with Escape, stay while the pointer is over them, and are linked to their control for screen readers. Buttons state their consequence; destructive actions say what they destroy. Countdowns are updated once a minute with a static sentence beside them, so a screen reader gets a date, not a ticking number.

The REST API covers customers, brands, campaigns, lines, creatives, listings, products, plays, alerts and settings, with the field help texts as descriptions, so a generated client is documented out of the box. Sign-in is OAuth with the person’s role; machines get their own client credentials with a scope.

The MCP server exposes the same operations as tools. An agent client is registered with allowed channels and a rate limit; every call is logged with the decision and the object it touched, so an order placed by an agent is as traceable as one placed by a person.

The pre-flight scan reads the account’s current advertising: which clips play as ads, how often, on which screens, by which schedules, and what would block a clean switch (screens without a location tag, shared schedules, loops that are only ads). It writes a report per account with the decisions to take.

Go-live is per account or per screen: the players are updated first, the campaigns are imported, and only then do the screens take plans from the portal. A rollback returns the screens to their previous playlists and schedules in one action and leaves the imported campaigns in place for the next attempt.

A copy of the account on a given date, with every page carrying a preview banner; nothing done there reaches a real screen, and no e-mail or chat message leaves it. The current advertising is imported as campaigns; uploaded videos are converted as in production.

Headless players, one per real screen, fetch the plans, time breaks against real clip durations and send proof of play, so the forecast, the alerts and the reports behave exactly as they will after go-live. The copy is removed after the review.