Same-day footfall
Entries by hour, in time to change the shift.
A store view of footfall, stock and stockouts the manager can use the same day.
A store manager sees same-day footfall, what is out of stock, and where people stop. Membership only links a visit to a purchase.
Footfall arrives next week, too late to change the shift or the display
Book stock and the shelf disagree at the till
Nobody knows where people stop, so display changes are guesses
The member system has fields that do not match today’s trade
Keep the equipment you have, connect the data first, then split the views by role. The connection layer takes the most work, and it is where most of our effort goes.
PLCs, meters, access control, cameras and sensors already on site. Read what is readable, add a module where it is not, and leave the existing control system alone.
Modbus · OPC UA · MQTT · HTTP · GB28181 · SDK
Common protocols connect directly. The gateway handles protocol mapping, local buffering and backfill, so the data does not break.
Device registry, time-series data, alert rules, work orders, roles and audit in one back end that serves several scenarios.
Data is collected once and reused by every scenario added later, which is why the connection layer has to be done properly the first time.
Entries by hour, in time to change the shift.
Items under the store’s own level are listed before the till finds them.
Zone dwell shows which area is busy. It is not a surveillance story.
When a member can be matched, the visit and the purchase sit together.
Not a feature list: what actually happens in a day. These four steps are the common shape of such projects.
A cold case reads high at opening; the dairy section is flagged on its own.
The manager moves stock per the guide while the service ticket goes out.
Case faults enter store scoring, and head office sees the comparison.
Every stage has a checkable output. No six-month build followed by a single review.
Walk the site, list devices, available ports and current systems, and mark what reads directly versus what needs a module.
Rank the ideas by impact, feasibility and dependencies, then choose one that proves value without dragging in every department.
Gateways connect devices, data lands on the platform, and alert rules, roles and recipients are configured for a small internal group.
One team or one building uses it for real; rules and screens change with feedback until false and missed alarms settle.
Check every acceptance item, finish documentation and training, then decide which buildings, lines or sites come next.
The three items below come from projects of this kind and go into the acceptance sheet, instead of relying on a general impression.
Footfall is available the same day
Stockouts are on a replenishment list
Display changes map to a busy zone
Footfall arrives next week, too late to change the shift or the display Book stock and the shelf disagree at the till Nobody knows where people stop, so display changes are guesses The member system has fields that do not match today’s trade
Same-day footfall: Entries by hour, in time to change the shift. Visible stockouts: Items under the store’s own level are listed before the till finds them. Where people stop: Zone dwell shows which area is busy. It is not a surveillance story. Visit and purchase: When a member can be matched, the visit and the purchase sit together.
Footfall is available the same day Stockouts are on a replenishment list Display changes map to a busy zone
No. The platform reads through interfaces or gateways and the existing systems stay in use. Only modules nobody maintains are worth replacing.
Priced by scenarios and device connection points: a site survey produces the list, then a quote and schedule. Most projects have a first scenario live in four to eight weeks.
Leave one contact. We send how similar projects were handled plus a scenario list. If it is not worth doing, we say so.
Phones are answered 9:00-18:00 on weekdays, or scan the WeChat code.