Article
Intermarché: the first customer numbers, and what went wrong.
This Intermarché was our first customer, and we say that with gratitude. Trusting a new system with something as sensitive as the hours of the people who work there is no small favour.
Every number in this article comes from the production database, counted case by case, with the period beside it. There is not a single brochure average here.
The starting point: a card that only spoke at month end
Before us, the store had the classic setup: everyone with a card, swiped on the way in and on the way out. The card was not the problem. Everything around it was, and above all when you got to find out.
| What you saw | Where the problem was |
|---|---|
| Clock-ins only checked at month end | Errors found weeks after they were born |
| Frequent misses, sometimes deliberate | Without daily validation, forgetting pays off |
| Cards swiped by colleagues | A card proves the card was there, not the person |
| An accounting close of 1.5 to 2 days | Fixing clock-ins by hand, Excel, CSV, and only then the payroll software |
The close deserves a description, because that is where the cost piles up. At the end of every month, the accountant took the raw clock-ins and fixed them one by one: misses, swaps, exits with no record. Then Excel. Then CSV. Then absences, holidays and sick leave. And only then the payroll run. Between 1.5 and 2 days, every month, to rebuild by hand what the system should have recorded correctly in the first place.
And there is a cost that shows up on no ledger: when the record is weak, it fails in both directions. An employee can take advantage of a manager being away; a manager can take advantage of a missing punch to argue about hours that were owed.
The installation: one day per store
Development of the camera recognition started in early July 2026. The physical installation took a single day: the terminal, the pair of cameras and the mini PC that processes everything locally. With the experience we now have, each station takes one to two hours.
We took longer. The reason is in the section on what went wrong, because it was the very first thing to go wrong.
August 2026 payroll has already been processed with our software.
The numbers
| Metric | Before | September 2026 |
|---|---|---|
| Visibility of clock-ins | At month end | Same day |
| Records processed per day | Not measured | 514 on average, peak 649 |
| Hours close, per month | 1.5 to 2 days | 3 to 4 h |
| Manual corrections at close | All of them | 1 |
The 3 to 4 hours of the first close include the initial software adjustments. That is the ceiling, not the average.
How many missed punches the camera actually catches
It is the question that matters to whoever runs the place, and the only answer worth anything is the one counted case by case. Here it is, missed punch by missed punch, across the two months the system has been in production.
| Clock-ins | August (31 days) | September (1 to 15) |
|---|---|---|
| Recorded | 2,052 | 856 |
| Missed | 56 | 21 |
| Filled by the camera | 32 (57%) | 18 (86%) |
| Corrected by a person | 21 | 1 |
| Still open | 3 | 2 |
Twenty-one human corrections in August. One in September. This is not start-up tuning, it is the system doing what it was built for, and doing it with cameras we deliberately chose worse than the ones available, because we traded image quality for data security and installation cost. Eighty-six per cent with the hardware held back. Better hardware is already selected for the next installation, and this is exactly the number where we expect to see it.
We publish the 2 cases still open for the same reason we publish everything else: a number that does not admit its own holes is not a number, it is advertising.
Duplicates, which the old system could not even see
The same person swiping twice by mistake. On the old system it was one more case for the accountant to find and clean up by hand at the close. Now they are resolved the same day, with no intervention: 8 in August, 2 in September, and none reached the close.
What went wrong
Two true episodes, chosen because they taught us the most.
The cameras arrived misconfigured from the factory. We found out on installation day, with the team in Braga and the office in Lisbon. Driving up and back just to reconfigure cameras made no sense, so the fix was local: a colleague there configured them and the next day everything was running. Today, building every installation so that everything is reachable and fixable remotely is part of our standard. When an error shows up, and it will, we do not know in advance where it is; what we guarantee is not needing 700 kilometres of road to go and look.
Wiring the cameras to the cards was a serious headache. It looked like a detail and became the most customer-specific piece of the product. It cost weeks of tuning, and it is still being tuned. Anyone who tells you this integration works out of the box, without knowing how the store runs, is selling you a demo.
Where the data lives: not one pixel leaves the store
This case involves facial recognition of workers, and we do not write about it without saying where the data lives. The answer fits in three sentences.
There is not a single pixel of a face stored anywhere: the image is immediately converted into an encrypted template by an irreversible algorithm. All video processing happens on the mini PC installed in the store; no video travels to the internet. The only thing that leaves for the application is the clock-in event: Maria clocked in at 19:32:12 on the 23rd. Nothing else, because nothing else is needed.
The full legal framing (Article 18 of the Portuguese Labour Code, Law 58/2019, DPIA) is in the article on what the law does and does not allow.
What this store changed in the product
- Remote deployment by design. Born from the camera episode: every installation is set up for remote diagnosis and correction from day one.
- The scheduling engine, per store and per shift. Born from the integration headache: it is what lets us validate exceptions with context instead of dumping alerts.
- Phased rollout as a rule. Running in parallel with the old system became standard practice, because it is what lets a customer adopt the system with minimum risk.
A demanding first customer early in a product’s life is not just revenue: it is the best quality department you can have, provided you are willing to listen and to write down in black and white what went wrong.
Want to compare these numbers with your own operation? The first meeting is 20 minutes and needs no more preparation than a recent month-end close on the table.
Guilherme Gameiro
Engineer and Co-Founder of Notchel.