The Table Stakes of Digital Signage

tablestakes

“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!

 

 

Dave Haynes

Dave Haynes

Editor/Founder at Sixteen:Nine
Dave Haynes is the founder and editor of Sixteen:Nine, an online publication that has followed the digital signage industry for more than a decade. Dave does strategic advisory consulting work for many end-users and vendors, and also writes for many of them. He's based near Toronto.
Dave Haynes

@sixteennine

Decade-old blog about digital signage and related tech, written by industry consultant and shit-disturber Dave Haynes.
RT @StudioHaloLA: Looking for freelance motion graphics / after fx people to help out in the next weeks on some overflow - let me know if y… - 1 day ago
Dave Haynes

6 Comments

  • Ken Goldberg says:

    Dave:

    I can’t take issue with any of your four points, and there is no doubt that the table stakes have evolved. I believe the points you mention are relevant mostly to what i refer to as the enterprise level and SMB tiers of the signage marketplace. But since we are talking poker, why not go for seven card stud?

    Control of the vision and roadmap: Customers at the enterprise level (and usually at the SMB level) want to understand your roadmap and its fit with their own vision. They also want a feel as to their ability to influence that roadmap. Most companies are able to articulate a roadmap, but it becomes difficult for some when their own progress is dependent upon the strategy and tactics of another company, say for example a screen manufacturer. This is fundamentally why SoC and the ever-changing architectures, OS platforms and strategies that have gone with it have largely failed at these tiers of the marketplace. Customers of scale want some level of certainty where their partner is going. They aren’t buying smartphones with the intent to replace them in two years!

    Licensing options: Flexibility with respect to how a platform is licensed has become important, because no two deals, even in the same market segment, are identical. This can be due to the nature of the organization structure or because there are different income statement and balance sheet ramifications based upon how licenses are handled. For some SaaS is preferred or required. For others, some form of an enterprise license is required, either self-hosted or hosted externally. When you wrap services into a deal, as you mention above, being able to charge for those services if the most efficient manner can have an impact on a deal.

    Financing: The nature of deal sizes at the top tiers of the marketplace almost demand the ability to provide financial options that can accomplish the internal goals of the customer with respect to both cap ex and operational dollars. That could mean having a leasing partner in the ecosystem, or it could mean having the ability to offer hardware as a service, building up front hardware dollars into a long term monthly deal. It could mean creative structuring of a licensing arrangement. But it seldom just means dropping price, it almost always means providing more value.

    The common thread to these three, as well as the four you mention, is the willingness to identify problems and pain points and present a solution. Features and functions are great (and necessary), but we don’t exist on an island any longer and a functional product is not enough. Understanding the unique combination of organizational and functional requirements of a customer will help determine stakes at that table. It is a different game than it used to be, that if for sure.

    • Dave Haynes says:

      great comments … thoroughly agree, though SoC is, I think, seeing some marketplace traction no (agree SW vendors have good cause to be wary of display vendor commitments and architecture).

  • Jeremy Gavin says:

    Support Web Services (HTML5) Well:
    As a content company offering content in HTML, we see the value this media form provides and this value is being under-realized by the fact many providing a package to end users are providing hardware that are unable to keep up with average animation techniques. We also see very little support for local-caching of content – table stakes in my book for companies that call themselves innovative.

    • Dave Haynes says:

      Good points … for caching, are you mostly talking about System on Chip devices and low cost sticks and set-top boxes? Or the CMS software guys?

  • Geoff Bessin says:

    Of the seven and a half table stakes listed, API compatibility and HTML5 support are, by far, the most recent additions. As a result, ‘minimal necessary’ is still being defined. Today, the minimum necessary for API and HTML5 support may be “we give your developers a framework”. But there is no technical hurdle preventing, for example, the person who creates playlists to also create integrations to public/private Web services. It can actually be easy, requiring no special skills.
    I don’t think we’re far from seeing these DS game-changing additions become accessible to all. At that point, they will achieve the same yin-yang of personalization, simplicity and control represented by the other table stakes listed above. Today, I get the sense that many who claim API/HTML5 support to get a seat at the table have really only achieved a minimum that can’t (and won’t) stand for long.

Comments are closed.