In most SMEs the first signal that something has gone wrong comes from the customer. They call because the order never shipped. They email because they're still waiting for a quote three weeks later. They escalate because an invoice is overdue even though they paid two weeks ago. The ERP had all of it visible — nobody was looking, because nobody had a reason to look at that particular report on that particular day.
A business alert flips the situation around. The system itself says: "procurement — this SKU has been sitting for 90 days and you have a supplier meeting tomorrow". "Owner — margin on customer X dropped 15% this month". "Sales rep — customer Y has been waiting for your quote for five working days". No one has to log into the ERP, no one has to open a report. The problem reaches a person before the customer gets a chance to be annoyed.
The problem is that the first instinct is "fine, let's set up alerts on everything". Two weeks later the whole team mutes notifications, because Teams buzzes every five minutes and nobody can tell which alert actually means something.
What a business alert is — and what it isn't
It isn't IT monitoring. IT monitoring watches whether the server is alive, whether the uplink is up, whether the backup ran — we wrote about that separately (see IT monitoring for SMEs). A business alert watches something different: events in business processes that require a human to act.
The difference is practical. IT monitoring calls an admin at 3 AM because a server died. A business alert pings a sales rep at 9:15 on Tuesday because a customer has been waiting on a quote for five days. The first is binary (up/down). The second is threshold-based (something is happening too slowly, too rarely, below normal).
A business alert has three properties that an ordinary report doesn't:
- It reaches a specific person, not a generic company inbox. "Alert to the sales rep who owns this quote" — not "alert to the sales team".
- It's addressed to an action, not to reading. "Quote OF/2026/0421 has been waiting 5 days — call the customer" makes sense; "attached is the list of open quotes" doesn't.
- It has a firing threshold. It doesn't go off every time something happens.
If it doesn't meet those three conditions, it's not an alert — it's spam.
What's actually worth watching in a typical SME
The list of alerts that pay off in 10–50-person companies isn't long. What's interesting is that these aren't sophisticated things. They're basic signals every owner would want to know anyway — they just used to find out about them two days too late.
- Quote with no response. Quote issued more than X days ago, no status "won" or "lost". Goes to the sales rep who owns it and to their manager. Threshold: usually 5–7 working days.
- Order stuck in a stage. Customer order has been in a status other than "completed" or "cancelled" for more than X days. Goes to the customer service lead. Threshold: 3 days if the normal cycle is one.
- Overdue invoice above a value threshold. Not every missed payment — only those above an amount that genuinely hurts (say PLN 10k) and more than 7 days past due. Goes to accounting and the sales rep.
- Stock below minimum on A/B category items. Not everything — only those SKUs that are part of your core offer, where a stock-out is immediately visible to the customer. ABC/XYZ analysis is a separate topic.
- Contract/customer margin below threshold. Line in an order with a margin below X% — alert to the sales manager, not a system block.
- Complaint ticket unassigned for 24h. If no one has picked up a complaint within one working day — alert to the service/support lead.
One classic overload: an alert for every admin login, for every new employee, for every price change. Those are technical events. They belong in the log, not in the owner's inbox.
Alert fatigue — the biggest trap
If a human gets more than 5–7 alerts a day, they start ignoring them. Not because they're lazy. Because the human brain filters noise. And noise is everything that isn't an action I can take right now.
Signs that alerts in your company have broken down:
- "Oh, that fires every day, I don't look anymore." An alert nobody reacts to should be switched off — or the threshold needs changing.
- Alerts go to a shared inbox ("office@", "orders@") where someone glances at them "when they have time". That's not alerts, that's an email queue.
- Alerts say what happened, but not what to do about it. "Quote is 10 days old" is a report. "Quote is 10 days old — call customer Y or mark as lost" is an alert.
- The same notification lands on five channels at once (email + Teams + SMS + ERP toast + a phone call). One channel per alert.
A good rule: in the first month, 60–70% of the alerts you set up will stick. The rest need to be either switched off or tightened — otherwise they'll drag the rest down with them.
Tools: from an ERP filter to Power Automate
You don't need a separate alerting system. In most SMEs, three kinds of tools you already own are enough.
Option 1 — native ERP mechanisms. Comarch Optima, enova365, Subiekt, Microsoft Dynamics AX — each has some flavour of filters, saved queries, reminders. They aren't full alerting engines, but for a few key events (overdue invoices, minimum stock) they'll do. Upside: no integration needed. Downside: the alert usually lives inside the ERP and won't jump to Teams/SMS without external help.
Option 2 — Power Automate / Zapier / Make. If the ERP has an API or at least an SQL/CSV export, Power Automate (part of Microsoft 365, which you already have) can run alerts on a schedule: every morning at 7:30 it queries the database, sends an email or a message to a Teams channel. This is the realistic tool for 90% of SMEs — low barrier to entry, everything inside one Microsoft tenant, logs available, works from day one.
Option 3 — SQL queries + a small script. If you have an in-house IT person or an external ERP developer, the cheapest path is an SQL query against the ERP database run on a cron, which sends an email or a message. Stable, one-off cost of a few hours, but it needs a hand that knows the database schema — and whoever succeeds that person has to know where the scripts live (see bus factor in SME IT).
If the ERP has its own workflow module (Comarch DMS, enova365 Workflow), look at it before bolting on a third tool — but in a 10-person company it often turns out that the built-in workflow is overkill.
One concrete example
At one of our clients — a 24-person electrical materials wholesaler selling mostly to electricians and small installation companies — we started with 23 proposed alerts. "Let the system tell us everything." After three weeks the owner wrote: "people are muting Teams, they can't work."
Six survived:
- Quote with no response, >6 working days — to the sales rep owning it and copy to the sales manager. Before alerts, the average "time to close a quote" was 18 working days; after three months it dropped to 11.
- Customer order stuck >48 hours in status "to pick" — to the warehouse lead. Previously, roughly once a week an order would sit for 4–5 days because "we're missing one item, we'll order it soon". After the rollout — statistically zero such cases per quarter.
- Invoice above PLN 8k, >7 days past due — to the accountant and the sales rep. Collections (see SME collections automation) stopped looking like a month-end rescue mission.
- Stock below minimum on the top 50 SKUs — once a day at 7:00 to the procurement lead. The remaining 2,000 SKUs are handled by a different mechanism (reorder point in the ERP), because they don't need human intervention.
- Complaint unassigned >24h — to the service lead. Previously there were complaints sitting for a week because "they landed in the shared inbox".
- Order line margin <12% — to the sales manager, not a blocking system. Below-threshold items are usually conscious trade decisions, but someone in management should see them.
Tooling: the first three alerts in Power Automate, which queries Optima's SQL at 7:30 and posts a message to a specific Teams channel. The fourth and fifth natively in the ERP plus email. The sixth — an SQL query firing on the database side. One-off implementation cost: about 20 hours of integrator time spread over three weeks. Ongoing: 1–2 hours a month fine-tuning the thresholds.
The time saved was hard to measure exactly, but at the end of the quarter the owner summarised it differently: "for the first time in a long while, I didn't learn about a problem from a customer."
How to start in two weeks
You don't need a revolution. The sequence that works at clients:
- Week 1 — talk to the team. Not to the integrator, not to the board. To the people sitting in the ERP every day. "What would you like to know earlier than you find out today?" You'll collect a list of a dozen or so suggestions — that's where real alerts come from, not from the slides.
- Week 1 — pin the 5–7 most important ones. No more than that. The rest wait for a second round. For each one: who gets it, through which channel, what they should do after receiving it, when the alert clears.
- Week 2 — implement. Preferably in tools you already own (ERP + Power Automate). You buy new tooling only when something genuinely won't work.
- After a month — review. Which alerts worked? Which are ignored? Which should have a higher threshold? One Tuesday afternoon is enough.
If you don't know which alerts to start with — half an hour with someone who has arranged a dozen similar lists before saves two weeks of guessing.
A good alert doesn't say "something happened". A good alert says "do this now, or in three days it'll be too late".
Let's talk about business alerts for your company →