How do I get alerts from a web app when the browser isn't even open?

This page may contain affiliate links from which Blur Studio earns commissions.

This complaint shows up constantly with office and dispatch teams: a customer messages through a web chat tool, a booking system, or a shared inbox, and nobody sees it because the browser tab that tool lived in was closed at lunch, or the computer was restarted, or someone just never had it open that day. Phone notifications help, but they also mean someone has to be watching their phone, not the thing they're actually meant to be doing.

Why a closed browser can't notify you

A web page only exists while its tab is open and the browser process is running. Close the browser, and every tab inside it, including whatever tool was quietly waiting for a new customer message, stops existing entirely. There's no way for a plain browser tab to notify you about something that happened after you closed it, because nothing is running to notice it happened. This is the structural reason phone notifications become the fallback: a phone app can run in the background and alert you even when it's not open on screen, and a browser tab simply can't do the same thing.

Relying on phone notifications for this instead comes with its own real cost. It means whoever's meant to be watching for customer messages is now also pulled toward every other notification their phone produces throughout the day, which is a worse kind of distraction than the one you were trying to fix.

How turning it into a desktop app changes this

WebCatalog's desktop apps give a website its own window, its own icon in the dock or taskbar, and its own notifications and badge, independent of your browser. The underlying idea is the same one that lets a normal installed program (an email client, a chat app) notify you without a browser running at all: once the web app has its own dedicated window rather than living inside a shared browser, it can behave the same way. Its own process stays running (as long as the computer itself is on), so it can still show a badge or a notification for a new message even if your actual browser is closed. This also helps if you arelosing your CRM and inbox among browser tabs.

What this does not fix on its own is a computer that's fully shut down, or a staff member who's away from their desk entirely. If the job genuinely needs someone to be reachable anywhere, a phone-based alert is still the right tool for that specific gap, and the two aren't mutually exclusive: many teams use a desktop app for the "I'm at my desk" case and a phone alert as the backup for "I've stepped away."

How to set this up

1. Add the specific tool your customers actually message through as its own WebCatalog app: a shared inbox, a web-based chat widget, a booking system's own dashboard, whichever one is actually missing messages today. Chats from several services can also behandled in one place.
2. Leave it running and pinned to the dock or taskbar rather than opening and closing it like a normal browser tab. The whole benefit depends on it staying open as its own process, not on reopening it occasionally.
3. Test the actual alert behavior with a real message before trusting it, since notification reliability can vary by which specific site you've added. Send yourself a genuine test message and confirm you actually see a badge or notification before relying on this for live customer traffic.
4. Decide who's responsible for keeping the app open on a shared office computer. If three different staff members use the same desk across a day, agree on whether the app stays running for all of them or gets reopened per shift.
5. Pair it with a phone alert only for the specific moments staff genuinely leave their desk, rather than defaulting to phone notifications for everything, which brings back the original distraction problem. To keep alerts from following staff home, see how tostop work chat alerts after 6pm.

What I'd actually tell you

If missed messages are genuinely costing you leads, as they clearly are if this is the exact problem you searched for, this is one of the cheapest fixes available: the Basic plan is free for up to 2 apps, so you can set up exactly the one tool that's leaking messages and see whether the badge-and-notification behavior actually works for your specific setup before paying anything. I'd test it for real customer traffic for a week before deciding it's solved, since "notifications work" can mean different things depending on the operating system and the specific site.

Where this stops being enough: if the actual problem is that nobody has a clear rule for who checks which tool and when, no amount of better notifications fixes a responsibility gap. Fix the "who's watching this" question first, then let the desktop app make it easier for that person to actually notice.

A worked example: a dispatch desk missing booking alerts

Say a small field-service company runs its booking requests through a web-based scheduling tool that lives in a browser tab, and the front-desk computer gets restarted most mornings by whoever arrives first, with nobody consistently reopening that specific tab afterward. The result is a predictable pattern: new booking requests sit unseen for hours until someone happens to click back into that tab, and a same-day request that should have been caught at 9am gets noticed at 1pm instead, sometimes after the customer has already called a competitor. Turning the scheduling tool into its own WebCatalog app, pinned to the taskbar and left running independent of the browser, removes the specific failure point: it's no longer dependent on someone remembering to reopen a browser tab after every restart, because it's its own program showing its own badge the moment anything's waiting. Dispatch teams can alsolimit the tools on screen to what they need.

Common mistakes with this setup

• Assuming it works the same for every site without testing. Notification reliability genuinely varies by which specific web app you've added, so confirm with a real test message before trusting it for live customer traffic, rather than assuming it behaves identically to whatever tool you tested it with first.
• Letting the app close "by accident" and never noticing. The entire benefit depends on the app staying open as its own running process. A staff member who closes it out of habit, the same way they'd close a browser tab, quietly undoes the fix without anyone realizing until a message is missed again.
• Adding every tool at once instead of starting with the one that's actually leaking messages. With only 2 apps free, it's worth identifying the single highest-cost missed-message source first, confirming it actually works, and only then deciding whether paying for more apps is worth it.

When should you skip this?

If your team is already glued to their phones and checks messages there reliably, adding a desktop notification layer on top solves a problem you may not actually have. It's also worth being honest that per-site notification reliability isn't something WebCatalog documents in detail, so if a specific missed-message situation is genuinely high-stakes (a safety issue, a time-sensitive booking), don't rely on this alone without testing it directly first.

How I'd approach this

Most of the time this problem is solved exactly the way described above: give the one tool that's actually leaking messages its own dedicated window with WebCatalog's desktop apps, test it properly, and move on. Where I get called in is when a business has outgrown relying on any single tool's own notifications, five systems, five separate places a customer might message, and wants one combined alert feed that tells a dispatcher "something new happened" regardless of which tool it came through. That's a small custom build on top of each tool's own API, not a desktop-app trick, and it's worth having if missed messages are a recurring, expensive problem rather than an occasional one.