LiveKeeping had notifications. They had no system. I built the system.
Event Triggers Designed
Compliance, engagement, lifecycle
Daily Notification Cap
With P0 override logic
Geo-Segmented
Pan-India + 4 regional zones
Plan-Tier Logic
Different triggers per tier
LiveKeeping had push notifications. But there was no strategy — no documented trigger list, no priority rules, no daily cap, no regional logic. Compliance reminders, feature announcements, and festival greetings competed for the same time slots with no defined winner. A user filing their GSTR-1 on the 11th of the month could receive a Holi greeting at the same time as a compliance deadline reminder. No one had built the rules for what fires when, for whom, and in what order.
NO PRIORITY SYSTEM
A Diwali greeting and an GSTR-1 deadline reminder had equal weight. One is a compliance P0. One is a relationship touch. They're not the same.
NO CAP
Users could theoretically receive 5+ notifications on a single day during busy compliance periods. Every notification above 3 per day is a churn risk.
NO GEO-LOGIC
A Ganesh Chaturthi greeting going to a user in Chandigarh is meaningless noise. A Vishwakarma Puja greeting going only to East India users is the right call. This logic didn't exist.
I built this as a layered system — priority tiers, slot management, geo-segmentation, conflict resolution, and per-plan rules. Every notification type has a defined place in the hierarchy.
P0 → P3 Priority Hierarchy
P0 — OVERRIDE: GSTR-1 Last Day (11th of month). Takes slot 1. Always fires regardless of other slots. Cannot be bumped.
P1 — Workflow Compliance: E-Way Bill missing (dispatch event), IRN pending (invoice creation event). Takes slot 1 if no P0. Event-triggered.
P2 — Accounting: Month-close reminders (26th at 3 PM, last day at 5 PM). Daybook summary. Slot 2 or 3.
P3 — Engagement: Festival greetings, Send Greetings nudges, re-engagement (7-day inactivity). Last priority. Dropped if slots full.
3-slot daily cap with earned access
Users with 0-3 months tenure: 2-slot cap. Users with 3+ months: 3-slot cap. This prevents overwhelming new users who are still in the onboarding phase.
When P0 fires (GSTR-1 Last Day): slot 1 is consumed. Daybook and CN/DN are dropped from that day — compliance takes precedence. When E-Way and IRN fire same day: E-Way fires first (dispatch = later in workflow), IRN fires after (invoice creation = earlier). They are sequential workflow steps, not duplicates — both can fire.
The single IRN and bulk IRN alerts are mutually exclusive: single fires if <3 IRNs pending, bulk fires if ≥3. Not both.
5 geo-segments. Different festivals. Different timing.
Pan-India: National occasions — Eid, Independence Day, Diwali, Holi, Raksha Bandhan, Guru Purnima, Janmashtami
South India: Ugadi, Onam (Kerala), regional harvest festivals
Maharashtra / Goa: Gudi Padwa, Ganesh Chaturthi (10-day festival — highest engagement in MH)
East India (WB / Odisha / Assam): Ratha Yatra (Odisha primary), Vishwakarma Puja, Durga Puja
Gujarat / Rajasthan: Navroz, Cheti Chand, Mahavir Jayanti
Named exception handling
E-Way Bill + GSTR-1 Day: GSTR-1 takes slot 1. E-Way takes slot 2 (event-triggered). If 2-slot cap: E-Way drops on GST compliance days. Note in SOP.
E-Invoice + GSTR-1 Last Day (11th): GSTR-1 = slot 1 (9 AM). IRN = slot 2 (within 2 hrs of creation). Daybook and CN/DN dropped on 11th entirely.
June 21 — Yoga Day + Father's Day: Two occasions, same date. Send one only, or route one to June 20. Named in conflict doc as 'June 21 exception.'
Every notification was written with a specific trigger, audience, and action in mind. I wrote all copy. Two examples that show the principle:
E-Way Bill missing — trigger-based, PRO+
Title: E-Way bill for [Customer] is incomplete
Body: Vehicle or transporter details missing. Add now to generate and avoid delays.
Why this works: Names the specific document, names the specific gap, gives a reason (avoid delays), one CTA.
Month-close reminder — 26th of month, PRO/PRO+
Title: Month closes in 5 days
Body: Reconcile your sales entries and GST data now — catch errors before they hit your GSTR-1.
Why this works: Urgency without panic. Concrete action (reconcile). Stakes clearly stated (GSTR-1 impact).
Multi-batch voucher feature release copy
Shipped notification copy for the multi-batch + godown selection feature on Create Voucher. The winning notification:
Title: 'Stop creating vouchers one batch at a time'
Body: 'Multi-batch & godown selection is now live. Fewer entries, cleaner records, faster period closing.'
Sent Day 3-5 to non-openers only — avoided fatiguing users who had already opened and explored the feature.
This was a systems design project, not an A/B test. The output was the architecture itself — a documented, reproducible, tier-aware notification system that the team could maintain and extend. Before this, every new notification was ad-hoc. After this, every new trigger has a defined slot, a defined audience, a defined priority, and a conflict resolution rule.
27+ trigger events documented with timing, segment, priority tier, conflict rules, and suppression conditions
Festival calendar: 27 occasions across 7 months, geo-segmented across 5 zones, with multi-occasion date handling
Evergreen greeting library: 13 types, copy written, template IDs assigned
Multi-batch voucher feature release notification: 5 variants written and A/B-tested
Conflict resolution SOP for all identified edge cases — used by the team for all future notification planning
Notification strategy is product strategy. Every send decision encodes a priority — what the product thinks matters most right now. Getting the P0/P1/P2/P3 hierarchy right is equivalent to getting the product's value proposition right for that user at that moment.
I'd have added open rate and action rate tracking per trigger from day one. We had segment data but not per-notification-type engagement data. Without that, you can't iterate on what's working.
The 3-slot cap was set conservatively. With proper measurement in place for 60 days, I'd have tested a 4-slot cap for PRO+ users on GSTR-1 filing weeks — where compliance urgency is high and users are already in 'active business management mode.'