Part 2 — Set Up Your Company · Chapter 13

Alerts & Notifications

Alerts are how BigWave taps people on the shoulder. Configured per project under Project Setup/Alerts, each alert pairs a trigger with recipients and an email, optionally dressed in an HTML template from chapter 12. Done well, alerts replace the daily “any update?” calls in both directions. Done badly, they train everyone to delete BigWave email unread, so this chapter is as much about restraint as configuration.

The triggers

An alert can fire when, on a work order in this project:

one is created
a comment is added
the status changes, on any change or on reaching one specific status
a document is added
a custom field value changes
a technician is assigned, or an assignment is completed
an issue is logged, any or one specific issue type, chapter 22
a deliverable is completed
a schedule date changes, or a scheduled date is missed
a scheduled event reminder comes due, meaning advance reminders before a visit. Enabling this also unlocks the project’s Scheduled Reminder report.

Then there are the timers, which fire on a duration rather than an event: a schedule item overdue, a status held too long, or a timecard overdue. Timers are the enforcement arm of chapter 7’s one-status-one-owner rule. A work order stuck in Awaiting Parts for ten days emails somebody instead of aging quietly.

An email document alert type also exists, for sending generated documents automatically.

Recipients

Each alert chooses its audience: internal people, meaning a named user or the project team or the project manager, the assigned technician, or customer contacts. The same trigger can exist twice with different audiences and different wording. The status change that tells Priya “job done, invoice it” and the one that tells Harbor Grill “your site is complete” are separate alerts saying separate things.

Designing an alert set people keep reading

Start from the moments your team currently chases by phone or by re-checking screens.

Commercial (Harbor Grill): four alerts. Specific status Report Submitted notifies Marcus. A stale-status timer on PO Received notifies Priya. Completion of the signed-report deliverable notifies the Harbor Grill facilities manager with a branded template. A missed schedule date notifies Priya, because a missed inspection window is a contract problem the same day, not at month end.

Residential (the Okafors): two. Work order created, from the portal or from intake, notifies Priya. Specific status Complete emails the customer their summary and invoice.

The restraint rules. Never alert the whole team when one owner will do. Prefer a specific status over any-status-change, since any-change alerts are the fastest route to a deletion reflex. Use a timer instead of a person checking a screen wherever the real requirement is “nothing should sit here long”.

Status action buttons: alerts that accept replies

The emails BigWave sends can do more than inform. A template can embed a status action button. The recipient clicks it, lands on a lightweight confirmation page, confirms, and the work order moves to the status the button names. No login, no reply email, no phone tag.

The canonical use is quote approval. The quote email to the Okafors carries an Approve button targeting the Approved status, and the click moves the work order, which can trigger the next alert, “quote approved, schedule it”, to Priya. Chapter 18 assembles the whole loop. The mechanism is status-agnostic, though: a Confirm appointment button, a Reject button targeting a rejected status, whatever your flow needs. The two-step click-then-confirm design exists so email security scanners that pre-open links can’t trigger the action by accident.

Checklist

List the phone calls and check-ins your team makes daily. Each is an alert candidate.
One owner per alert. Broadcasts breed filters.
Put a stale-status timer on your two stickiest statuses.
Give customer-facing alerts a branded HTML template before enabling them.
Revisit after a month and delete anything people admit to ignoring.