Notifications
Notifications are part of the order experience. A missing “order accepted” message creates a support ticket; a broken password reset locks a customer out.
Channels
| Channel | Use | Dependency |
|---|---|---|
| Receipts, password reset, vendor invites | SMTP or transactional provider | |
| SMS/OTP | Login, order updates in low-data markets | SMS gateway and sender ID |
| Push | Order status, reorder, promotions | Firebase project and app build |
| In-app | Order tracking and support | App/API connection |
Triggers to test
- Customer: OTP, order placed, payment success/failure, accepted, picked up, delivered, refund.
- Vendor: new order, cancellation, payout statement, menu approval.
- Rider: new assignment, pickup reminder, cash limit warning, shift summary.
- Admin: failed payment, refund request, vendor offline, delivery exception.
Disable marketing messages until transactional messages are reliable. A promotional push that arrives before the receipt erodes trust.
Email deliverability
- Send from your own domain, not a free mailbox.
- Configure SPF, DKIM and DMARC.
- Use a transactional provider for volume; keep the reply-to monitored.
- Warm up a new domain gradually.
- Test Gmail, Outlook and a local provider; check spam and rendering.
Push setup
Create a Firebase project, add the Android package and iOS bundle ID, download the configuration files and rebuild the apps. Test on a real device after a clean install. An emulator can pass while production tokens fail. If push stops after an app update, check the server key, the bundle ID and the device token.
Frequency and consent
Order updates are transactional and should always send. Marketing pushes and SMS need consent and an opt-out. Cap promotional messages per week and stop them after a complaint. In the EU/UK, consent rules are stricter; confirm with local counsel.