--- title: "Notifications in a Business Application: Email, SMS and Push" description: "A notification nobody reads is worse than none — it teaches people to ignore the important ones too. How to design alerts that keep their credibility." canonical: "https://interfase.sk/en/news/notifications-in-a-business-application-email-sms-and-push" lang: "en" last_updated: "2026-10-19" --- # Notifications in a Business Application: Email, SMS and Push > A notification nobody reads is worse than none — it teaches people to ignore the important ones too. How to design alerts that keep their credibility. Published: 2026-10-19 - The first question is not which channel but whether the notification should exist at all — most needless alerts are information that could have waited in the app. - The channel follows urgency: push for now, email for today, SMS only for what must not be missed. - Send too often and people switch notifications off or stop reading them — including the ones that mattered. - Email deliverability is a technical discipline; without domain authentication records, messages land in spam with no warning. The application sends alerts for everything: a new order, a status change, a comment, a task assignment, an approaching deadline. Within a month half the team has turned them off and the other half has stopped opening them. What was lost is not only the flood — it is also the three notifications a month that genuinely mattered. ## First ask whether it should exist Before choosing a channel comes the question people skip: **does the user have to be told actively, or is it enough that they see it when they look?** Most alerts in business applications belong in the second category. An order status change is information, not an event. It belongs in a view inside the application, not on someone's phone. A good rule: a notification is warranted when it **requires something** of the user, or when not knowing would **cost them money or time**. Everything else is a polite interruption. ## Channel by urgency - **Push** — it needs dealing with now. An outage, a critical error, a task due today. - **Email** — it needs to be known today, but not this minute. Digests, approvals, documents. - **SMS** — only what must not be missed and is time-critical. It is the most intrusive and most expensive, so it suits one-time codes and genuinely serious events. - **In-app** — everything else. A common mistake is sending the same thing through every channel "just in case". The user gets it three times and learns that the application shouts. ## Digests instead of individual alerts If an event recurs often, it should not be sent every time. Instead of fifteen emails about new orders, one morning digest is better. What works is letting the user choose the frequency — immediately, daily, weekly — and defaulting to **daily**. Whoever needs immediacy will switch it; whoever does not never has to think about it. ## Settings have to be per type A single "send notifications" toggle is not enough. A user wants to hear about a task assigned to them and not about every comment. If the only thing they can turn off is everything, they will turn off everything. Breaking it down by event type and channel is more work at design time, but it is the difference between a feature people use and one they work around. ## Email deliverability is its own topic This surprises almost every project. The application sends the email, the log says "sent" — and the message is in spam. Without domain authentication records (SPF, DKIM, DMARC) email from a new application often does not arrive at all. Other things that help: sending from a domain also used for ordinary mail, having a working reply address, and **tracking bounces** rather than discarding them silently. For sign-in and security notifications there is the added point we make in the piece on [authentication and user management](/blog/prihlasovanie-a-sprava-pouzivatelov-sso-dvojfaktor-a-role) — these are messages that have to arrive. ## What to put in the notification Three things: **what happened**, **who it concerns** and **what to do about it**. A subject line reading "New order" says nothing; "Order 2841 needs approval by tomorrow" says everything needed before it is even opened. And the link should not lead to a home page but straight to the place. If the situation has changed meanwhile, the user should see that — not land on an empty screen. ## Mobile specifics Push notifications get lost when the app is offline or the device is in a power-saving mode. So an **in-app list** is always needed as the source of truth — push is a prompt, not delivery. This connects to what we describe about [offline mode in a mobile app](/blog/offline-rezim-v-mobilnej-aplikacii-synchronizacia-a-konflikty). ## What to measure - **Open rate by notification type** — a type below ten percent is a candidate for removal. - **The share of users who turned them off** — the strongest signal that there are too many. - **Email deliverability** — how many failed to arrive, and why. ## Where to start On an existing application it pays to take an inventory: list every notification the system sends and ask of each what it requires from the user. Move the ones with no answer into the app. Usually that is more than half. If you are building a new application and want this thought through from the start, [get in touch](/kontakt). We handle it as part of [custom development](/riesenia/vyvoj) — examples in our [case studies](/referencie). --- Web version: https://interfase.sk/en/news/notifications-in-a-business-application-email-sms-and-push llms.txt: https://interfase.sk/llms.txt