Occupancy Management : Occupancy Apps are the Right Solution
Occupancy Management : Occupancy Apps are the Right Solution
By Gary Angel
|September 2, 2020
Occupancy Apps are the best way to deliver occupancy management – not web-based reporting. Why? It stems from the basic uses of an occupancy management system that make it different than most of the rest of what our tools are used for.
Most of our DM1 analytic platform is delivered by the web. You can use a mobile device to access it, but the experience is limited. Even Google’s truly excellent mobile app for Google Analytics is best seen as a minor adjunct to the full Google Analytics tool – useful for when you absolutely must be away from a laptop. So far, at least, not even Google has figured out how to do deliver good analytics on a small screen.
But when it came time to deliver our real-time Occupancy system, we switched gears and chose Mobile Apps as the primary delivery platform and we switched our entire development environment to accommodate and maximize that choice.
Why?
Occupancy management isn’t really analytic. Sure, our Occupancy Management system features a temperature gauge and a few numbers, but the people using it don’t have to understand analytics. All they need to know is “Green is good” and “Red is Bad”.
The temperature gauge is a simple visual indicator that makes it easy to see if you’re close to a problem or not. The current occupancy – in truth the only really essential number in the whole App – is all anyone actually needs to know. Everything else is just context.
We did build out a short view of the last ten minutes – that’s to help Store Managers understand how rapidly the situation is changing.
But you can use the App effectively without ever even looking at any of that. It tells you when Alert thresholds are crossed – and if all you need to know is when that happens, you don’t even need the bar charts or current occupancy.
What all this means is that for effective Occupancy Management, the important capability isn’t analysis. It’s immediacy. The only thing people absolutely need to know is if there is something they need to do RIGHT NOW. And since there are only a couple numbers involved in keeping track of that (current occupancy, max occupancy, alert threshold), limited screen size isn’t an issue and Apps provide a significantly better Alerting environment than browsers.
In most physical situations, immediacy can only be achieved on a device. Except at cash-wrap, people aren’t constantly in front of a device. But by supporting Android and iOS, we could deliver occupancy on phones, tablets and specialized work devices built on top of Android. Supporting web too just completes the trifecta. It means Managers can have a view in their laptop browser while the system can Alert associates who may be almost anywhere in the building. It also means we can the real-time Occupancy feed and source it into public iFrames so our clients can use it to give information back to their clientele:
This public view is a huge advantage. In these times, Occupancy is public data – and by making it available to shoppers or students, you help people plan their visit and feel both safer and more informed.
Even better, the combination of real-time Occupancy and public views has allowed to us develop extensions for queuing and reservation systems that significantly extend the business capabilities. These systems make it possible for businesses to run virtual cues, to space visits more intelligently, and to manage lines and pickups with aplomb.
Not every part of the Occupancy Management system was built in Flutter or lives in App. We chose to build the Administration function as Web only and used a more traditional development environment. Like analytics, administration is just poor on a Mobile Device. It’s easier to make the admin smooth and robust when you have more screen space and a better typing environment to work with!
As a developer, it’s easy to get wedded to a single environment or toolkit – and there’s good reasons for sticking with what you know. It almost always makes the development process more predictable (and often faster in the initial stages). This is a case where trying something different allowed us to custom fit the tools to the job and has, on the whole, worked out pretty well.