Most in-room screen pilots are evaluated on content, offer menus and revenue share. The thing that actually kills them is the property network. A Smart TV that cannot reach the internet is a mirror, and a screen that drops off the network mid-stay stops earning for the rest of the booking without anyone noticing. Before a single screen goes on a wall, four network questions need honest answers, and most buildings cannot answer two of them.
Bandwidth per room, not per building
Hotels and short-stay buildings buy internet for the aggregate: one fat pipe, shared. That works for browsing and streaming because those are bursty. Ad-supported screens are different in one important way: they download content on a schedule and need to phone home to report plays. The per-room requirement is small, roughly 2 to 4 Mbps at the moment a screen updates and near zero the rest of the time, but it has to be available at that moment. A building where evening streaming saturates the pipe will have screens that fail their 2am content refresh and serve yesterday's offers all week.
The check is not theoretical. Ask the building for a per-floor bandwidth test done at 9pm on a Friday, not a speed test at the router at 10am. If a screen's update window cannot get 3 Mbps at peak, the refresh schedule needs to move, or the network does.
Guest isolation is the silent killer
Nearly every managed property network enables client isolation: devices on the guest Wi-Fi can see the internet but not each other. That is good security and it breaks remote screen management. A TV sitting on an isolated guest network cannot be reached for updates, health checks or content changes unless someone walks into the room with a remote.
There are three workable answers, in order of preference. Put screens on a separate SSID or VLAN with isolation off between managed devices only. Use a property that offers a dedicated IoT or operations network alongside the guest one. Or accept manual updates via USB or a paired mobile app, which caps how many rooms one person can realistically run. Anything above roughly twenty rooms on manual updates is not an advertising network, it is a hobby.
DNS and captive portals
Captive portals, the login page guests accept terms on, are designed around laptops and phones. TVs handle them badly or not at all. If the property network requires portal authentication per device, every screen needs a pre-authorised MAC address or the network needs a portal exemption list, and someone needs to own maintaining that list when hardware is swapped. Filtering is the second half of this problem: networks that block unknown domains or enforce strict DNS filtering will silently refuse the ad server endpoints. The symptom is a screen that looks healthy and has not fetched an ad in eleven days. Test before rollout by connecting one TV, letting it run a full refresh cycle, and checking its delivery log actually shows fills, which is the same evidence standard we recommend in judging what a pilot should prove.
Power and placement, briefly
Not strictly network, but the same pre-flight checklist: screens need power that does not get switched off with the room. Many properties cut sockets at checkout via a keycard or master switch. A screen that powers off with the room loses its schedule, its reporting and eventually its mind. A socket on the always-on circuit, or the building's written confirmation that media panels stay live, is a prerequisite, not a nice-to-have.
The one-week pre-flight
Run one screen per floor for a week before committing to the building. Record three numbers daily: did it complete its scheduled refresh, did it stay on the network, did it report plays. This costs almost nothing and answers the questions a spec sheet cannot. It also gives you the failure mode in miniature: whether problems cluster at peak hours, which points to bandwidth, or randomly, which usually points to isolation rules, portal re-authentication or a router quietly rebooting each night.
Once the network is boring, the interesting work begins: building the offer list guests actually buy, which we cover in what your in-room screen should actually sell. But the order matters. Content strategy on an unreliable network is a plan to disappoint guests in their living room, and they will remember the blank screen longer than the good offer they never saw.
What to ask the building, in writing
Three questions, emailed to building management before signing anything, and their acceptable answers. Is client isolation enabled on the network the screens will use, and can managed devices be exempted. What is the per-floor contention ratio at evening peak, or if they have never measured it, who owns the network and can a one-week test be run. Is there a portal, and is there a MAC exemption process with a named owner. A management company that answers all three within a day has done this before. One that answers none of them will be the same company that blames the screen vendor in month three, which is why the choice of TV platform should only happen after the network answers, not before.
Buildings that pass the pre-flight cleanly are the ones where screens earn quietly for years. Buildings that fail it usually fail for under a hundred dirhams of network work, which is the cheapest fix in the entire stack and the most commonly skipped.