Signage content expiry checklist for offline playlists

Why an end date does nothing on a card

A cloud signage scheduler carries a start and end time on each playlist item. When the end time passes, the item drops out of rotation and the remaining items keep their order. Several platforms document exactly this behavior, and it is the clearest single reason to run screens on a scheduler; the offline or cloud signage guide weighs that against a card setup. A card-fed screen has no equivalent. The player reads the card, plays the loaded playlist, and is designed to start it again after a power cut once offline playlist autostart is set up. A date in a file name is a note to a person. No rule on the card applies it.

The failure is quiet. An expired slide raises no error and changes nothing about how the screen looks, which is why lapsed promotions survive for weeks on screens somebody walks past every day. Menu boards carry the sharpest version, because a lapsed price is an offer the staff will not honor; the menu boards that run from a card are where this hurts most.

Before the campaign goes up

Dates set at design time cost nothing. Dates discovered later cost a screen showing the wrong thing. Work down this list before a dated promotion goes live:

• Dates at the source. Write the start date and end date on the campaign sheet the day the slide is designed. One sheet per site, one row per promotion: slide name, start date, end date, screens carrying it.
• The end date in the file name. spring-promo-ends-05-31.png says what the file is months later, when memory has moved on.
• The replacement decided now. What plays the morning after the end date: the next campaign's slides, or the loop with the promotion removed. Name and build that file while the promotion is live.
• Slides built and ordered. Prepare the slides free in a browser with the card builder, and put the promotion where the eye lands in the playlist order.
• Names on the two jobs. One person approves slides and dates, one loads cards. On a small site it is the same person; write the name down anyway.

Example: a cafe with 2 counter screens and a promotion ending Sunday 31 May

Inputs. The promotion ends Sunday 31 May, from the campaign sheet. The site has 2 counter screens, one card each. The review weekday is Monday, once every 7 days. The lead rule gives the replacement card 2 days. The loop holds 3 slides: breakfast menu, loyalty, spring promotion.

Rule in words. Each screen's replacement card is built and checked at least 2 days before the end date, and the swap happens on the end date, after closing. The 2 days are one working day to build and check both cards, and one spare day if a slide fails.

Arithmetic. 31 - 2 = 29, so both replacement cards are built and checked by Friday 29 May. Monday 25 May is the review before: replacement slides exist, dates right, order right. Friday 29 May: build each screen's replacement card, menu and loyalty slides, and check both loops on the office computer. Saturday 30 May is the spare day; a slide that comes up cropped or blank gets fixed with the signage image file troubleshooting checklist. Sunday 31 May after closing: swap the card in each screen. Monday 1 June review: both screens play the new 2-slide loop, and the promotion files move to the archive folder on the office computer.

Result and decision. The loop drops from 3 slides to 2 on the evening of 31 May. The promotion's last advertised day is its true last day, and no screen shows it on 1 June. The threshold to hold: inside 2 days of an end date, the replacement card sits next to the screen. What moves the 2 days is travel, not card count: 2 screens in one cafe fit inside Friday, while a route across five towns starts the visits on the Monday, one town per day, so every card is still checked before its end date.

The weekly review, one fixed weekday

Pick one weekday and keep it, every 7 days, for every screen:

• What is playing matches the campaign sheet, slide for slide and in order.
• Every end date on the sheet is still ahead of today.
• The nearest end date has its replacement card built; inside 2 days, it sits next to the screen.
• Each card carries only the live loop, so the next swap is a clean copy.
• After a power cut or a swap, confirm the screen came back to the playlist.

How long one loaded card keeps a screen playing, and what the player caches between updates, is the subject of offline signage schedule caching.

Several screens and several sites

• One review weekday across every site, so a date never waits on memory. Two screens in one building load on the same visit.
• Label every card with the site and the date it was loaded. An unlabeled card is a card nobody trusts.
• The workflow around expiry grows faster than the playback does: who submits slides, who checks dates, who approves, what is recorded after each swap. On screens that update over a network, plan a remote signage content workflow covers that side.
• Where a site has no network path, updates arrive on a card or by updating the offline screen with a phone hotspot.
• When content changes weekly and no weekly visit can cover the screens, that is the point to move them to a scheduler that expires items on a date.

Recommendation: run this routine on every card-fed screen. Put the end date on the campaign sheet and in the file name the day the slide is designed, build and check the replacement card at least 2 days before that date, swap on the end date after closing, and review every screen on one fixed weekday. Move a site to a scheduler with per-item expiry when its content changes weekly and no weekly visit reaches its screens.

What to send with a quote

When screens come to us on a project quote, send the rhythm with the enquiry: how many screens at how many sites, portrait or landscape, how often campaigns start and end, who loads the cards, and whether someone stands in front of each screen on the review day. Wall, counter and hanging models in the current range are quoted per project, with software, ports, power and warranty confirmed in that quote, so the expiry routine can be written around the hardware you actually get.

Questions