Every notification is a tiny tap on someone's shoulder. One at the right moment is helpful. Five in a row, about things they don't care about, and they do the only sensible thing: they turn notifications off.

And then they miss the one that mattered. The contract waiting for their signature. The water shutdown tomorrow morning. The rent reminder that arrived while the notifications were switched off.

That's the real cost of bad notifications, and it's why I treat them as a product feature in Kate PMS, not as a line of code at the end of a controller. Kate PMS has a web portal for staff, a staff app and a tenant app, and a lot of things happen across them: contracts and e-signing, rent and payments, maintenance requests. Almost every one of those is something somebody might want to hear about. The hard part is deciding who, how, and when.

Here are the questions I ask for every notification, in the order I ask them.

1. Does anyone actually need to know?

The easiest notification to get right is the one you don't send. When a maintenance request moves from "assigned" to "in progress" to "parts ordered" to "technician scheduled", the tenant probably cares about two of those steps, not all four. Internal status changes are often for staff, not for the tenant.

A good test: would this person do something differently because of this message? If the answer is no, it belongs in the app's activity history, where they can find it when they want it, not in their pocket.

2. How urgent is it? That decides the channel

Each channel has a personality, and using the wrong one is how notifications become noise.

Often the right answer is two channels with different jobs: a push to say "your payment receipt is ready" and an email that holds the receipt itself. The push is the tap on the shoulder; the email is the paperwork.

3. Can the person control it?

Preferences sound like a settings-screen chore. They're actually what makes people trust the notifications they keep. If the only choice is "everything or nothing", many people choose nothing.

The model I like is preferences per category, not per message: payments, maintenance updates, contract and documents, building announcements. A handful of switches people understand, rather than forty they never touch.

Some messages shouldn't be switchable at all. Legal and contractual messages, security alerts and payment confirmations are things the system must deliver. The honest way to handle that is to say so on the settings screen, not to hide it.

4. Will it arrive once, at a sensible time?

This is where the engineering lives. A few rules I don't bend:

• Always queued. Sending an email or a push inside a web request makes the request slow and makes it fail when the provider has a bad minute. A queue absorbs both.
• Only after the data is committed. If a notification is dispatched inside a database transaction that later rolls back, you've told someone about a contract that doesn't exist. Laravel's queued notifications can be told to wait until the transaction commits.
• Checked again at send time. A rent reminder queued for 9 a.m. should check that the rent is still unpaid at 9 a.m. Nothing destroys trust faster than "your rent is due" arriving right after the receipt.
• Safe to retry. Queues deliver at least once, so a crash at the wrong moment can mean a retry. Duplicate reminders are annoying; duplicate SMS cost money. Notifications need the same idempotency thinking as payments.
• Batched where it makes sense. Ten updates in five minutes should become one message, or a daily summary for staff who want one.

In Laravel, the "checked again" rule fits naturally into a notification's shouldSend method, which runs right before each channel sends (simplified):

class RentDueReminder extends Notification implements ShouldQueue
{
    use Queueable;

    public function __construct(public Invoice $invoice) {}

    public function via(object $notifiable): array
    {
        return $notifiable->channelsFor('payments'); // from the user's preferences
    }

    public function shouldSend(object $notifiable, string $channel): bool
    {
        return $this->invoice->fresh()->isUnpaid();
    }
}

Notice what via() does: the notification doesn't decide the channels, the user's preferences do. The notification describes the event; the person decides how they hear about it.

5. Does it read well on a lock screen?

A push notification has about one line to do its job. Templates help keep messages consistent, but the content still needs care:

• Lead with the action or the fact: "Contract ready to sign" beats "Update regarding your tenancy".
• Deep link to the exact screen. A push that opens the app's home screen and leaves the person to hunt for the contract is half a notification.
• Keep sensitive details off the lock screen. "A new payment receipt is available" is fine. Amounts and personal details belong inside the app, behind login.
• Write templates as copy, not code. Keep them in one place, reviewed like any other text users see, and in every language you support.

6. Can we prove it was sent?

In property management, "I never got that notice" is a real conversation. Keeping a record of what was sent, to whom, on which channel and when turns that from an argument into a lookup. It also helps support staff answer "did the tenant get the reminder?" without asking a developer to dig through logs.

The short version

• Send fewer notifications. Each one should lead to an action or answer a real question.
• Pick the channel by urgency: in-app for history, push for timely, email for records, SMS for rare and important.
• Give people category-level preferences, and be honest about what they can't switch off.
• Queue everything, send after commit, re-check at send time, and make retries safe.
• Write for the lock screen and deep link to the right place.
• Keep a record of what was sent.

Which app has the best notifications on your phone right now, and which one did you mute first?