Two weeks into HERE's private pilot, one of our merchants opened WhatsApp at 6pm and found this waiting for him:
Four separate messages. Four separate WhatsApp template costs. And on inspection, at least three of them were useless.
The battery car? An old order he'd already handled by phone. The 2 नग डिग्गी? A conversation from days prior he'd moved on from. The payment reminder didn't even name the customer — because there was no customer, just a stale record from an early test.
Only the first message — the daily summary — was actually earned.
What we thought we were building
The nightly reminder engine was written on a simple assumption: if there's an unconfirmed order in the ledger, remind the merchant. If a payment is overdue, remind the merchant. Every 24 hours, sweep the merchant's open items and nudge.
The idea was accountability. A shopkeeper's day is chaos. HERE was going to be the quiet backend memory that surfaces things you'd otherwise let slip.
It made sense on paper. It failed the moment it met a real merchant's inbox.
What actually happened
The reminders were technically correct — those items really were unconfirmed in the ledger. But "unconfirmed in the ledger" and "unresolved in the merchant's life" are two very different things.
Small business owners resolve things constantly, and rarely by tapping confirm buttons. A customer calls, the order gets sorted, life moves on. The ledger doesn't know that. So the ledger keeps nudging.
The result: merchants started training themselves to ignore evening messages from HERE. Templates began reading like spam. And every ignored template was a real cost — Meta charges per template, and merchant trust erodes faster than any dashboard can measure.
The observation that flipped it
The merchant, unprompted, sent us this the next morning:
These look aged or out of context. Maybe we should limit this to the last week. And in case there are pending items, we bring in history — that too limited look back.
He was right about the recency, but the bigger insight was buried in the framing. He wasn't asking us to send better proactive reminders. He was quietly telling us he didn't want them at all — he wanted to be able to ask when he needed to know.
That's the difference between push and pull. It changes everything about how a tool feels.
What we changed
We removed all proactive nudges except the daily summary. Overdue payments? Available on demand. Unconfirmed orders? Available on demand. Anything the merchant might want to check — HERE answers, but only when asked.
The merchant experience is now: one message from HERE at 6pm local time, summarizing the day. That's it. Everything else waits until the merchant types "what's pending" or "kya baaki hai."
We shipped the change the same weekend. The next evening, one message. No spam, no stale reminders. The merchant noticed, and told us so.
The broader principle
We think there's a category of founder-brain mistake we've been making without noticing: assuming that our software's memory is the same shape as the user's mental model.
It isn't. People forget things because they've already dealt with them. They forget follow-ups because those follow-ups happened over a phone call. They ignore reminders not because the reminders are wrong, but because the reminders are literal answers to questions they've already answered.
The correct response, most of the time, is to trust the user's attention as scarce and let them come to the memory when they need it — not the other way around.
Push notifications are a hammer that makes every feature look like a nail. Pull is quieter, less impressive, harder to demo. But it respects the person on the other end of the phone.
What this changes going forward
Every new HERE capability now has to answer one question before we ship it: does the merchant benefit if HERE surfaces this unasked, or only if the merchant asks? If the honest answer is the second one, that's what we build.