Appearance
Notifications and Communication
Communication is the nervous system of a marketplace — notifications keep transactions moving, messaging builds trust between strangers, and getting the balance right means the difference between engagement and annoyance.
Why This Matters
- 🏢 Owner: Communication drives transaction completion rates. Missed notifications mean missed bookings, unanswered inquiries, and lost revenue. But over-notification drives users to mute you entirely.
- 💻 Dev: You'll build the messaging infrastructure, notification delivery pipeline, real-time alert systems, and anti-disintermediation safeguards. This spans email, push, SMS, and in-app channels.
- 📋 PM: Notification strategy is a product lever — every message is an opportunity to move a transaction forward or re-engage a dormant user. You'll define what gets sent, when, and through which channel.
- 🎨 Designer: Notification design, inbox UX, message thread layouts, and communication templates shape how users experience your marketplace between visits. This is where relationships form.
The Concept (Simple)
Think of marketplace communication like a wedding planner coordinating between the couple, vendors, and venue.
Without the planner, the florist doesn't know when to deliver, the caterer doesn't know the headcount, and the DJ doesn't know the schedule. Chaos. The planner sends the right message to the right person at the right time — confirmations, reminders, updates, and alerts — so everyone stays coordinated without being overwhelmed.
A marketplace notification system does the same thing. It coordinates buyers and sellers through a transaction lifecycle — from initial inquiry to booking confirmation to fulfillment to review request — sending the right information at the right time through the right channel.
How It Works (Detailed)
Communication Architecture
┌─────────────────────────────────────────────────────────────────┐
│ NOTIFICATION SYSTEM ARCHITECTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ EVENT SOURCE │
│ (Transaction service, User service, etc.) │
│ │ │
│ │ publishes event: "booking.confirmed" │
│ ▼ │
│ ┌──────────────────────────────────────────────┐ │
│ │ NOTIFICATION ENGINE │ │
│ │ │ │
│ │ 1. Route: Which users need to know? │ │
│ │ 2. Template: What message for each role? │ │
│ │ 3. Channel: Email, push, SMS, or in-app? │ │
│ │ 4. Timing: Immediately, batched, or delayed?│ │
│ │ 5. Preferences: Has user opted out? │ │
│ └──────┬───────┬───────┬───────┬───────────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ ┌────────┐ ┌──────┐ ┌─────┐ ┌────────┐ │
│ │ EMAIL │ │ PUSH │ │ SMS │ │ IN-APP │ │
│ │ │ │ │ │ │ │ INBOX │ │
│ │ SendGrid│ │ APNS │ │Twilio│ │WebSocket│ │
│ │ SES │ │ FCM │ │ │ │ │ │
│ └────────┘ └──────┘ └─────┘ └────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘The Three Communication Types
┌─────────────────────────────────────────────────────────┐
│ THREE TYPES OF MARKETPLACE COMMUNICATION │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. TRANSACTIONAL NOTIFICATIONS │
│ ┌─────────────────────────────────────────────┐ │
│ │ System-generated, triggered by events │ │
│ │ • Booking confirmed / order placed │ │
│ │ • Payment received / payout sent │ │
│ │ • Shipping update / delivery confirmation │ │
│ │ • Review request after completion │ │
│ │ Channel: Email + push (critical path) │ │
│ └─────────────────────────────────────────────┘ │
│ │
│ 2. PEER-TO-PEER MESSAGING │
│ ┌─────────────────────────────────────────────┐ │
│ │ Buyer-seller conversation │ │
│ │ • Pre-transaction questions │ │
│ │ • Coordination during fulfillment │ │
│ │ • Post-transaction follow-up │ │
│ │ Channel: In-app inbox + email notification │ │
│ └─────────────────────────────────────────────┘ │
│ │
│ 3. MARKETING / RE-ENGAGEMENT │
│ ┌─────────────────────────────────────────────┐ │
│ │ Platform-initiated, growth-driven │ │
│ │ • "New listings matching your search" │ │
│ │ • "Price drop on your wishlist" │ │
│ │ • "You have unused credits" │ │
│ │ • Seasonal promotions │ │
│ │ Channel: Email + push (respect frequency) │ │
│ └─────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘Transactional Notification Map
Every marketplace transaction triggers a sequence of notifications to both sides:
| Event | Buyer Notification | Seller Notification | Channel |
|---|---|---|---|
| Inquiry sent | "Your message was sent" | "New inquiry from [Buyer]" | Push + in-app |
| Booking requested | "Request sent, awaiting confirmation" | "New booking request — respond in 24h" | Push + email |
| Booking confirmed | "Your booking is confirmed!" | "You confirmed [Buyer]'s booking" | Email + push |
| Payment captured | "Payment of $X processed" | "Payment of $X received" | |
| Reminder | "Your booking is tomorrow" | "Upcoming booking with [Buyer] tomorrow" | Push + email |
| In progress | "Your order is being prepared" | "Time to start [Buyer]'s order" | Push |
| Completed | "How was your experience? Leave a review" | "Transaction complete. Payout in 2 days" | Email + push |
| Review received | — | "[Buyer] left you a 5-star review!" | Push + email |
| Payout sent | — | "$X has been sent to your bank" | |
| Dispute opened | "We received your dispute" | "A dispute has been filed on order #X" |
Channel Selection Strategy
Choose the right channel for the right message:
┌─────────────────────────────────────────────────────────┐
│ CHANNEL SELECTION MATRIX │
├─────────────────────────────────────────────────────────┤
│ │
│ URGENCY │
│ Low High │
│ ┌────────────┬────────────┐ │
│ Low │ │ │ │
│ IMPORT │ EMAIL │ PUSH │ │
│ ANCE │ Weekly │ Real-time │ │
│ │ digest │ alert │ │
│ ├────────────┼────────────┤ │
│ High │ │ │ │
│ │ EMAIL │ SMS + PUSH │ │
│ │ (rich │ (must not │ │
│ │ detail) │ miss) │ │
│ └────────────┴────────────┘ │
│ │
│ Examples: │
│ • New listing match → Email (low urgency, low import) │
│ • Booking request → Push (high urgency, high import) │
│ • Payout summary → Email (low urgency, high import) │
│ • Order arriving → SMS + Push (high urgency, critical)│
│ │
└─────────────────────────────────────────────────────────┘In-App Messaging System
The buyer-seller messaging system is critical for building trust before a transaction:
┌─────────────────────────────────────────────────────────┐
│ IN-APP MESSAGING ARCHITECTURE │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────┐ │
│ │ MESSAGE THREAD │ │
│ │ │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ Buyer: "Is parking available?" │ │ │
│ │ │ 2:30 PM │ │ │
│ │ └──────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ Seller: "Yes, free street parking│ │ │
│ │ │ and a private driveway." │ │ │
│ │ │ 2:45 PM │ │ │
│ │ └──────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ Buyer: "Great! Booking now." │ │ │
│ │ │ 2:47 PM │ │ │
│ │ └──────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ SYSTEM: Booking confirmed ✓ │ │ │
│ │ │ 2:48 PM │ │ │
│ │ └──────────────────────────────────┘ │ │
│ │ │ │
│ │ [Type a message... ] [Send] │ │
│ └─────────────────────────────────────────────┘ │
│ │
│ Features: │
│ • Threaded per transaction/listing │
│ • System messages injected (confirmations, updates) │
│ • Quick reply templates for sellers │
│ • Photo/file attachment support │
│ • Read receipts and typing indicators │
│ • Auto-translate for international marketplaces │
│ │
└─────────────────────────────────────────────────────────┘Preventing Disintermediation
Disintermediation is when buyers and sellers exchange contact info to transact off-platform, avoiding your fees:
| Risk Signal | Detection Method | Prevention |
|---|---|---|
| Phone numbers in messages | Regex pattern matching | Block or flag messages with phone patterns |
| Email addresses shared | Pattern detection + ML | Mask or warn, allow after booking confirmed |
| External links | URL detection | Block non-whitelisted URLs pre-transaction |
| "Pay me directly" | NLP keyword detection | Flag for review, educate on platform benefits |
| Repeated off-platform terms | Keyword + context analysis | Gentle reminder of platform protections |
Important balance: Too aggressive blocking feels hostile and drives users away. Too lenient means revenue leakage. Best practice:
- Pre-transaction: Moderate messaging — prevent contact info sharing
- Post-transaction: Relax controls — they've already transacted on-platform
- Always: Emphasize why transacting on-platform is better (protection, escrow, reviews, support)
Notification Preferences and Fatigue
┌─────────────────────────────────────────────────────────┐
│ NOTIFICATION PREFERENCE SYSTEM │
├─────────────────────────────────────────────────────────┤
│ │
│ Category Email Push SMS │
│ ───────────────── ───── ──── ─── │
│ Booking updates ✓ ON ✓ ON ✓ ON (locked) │
│ Payment & payouts ✓ ON ✓ ON ○ OFF │
│ Messages ✓ ON ✓ ON ○ OFF │
│ Review reminders ✓ ON ○ OFF ○ OFF │
│ Promotions ○ OFF ○ OFF ○ OFF │
│ New listing alerts ✓ ON ○ OFF ○ OFF │
│ Tips & education ○ OFF ○ OFF ○ OFF │
│ │
│ Rules: │
│ • Transaction-critical notifications can't be muted │
│ • Default to fewer notifications, let users opt in │
│ • Batch non-urgent notifications into digests │
│ • Honor quiet hours (no push between 10pm - 8am) │
│ • Track unsubscribe rate per notification type │
│ │
└─────────────────────────────────────────────────────────┘Real-Time Notifications for On-Demand Marketplaces
On-demand platforms need sub-second notification delivery:
| Event | Latency Target | Channel | Tech |
|---|---|---|---|
| New order | < 2 seconds | Push + sound + vibration | WebSocket + FCM/APNS |
| Driver assigned | < 3 seconds | Push + in-app update | WebSocket |
| Location updates | Every 5 seconds | In-app map | WebSocket |
| Order status change | < 2 seconds | Push + in-app | WebSocket + push fallback |
| Chat message | < 1 second | In-app + push if backgrounded | WebSocket + push fallback |
In Practice
What Good Looks Like: Airbnb's Communication System
- Smart messaging — messages are threaded per listing/trip, with system messages (booking status, payment confirmations) injected inline
- Quick replies — hosts get suggested response templates for common questions
- Translation — automatic message translation for cross-language communication
- Response rate tracking — host response rate and time are visible to guests and factor into search ranking
- Scheduled messages — hosts can set up automatic check-in instructions sent the day before arrival
What Good Looks Like: Uber's Real-Time Notifications
- Sub-second matching — rider gets push notification within 2 seconds of driver assignment
- Live map — real-time driver location via WebSocket, no polling
- ETA updates — dynamic, adjusting based on traffic every 15 seconds
- Trip receipt — email with full trip details, route map, and fare breakdown sent within 60 seconds of trip end
- Rating prompt — in-app prompt immediately after trip, before the next action
Common Anti-Patterns
- Notification spam — sending every possible update via every channel. Users disable notifications and disengage entirely.
- Generic templates — "You have a new notification" instead of "Sarah confirmed your booking for July 12-15."
- No quiet hours — sending push notifications at 3 AM. Implement time-zone-aware delivery windows.
- Email-only critical alerts — relying on email for time-sensitive notifications (new orders, booking requests). Email has low open rates and high latency.
- Blocking all contact sharing — aggressively preventing any off-platform communication, which feels controlling. Focus on pre-transaction, allow post-transaction.
- No escalation ladder — sending the same notification repeatedly instead of escalating channel (in-app → push → SMS → phone call for critical events).
- Missing system messages — not injecting transaction updates into the messaging thread, forcing users to check separate notification screens.
Notification Metrics
| Metric | Target | Why It Matters |
|---|---|---|
| Delivery rate | >99% (email), >95% (push) | Undelivered notifications = missed transactions |
| Open rate | >40% (push), >25% (email) | Low open rate means wrong channel or content |
| Click-through rate | >10% (push), >5% (email) | Users should act on notifications |
| Unsubscribe rate | <0.5% per email send | High unsubscribe = notification fatigue |
| Response time | <1 hour (messages), <24h (booking requests) | Faster response = higher conversion |
| Notification-to-action rate | >20% for transactional | Notifications should drive behavior |
Key Takeaways
- Marketplace communication serves three purposes: transactional (move transactions forward), peer-to-peer (build buyer-seller trust), and marketing (re-engage users)
- Choose notification channel based on urgency and importance: SMS for critical, push for urgent, email for detailed, in-app for everything
- In-app messaging between buyers and sellers is essential for high-consideration transactions — it builds the trust needed to transact with strangers
- Prevent disintermediation by moderating pre-transaction communication while relaxing controls post-transaction — and always emphasize platform benefits over restrictions
- Default to fewer notifications and let users opt in — notification fatigue is a leading cause of app uninstalls and email unsubscribes
- On-demand marketplaces need sub-second notification delivery via WebSocket with push notification fallback
- Inject system messages (booking confirmations, payment updates, status changes) into conversation threads so users have one place to track everything
- Track notification metrics by type and channel — delivery rate, open rate, and notification-to-action rate tell you if your communication system is working
Action Items
- ☐ 🏢 Owner: Define your notification philosophy: which messages are mandatory (can't mute) vs optional (user controls)
- ☐ 🏢 Owner: Set a response time SLA for sellers (e.g., respond to inquiries within 24 hours) and communicate consequences
- ☐ 💻 Dev: Build an event-driven notification engine that routes events to the right users, templates, channels, and timing
- ☐ 💻 Dev: Implement WebSocket-based real-time messaging with push notification fallback for offline users
- ☐ 📋 PM: Map every transaction event to its notification — who gets notified, what channel, what content, what timing
- ☐ 📋 PM: Design a disintermediation strategy that balances revenue protection with user trust — don't be heavy-handed
- ☐ 🎨 Designer: Design a unified inbox that combines peer messages and system notifications in chronological threads per transaction
- ☐ 🎨 Designer: Create notification preference controls that are easy to find and understand, with sensible defaults that don't overwhelm