> For the complete documentation index, see [llms.txt](https://docs.physiqo.in/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.physiqo.in/04-product/prd-5.md).

# Notification

## Notification Module

***

## 1. Purpose

The Notification Module manages all transactional communications between PhysiQo and its users.

The module ensures that patients, physiotherapists and administrators receive timely, accurate and relevant updates throughout the booking lifecycle.

***

## 2. Business Objectives

The Notification Module shall:

* Keep users informed.
* Reduce booking uncertainty.
* Improve appointment attendance.
* Improve customer trust.
* Reduce manual communication.
* Support automated workflows.

***

## 3. Notification Channels

Current

* WhatsApp

Future

* Email
* Push Notifications
* SMS

System notifications shall use the most appropriate channel based on availability and user preferences.

***

## 4. Notification Events

The platform shall generate notifications for the following events.

### Authentication

* OTP Generated
* Login Successful

***

### Booking

* Booking Created
* Booking Confirmed
* Booking Cancelled
* Booking Rescheduled

***

### Payment

* Payment Successful
* Payment Failed
* Refund Initiated
* Refund Completed

***

### Assignment

* Physiotherapist Assigned
* Physiotherapist Reassigned

***

### Treatment

* Appointment Reminder
* Treatment Started
* Treatment Completed

***

### Reviews

* Review Request

***

### Account

* KYC Approved
* KYC Rejected
* Account Suspended

```mermaid
flowchart TD

A[Business Event]

A --> B[Notification Service]

B --> C{Channel}

C --> D[WhatsApp]

C --> E[Email]

C --> F[Push]

D --> G[Delivered]

E --> G

F --> G
```

***

## 5. Notification Priority

| Priority | Examples                                   |
| -------- | ------------------------------------------ |
| Critical | OTP, Payment Success, Booking Confirmation |
| High     | Assignment, Cancellation                   |
| Medium   | Reminder                                   |
| Low      | Review Request, Promotions                 |

***

## 6. Delivery Rules

Every notification shall contain:

* Recipient
* Notification Type
* Event Reference
* Timestamp
* Delivery Status

The platform shall maintain delivery history for troubleshooting and auditing.

***

## 7. Retry Policy

If notification delivery fails:

* Retry according to configured retry policy.
* Record every retry attempt.
* Mark final delivery status.

Repeated failures shall generate an operational alert.

***

## 8. Notification Templates

Templates shall be maintained separately for:

Patient

* OTP
* Booking Confirmation
* Reminder
* Cancellation
* Review Request

Physiotherapist

* Assignment
* Reassignment
* Settlement

Administrator

* Payment Failure
* Assignment Failure
* Critical Alerts

***

## 9. Backend Mapping

Controllers

* NotificationController

Services

* NotificationService
* WhatsAppService

Repositories

* NotificationRepository

Entities

* Notification

***

## 10. Future Enhancements

* User Notification Preferences
* Quiet Hours
* Scheduled Notifications
* Multi-language Notifications
* AI-based Smart Reminders

***

## Related Documents

* Booking PRD
* Payment PRD
* WhatsApp PRD
* User Journey
* Business Rules

***

Status

Draft


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.physiqo.in/04-product/prd-5.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.