Every stage lists the rule in effect on it and where that rule came from. Set it for one stage, for that kind of stage everywhere, or for everything. Pick who hears: your team in the app and by email, the customer by email and, if you tick it, by text. You can write your own wording per stage, and it still goes out in your branding. It is made only for post-frame and barndominium builders, because that is how the trade works: a barndominium owner wants to hear about every stage, a shed customer wants two.
Also called: stage notifications · who gets emailed · notify the customer on this stage only · too many notifications
Tell the customer when framing finishes on a barndominium, but not on a shed
Try itEvery building type's framing stage used to share one identity, so that sentence could not be said: builders took the customer emails on everything or on nothing, and the ones who found them noisy switched the lot off. Rules attach to a specific stage on a specific building type. Who hears is chosen per rule — the owner, the project manager, the assigned crew's lead, the job's assignees, named people, the customer — your team in the app and by email, the customer by email and, if you tick it, by text.
The shed customer gets six progress emails about a two-week build, sends them to spam, and misses the one about the final payment.
The barndominium customer hears about framing; the shed customer isn't sent an email he will never read. Because a rule hangs off a stage on one building type, builders stop choosing between everything and nothing — and stop switching the whole thing off.
Set it for one stage, for that kind of stage everywhere, or for everything
Try itThree levels, most specific first, and every stage shows the rule actually in effect on it and where it was inherited from. The settings screen works out the winner using the same logic that sends the mail. Two versions of that is how a settings screen ends up confidently describing behaviour the system does not have.
Somebody asks why the customer heard about permits, and nobody can work out which of three settings caused it.
The office can see why someone was or wasn't told, without guessing. The settings screen works out the winning rule with the same logic that sends the mail, so what the screen says is exactly what happens.
Untick the customer on one stage and the customer stops getting that stage
The winning rule applies whole, rather than blending field by field with the broader ones. Blend them and a builder who opens one stage and unticks "customer" still emails the customer, because something wider said so — and the setting he just changed appears to do nothing. Deleting a rule means inherit again; silence is a rule somebody chose, not the absence of one.
You untick the customer on Material Delivery, the email goes out anyway because a company-wide rule said so, and you stop trusting the screen.
A builder who unticks the customer expects the customer to stop hearing, and he does. The winning rule applies whole instead of blending with the broader ones, so the box you just changed is the box that counts.
Renaming a stage does not silently switch its emails off
Rules attach to the stage's own lasting identity, not to the words on it, so tidying "Framing" to "Post Set" keeps everything hanging off it. Before that, a builder saw a better name, lost the notifications behind it, and found out weeks later when a customer said nobody had told him anything.
A stage gets a better name in March, and the customers on that stage hear nothing until one of them rings in June.
Tidying a stage name shouldn't cost you anything. Rules hang off the stage's lasting identity, not its label, so "Framing" can become "Post Set" and every notification stays wired.
Your own wording per stage, still inside your own branding
Per-stage wording drops in with the stage, the project and the person filled in, and it rides inside your own branded email rather than replacing it. Setting up a rule used to swap the customer's email from the builder's colours to a hardcoded block in somebody else's — configuring the automation made the result worse than leaving it alone.
You write friendlier wording for framing, and the customer gets an email with no logo in a colour your company has never used.
The customer reads your words in an email that still looks like your company. Your wording rides inside the branded template with the stage, the project and the person filled in, so customising a stage can never make the email look worse.
- 1Open Settings → Project Stages → Notifications.
- 2Pick a stage and see the rule in effect and where it came from.
- 3Choose who hears — owner, project manager, crew lead, the job's assignees, named people, the customer.
- 4Choose the channels — in-app and email for your team, email and text for the customer.
- 5Write your own wording with the stage, the project and who finished it filled in.
- 6Delete a rule to inherit again; switching it off is a separate choice.
Every building type's framing stage shared one identity, so "email the customer when framing finishes on barndominiums but not on sheds" was unsayable. Builders took the emails everywhere or nowhere, and the ones who found them noisy turned the whole thing off. Worse, setting a rule up used to swap the customer's email from the builder's own branding to a hardcoded block in somebody else's colours — configuring an automation made the result worse than leaving it alone.
- All-or-nothing notification settings
- Renaming a stage orphaning its rules
- Settings screens describing behaviour the system doesn't have
- Configuring an automation degrading the customer's email
What happens when a stage finishes
The piece that acts on a completed stage. It works out which stage it was, finds your rule for it, and sends to the people and channels you chose. A rule you have switched off counts as answered, so a company that chose silence stays silent.
