“Table stakes” is an appropriated term from the card table, used in the business world not for poker bet limits, but on what a company needs to have to really be competitive.
I was asked the other day what the so-called table stakes now in digital signage – those “things” a company must have to be taken seriously as a software vendor or solutions provider.
Interesting question, I thought. And after a little noodling, and here’s how I see the hand dealt:
Device management
If a software platform being sold, or re-sold by a solutions provider, doesn’t have a solid toolset to show the state of all the players, displays and ideally other IP-connected gear that makes a network, then it’s not hitting a baseline of what I think is needed.
If a network operator can’t see what’s going with what could be 100s or 1,000s of players, that’s a rather hellish job. Elemental systems will do the basics like monitor whether players check-in on a schedule with the mother ship server, but the good ones do far more.
Table stakes, to me, are tools that provide a lot of diagnostics and reports and remote access capabilities, and limit rolling a truck to situations that beyond control, like an on-site fire or flood.
User-based Permissions and Approvals
A lot of network operators want the great majority of what’s on screens controlled by only a handful of trained, trusted people. But … they also want to hand off some pedestrian messaging to local operators, with a simple browser-based login and password, and REALLY simple instructions – like TYPE IN THE PRICE HERE.
For example, a national QSR doesn’t want to have head office people sorting out franchise-level local menu variations like the Soups Of The Day. The local manager can do that safely, particularly if there are eight options and the CMS says CHOOSE 4 to display and click on SUBMIT. Done. Those four soups show up on the screen.
If there is an opportunity for local staff to key in messages, a CMS tends to need some sort of notification and approvals chain. So … if the local manager types in “Buy One, Get One Feel” – there’s somebody centrally or regionally who’s going to get an email or other notice saying a new submission needs review and OK. A second set of eyes hopefully fixes the typo and Feel turns to Free.
If messages just go straight to screens with no approvals, that may work out – but it’s risky-risky-risky.
Permissions and approvals seem pretty essential to me.
Turnkey or Ecosystem
Many software companies and solutions providers have marketed themselves as turnkey providers for years and years, though most of it has been bullshit. Two creatives on call and an ops guy who can run project manager software is not a turnkey service. It’s a hack.
These days, just about anyone I ask confirms customers large and small are looking for one vendor, one invoice, one point of contact. They want a single entity to operate their network, so they can stay focused on the core mission of their business or organization.
VERY few companies have the resources to genuinely, properly offer all the elements of a digital signage – from ideation through execution and ongoing management. But they CAN develop ecosystems – tight partnerships with different service providers who can roll up into that one bill.
These days, a company either needs to have the resources to own and run a client, and behave like a master contractor with sub-contractors underneath. Or be an active – repeat active – part of an ecosystem run by some other partner. I don’t mean be a listed partner, among many. But part of a tight team.
APIs
Simply put, if you run a walled garden of software and services that don’t or can’t easily integrate, good luck with that.
These days, being able to work with external data and other management systems – even lighting control systems – is important. The future is not about someone at a desktop plotting out a week or month of digital signage playlists. It’s about data-shaped, directed and triggered content, influenced in near real time by multiple systems.
_________________________
That’s my take. I could also lob into the need to support web services (HTML5), I suppose. What do you think? Use the comments to add your point of view, or if you want to go to town, pitch me on a guest post!