Communicate appointment changes reliably in an app
A trial plan for notification permissions, sending status and the route back to the current service appointment.
The change belongs in the appointment system
A push notification informs customers of a changed appointment. The authoritative change must first be saved in the responsible system. Start by planning where customers find the current state and who follows up an important change if the message does not reach them.
Apple and Android describe platform-specific notification permissions. Explain the benefit at a suitable moment, such as when customers want appointment alerts. A denied permission must not be treated as consent. Check behaviour on the intended devices and operating system versions.
Example and completed trial plan
In the fictional example, dispatch moves service appointment AP-17 from 14:00 to 15:00. A restrained message reads: “A service appointment has changed. Open the app for the current details.” Personal job details need not appear on the lock screen for this.
Situation | Planned behaviour | Expected evidence |
|---|---|---|
Notification permission is absent | Current appointments remain findable in the app; use the agreed contact route for important changes. | The team assumes no successful push contact and knows the responsible role. |
Appointment changes | Save the change and link the notification clearly to that appointment. | The new state is saved; a sending attempt does not replace saving. |
Provider accepts the message | Record the sending status actually known. | Provider acceptance is not labelled device receipt or customer reading. |
Device is offline or the message is late | Load the current appointment state on opening. | An old message does not restore an old state; failure to update is clearly shown. |
Customer taps the message | Open the related appointment after any required sign-in and current permission check. | The correct appointment appears. If access is denied or data cannot load, the customer gets appropriate feedback. |
Check sending and customer action separately
FCM documents server acceptance and delivery to the device SDK as separate events. Device receipt also does not prove the customer read or accepted the change. In this example, tapping must neither create another appointment nor automatically give any approval the business process requires.
Set a suitable validity period for the message. Messages can arrive late, so an old notification must not be the sole source of appointment state. Agree when the responsible person follows up important changes through the designated contact route.
Try allowed and denied notifications, delayed receipt, missing sign-in and appointment data that cannot load. The table describes expected results of this trial. Assess whether customers find the current appointment and understand the necessary next action.
Sources
Read more
All articles
Software Development with ASES
Custom software, web and mobile apps