12. Messaging & On-Site Emergencies

← Business Requirements

(a) Business requirements

  • There is no live chat and no direct nurse↔customer messaging. All post-booking communication runs through a structured ticket system that admin can read in full. This is a deliberate anti-disintermediation and patient-safety design: it protects vulnerable patients, creates a dispute paper trail, and prevents families and nurses pairing off-platform.
  • A booking-scoped coordination ticket is auto-created so the nurse and customer can coordinate logistics (arrival time, room location) under admin visibility. Internal admin-only notes are supported and never shown to users.
  • Tickets also carry refund conversations and any support request, and are the mandatory anchor for admin refunds (Section 7).
  • On-site emergency playbook. The ticket system is async and has no real-time channel, so the operational playbook is explicit: in an emergency (no answer at the door, a medical emergency), the nurse calls the emergency-contact number surfaced in the app, then opens a ticket. The emergency contact number is surfaced prominently in the booking UI (drawn from encrypted care instructions), so a nurse never needs to find the family's number by other means (which would break the platform's communication control).

(b) Iran-specific considerations

  • Disintermediation is the predictable failure mode of recurring, relationship-based care; the ticket-only model retains value (escrow, dispute protection, backup coverage, insurance that only applies on-platform) instead of relying on punitive lock-in.
  • For unobserved in-home care of patients who cannot self-report, the controlled-but-auditable communication channel plus a clear emergency escalation path is a safety requirement.

(c) MVP vs DEFERRED

  • MVP: ticket-only messaging (admin-readable); auto-created booking-coordination ticket; internal notes; prominent in-app emergency contact + documented playbook.
  • DEFERRED: real-time chat; a first-class incidents/emergency-event entity with SLA; push/real-time alerting.

(d) Supporting database entities

tickets, ticket_participants, ticket_messages, booking_care_instructions (encrypted emergency contact), support_alerts.

Related: Data model — Messaging.

↑ Back to top