Project Milestone Notifications

Most client dissatisfaction in project work is not about the work. It is about not knowing. The engagement starts with a kickoff call where everybody is aligned, and then the firm disappears into delivery for three weeks. Nothing is wrong - the team is heads-down, the project is on track - but from the client's side a silent two weeks is indistinguishable from a stalled one. So they email to ask how it is going. Somebody writes a paragraph back. Two weeks later they ask again, slightly more pointedly, and this time the account manager writes four paragraphs and copies in a partner. None of that correspondence advanced the project by a single hour.

The cost shows up in three places. First, interrupt cost: every "just checking in" email pulls a delivery person out of the work to write a status update, and the person best placed to write it is always the person least able to spare the time. Second, inconsistency: one project manager sends weekly updates with screenshots, another sends nothing for a month, and the client's experience of the firm depends entirely on who they were assigned. Third, and most expensive, the surprise. A date slips internally in week two, nobody tells the client because it might still be recoverable, and the client finds out in week five when the thing they had promised their own board does not arrive. The delay was forgivable. Not being told was not.

The underlying failure is that status lives in two places that never speak. The pipeline, or the spreadsheet, or the project tool knows exactly what stage the work is at and what is blocking it. The client knows none of that, and the only bridge between the two is a human remembering to write an email. This build removes the human from that bridge. Every stage change in the delivery pipeline fires a client-facing notification written from a per-milestone template, so the client is told what was just completed, what happens next, what is needed from them and when the next update lands - and the firm's internal escalation fires at the same moment, from the same event, so nobody finds out late.

Pipeline and stages

One pipeline, Project Delivery, where the stages are the milestones. This is the whole design: the client-facing notification is driven by the stage change, so the pipeline being accurate and the client being informed become the same act. A delivery lead who moves a card has already told the client.

• Kickoff Scheduled - project exists, kickoff call booked, nothing started.
• Discovery - gathering inputs, access, requirements.
• In Progress - the main body of the work. For longer engagements this splits into In Progress - Phase 1, Phase 2 and so on, each firing its own notification.
• Internal QA - the firm's own review, before the client sees anything.
• With Client for Review - deliverable sent, awaiting feedback.
• Revisions - feedback received, changes being made.
• Approved - client has signed off.
• Handover - files, credentials, documentation and training transferred.
• Closed - final invoice raised, feedback captured, project archived.

Blocked states are tags rather than stages, so a project waiting on client input keeps its real stage and does not lose its place. A second pipeline, Project Escalations, holds red projects: Flagged, Partner Engaged, Recovery Plan Agreed, Resolved.

Calendars

• Project Kickoff - 60 minutes, delivery lead plus the account owner, booked by the client from the handover email when a contract is executed.
• Review Session - 45 minutes, offered when a deliverable goes to the client, as an alternative to written feedback. Assigned to the delivery lead.
• Unblock Call - 15 minutes, surfaced only on the awaiting-client path after two chases. Deliberately short, so it is easy to accept.
• Handover Session - 30–60 minutes depending on project type, booked at the Approved milestone.

Custom fields

• project_name - text, the client-facing name
• project_code - text, the internal reference used in every subject line so threads stay sorted
• delivery_lead - user reference, moves the cards
• account_owner - user reference, owns the relationship and receives escalations
• project_start_date, target_delivery_date
• original_delivery_date - date, written once and never overwritten, so slippage is measurable
• current_milestone, next_milestone - text, written by the automation on each stage change
• next_milestone_due - date
• stage_entered_date - date, reset on every stage change, drives the SLA monitor
• stage_sla_days - number, set per stage from the project type
• notify_level - dropdown: Every milestone, Key milestones only, Weekly digest only, No automated updates
• notify_contacts - text, who receives updates
• notify_channel - dropdown: Email, Email plus SMS
• client_action_required - long text, what the firm needs from the client right now
• client_action_due - date
• blocked_reason, blocked_since_date
• project_health - dropdown: Green, Amber, Red
• revision_round - number
• date_change_count - number, how many times the delivery date has moved
• last_client_update_sent - date, the staleness clock
• handover_items - long text, the checklist of what gets transferred

Tags

• project-active - the master gate
• notify-all, notify-key, notify-digest, notify-none - set from notify_level and read by every send step
• awaiting-client - the single most important tag in the build. Freezes the SLA clock, starts the client chase, and changes the digest copy from "we are working on it" to "we are waiting on you".
• stage-overdue - applied when days in stage exceed stage_sla_days
• project-amber, project-red - health flags, driving different escalation paths
• revision-loop - applied at revision round 3, triggers a scope conversation rather than another round
• date-slipped - applied when target_delivery_date moves past original_delivery_date
• project-paused - the manual brake. Suppresses every client-facing message in the build.
• update-stale - applied when last_client_update_sent is more than 10 days ago, regardless of stage. This is the backstop that catches a long quiet stage.

Forms

• Project Setup - internal, completed at kickoff. Project name and code, delivery lead, account owner, start and target dates, project type which sets the stage SLAs, the milestone list for this project, and the handover checklist. Writes every field and creates the pipeline card.
• Client Communication Preferences - client-facing, sent with the kickoff confirmation. Who should receive updates, how often, and whether SMS is welcome for anything urgent. Writes notify_level, notify_contacts and notify_channel. Letting the client choose the volume is what stops milestone notifications becoming noise.
• Client Input Request - sent whenever awaiting-client is applied. Structured: exactly what is needed, why it blocks the work, and a due date. One form per blocking item, so nothing is bundled and lost.
• Review and Approval - sent with every deliverable. Three options: approve as is, approve with minor comments, or request changes with structured feedback. Writes to revision_round and drives the stage change.
• Delay Notice - internal, required before target_delivery_date can be changed. Reason, new date, whose side the cause sits on, and the recovery plan. This form is the gate that stops a date moving silently.
• Project Close Feedback - client-facing, two questions plus free text, sent after handover.

BO's role and guardrails

BO covers the inbound traffic that milestone notifications generate, which is the point - the notifications create replies, and replies are cheaper to handle than the status requests they replace.

• BO answers status questions directly from the record: what stage the project is at, what milestone is next, when it is due, what the firm is waiting on, when the next update lands.
• BO chases outstanding client input on the schedule in workflow 5, by email and SMS, and logs what arrives.
• BO books and reschedules Review Sessions, Unblock Calls and Handover Sessions.
• BO may read back client_action_required verbatim and may confirm dates currently on the record.
• BO may never commit to a date that is not already in target_delivery_date or next_milestone_due, and may never say a date will be met or missed. Any reply pressing for a new date, asking whether the project will land on time, or asking to bring a date forward is routed to the delivery lead and the account owner, and BO replies only: "I do not want to guess at that - [delivery lead] will confirm today."
• BO may never accept, decline or price a scope change, discuss fees or hours, or agree to additional work. Any such reply applies awaiting-client removal, notifies the account owner, and stops BO from replying further on that thread.
• BO may never explain a delay or offer a reason for one. Delay communication is always human-reviewed, which is what workflow 7 enforces.
• BO stands down the moment the delivery lead or account owner replies in the thread.

Numbers and channels

• Milestone notifications go by email from the delivery lead's own address on the authenticated firm domain, with project_code in every subject line so the client can thread the whole project.
• One registered SMS number, used for three things only: an unblock prompt when the project is genuinely held up, a review reminder before a session, and a same-day heads-up that a delay notification is landing in their inbox. Never for routine milestones, and only to clients who opted into SMS on the preferences form.
• Internal notifications by Slack or Teams webhook into a delivery channel, carrying every stage change, every overdue stage, every amber or red flag and every date change.
• Quiet hours 8am to 7pm recipient local time, weekdays, on SMS. Milestone emails send immediately on the stage change during working hours, and hold until 08:30 next working day otherwise - nobody needs a project update at 23:40.

1. A contract is executed and the handover from the proposal pipeline fires. The delivery lead completes the Project Setup form: project name, code DEL-0412, delivery lead and account owner named, start date, target delivery six weeks out, project type set to Implementation which loads the stage SLAs, nine milestones listed, and the handover checklist populated. The card is created in Project Delivery at Kickoff Scheduled, original_delivery_date is written and locked, project_health is set to Green.
2. The client receives the kickoff confirmation and the Client Communication Preferences form. They choose Every milestone, name two recipients plus their operations manager, and opt in to SMS for anything urgent. notify-all is applied.
3. The kickoff call happens. The delivery lead moves the card to Discovery. That stage change fires the milestone notification immediately: "Kickoff complete. We are now in discovery, which means collecting the three things on the list below. Next milestone: Discovery complete, due [date]. What we need from you: access to the two systems we discussed, by Friday." current_milestone, next_milestone and next_milestone_due are written, stage_entered_date is reset, last_client_update_sent is set.
4. Because the notification named a client action, awaiting-client is applied, client_action_required and client_action_due are written, the stage SLA clock is frozen, and the Client Input Request form goes out with the two access items itemized.
5. Friday passes with one of the two systems still not granted. BO sends a short chase naming only the outstanding item, then an SMS prompt the following Monday. On Tuesday the access arrives. awaiting-client is removed, the SLA clock resumes with the frozen days excluded, and the delivery lead is notified that they are unblocked.
6. Discovery completes. The card moves to In Progress - Phase 1 and the milestone notification fires automatically with the Phase 1 template: what was learned in discovery, what is being built, the next milestone date, and the line that prevents half the inbound status emails - "Nothing needed from you during this phase. Next update: [date]."
7. Eleven days into a stage with a nine-day SLA, the monitor applies stage-overdue and sets project_health to Amber. No client message goes out. The delivery lead and account owner are notified internally with the days-in-stage figure and asked to either move the card or log a delay.
8. The delivery lead can recover two of the three days but not all of it. They complete the Delay Notice form: reason, new target date four days later, cause on the firm's side, recovery plan stated. Only now can target_delivery_date change. date-slipped is applied and date_change_count becomes 1.
9. The delay workflow does not send automatically. It drafts the client notification from the form and holds it for the account owner's approval - the one message in this build a human must sign off. The owner edits one sentence and releases it. The client receives it the same day, along with an SMS heads-up because they opted in. The client is annoyed about the date and not about the firm, which is the whole difference.
10. Phase 1 completes and passes Internal QA. The card moves to With Client for Review. The deliverable goes out with the Review and Approval form and the offer of a 45-minute Review Session. awaiting-client is applied with a five-working-day due date.
11. The client books the Review Session instead of using the form. Reminders fire at 24 hours and 2 hours; the delivery lead receives a pre-call brief with the deliverable, the revision history and the current health flag. On the call the client asks for two changes.
12. The lead logs them, moves the card to Revisions, and revision_round becomes 1. The notification fires: "Two changes logged from today's session: [list]. Back with you by [date]." The client never has to wonder whether their feedback was captured.
13. Revisions complete, the deliverable goes back, and the client submits the form choosing Approve as is. The card moves to Approved. The notification confirms sign-off, states what happens next, and carries the Handover Session booking link.
14. Handover runs. The card moves to Handover, then Closed. The close workflow transfers everything on handover_items, raises the final invoice in the connected accounting system, sends the Project Close Feedback form, notifies the account owner that the project is complete with total elapsed days and days lost to client wait, and - because the engagement is a retainer - hands the account to the reporting cycle and the renewal clock.
15. Through all of it, the staleness backstop has been running daily. Any project where last_client_update_sent passes ten days gets update-stale and a short holding note, so a long quiet stage never becomes silence. And every Friday leadership receives the delivery health report: projects by health flag, stages overdue, days lost to client wait, date changes, and every project whose last client update is more than a week old.

1. Project Setup and Notification Profile

Trigger: Project Setup form submission, or an opportunity reaching Fully Executed in the firm's proposal pipeline.

Conditions: none. Every project gets a card and a notification profile, or it appears on the gap list in workflow 9.

Actions in order:

1. Create the card in Project Delivery at Kickoff Scheduled. Write project_name, project_code, delivery_lead, account_owner, project_start_date, target_delivery_date, handover_items.
2. Write original_delivery_date equal to target_delivery_date and never write to it again. Every slippage measurement in this build depends on that field staying honest.
3. Load stage_sla_days per stage from the project type, set stage_entered_date to today, set project_health to Green, revision_round and date_change_count to 0.
4. Apply project-active and notify-all as the default, which the client can change.
5. Send the kickoff email from the delivery lead with the Project Kickoff booking link: "Hi [first name], [project_name] is live and I am your point of contact. First thing: 60 minutes to agree the plan and what we need from each other - [booking link]. Second thing, and it will save us both time later: tell me how you want to be kept informed. [preferences form link]. Some clients want a note at every milestone, some want one summary a week. Both are fine; what I would rather avoid is you having to email me to find out where things are."
6. Wait 3 days. If the preferences form is not submitted, send one reminder and proceed on notify-all.
7. On preferences submission: write notify_level, notify_contacts, notify_channel. Swap the notify tag to match. Confirm: "Set. You will hear from me [at every milestone / when the key milestones land / once a week on Fridays], and you will never have to ask where we are."
8. Notify the delivery lead with the final profile.

Exit: single pass.

2. Milestone Reached Notification

The core workflow. Everything else in this build supports it.

Trigger: the card changes stage in Project Delivery.

Conditions: project-active present, project-paused absent. Branch on the notify tag: notify-all sends on every stage change; notify-key sends only on Discovery complete, each phase complete, With Client for Review, Approved and Handover; notify-digest sends nothing here and lets workflow 9 carry it; notify-none sends nothing at all. Outside working hours, hold the send until 08:30 the next working day.

Actions in order:

1. Write current_milestone as the new stage's client-facing name, next_milestone as the following stage, and next_milestone_due as today plus that stage's stage_sla_days. Reset stage_entered_date to today. Remove stage-overdue.
2. Select the per-milestone template. Each stage has its own, and all of them follow the same four-part shape, which is what makes them answer the client's questions before they are asked: what just happened, what happens next and by when, what we need from you, when you will next hear from us.
3. Send from the delivery lead to notify_contacts, subject "[project_code] [project_name] - [current_milestone]". Example body, Discovery complete: "Hi [first name], discovery is done. We have what we need on [area one] and [area two], and the one surprise was [item] - it does not change the date. Next: we move into build, which runs to [next_milestone_due]. Nothing needed from you during this phase. You will hear from me when build completes, or sooner if anything changes."
4. Example body, With Client for Review: "Hi [first name], the first deliverable is ready: [link]. Two ways to give us feedback - the form takes five minutes and keeps everything in one place [form link], or book 45 minutes and we will walk through it together [booking link]. Either is fine. We need one of them by [client_action_due] to hold the [target_delivery_date] date."
5. Write last_client_update_sent as today. Remove update-stale.
6. If the new stage requires client input - Discovery, With Client for Review, or any stage flagged as client-dependent on the project type: apply awaiting-client, write client_action_required and client_action_due, and hand to workflow 5.
7. Post to the internal delivery channel: "[project_code] moved to [current_milestone]. Lead [delivery_lead]. Next due [next_milestone_due]. Health [project_health]."
8. If the new stage is Approved: hand to workflow 8. If Revisions: hand to workflow 6.

Exit: fires once per stage change. A card moved backwards fires too, with the regression template - clients tolerate a step back far better than they tolerate discovering one.

3. Stage SLA Monitor and Health Flag

Trigger: scheduled daily at 07:00 across all cards tagged project-active.

Conditions: days since stage_entered_date, excluding any days the card spent tagged awaiting-client. This exclusion is essential - a project should never be marked amber for a delay the client caused, and the days-lost figure is itself worth reporting.

Actions in order:

1. Calculate adjusted days in stage. Compare to stage_sla_days.
2. At 100 per cent of SLA: notify the delivery lead only. "[project_code] has been at [current_milestone] for [n] days, which is its full allowance. Move it or log a delay today." No client message. Nothing has gone wrong yet.
3. At 120 per cent: apply stage-overdue and project-amber, set project_health to Amber, notify the delivery lead and account_owner jointly, and create a task on the lead due same day: "Move [project_code] or complete the Delay Notice form."
4. At 150 per cent, or when target_delivery_date is in the past: apply project-red, set project_health to Red, create a card in Project Escalations at Flagged, and notify the account owner, the practice lead and the partner. Create a task on the partner due within 1 business day: "Review [project_code] - red."
5. Still no automatic client message. Every client-facing word about a delay goes through workflow 7 with human approval, because an automated apology for a slip the firm has not yet decided how to fix makes things worse.
6. On the card moving stage: remove stage-overdue, and if no other condition holds, reset project_health to Green and remove the amber or red tag. Notify the account owner that the project has recovered.
7. Daily, also check last_client_update_sent. If more than 10 days ago and notify-none is not set, apply update-stale and hand to workflow 9's staleness branch.

Exit: runs continuously while the project is active.

4. Kickoff Call Handling

Trigger: a booking on the Project Kickoff calendar.

Conditions: branch on appointment status.

Actions in order:

1. Send confirmation with the agenda and the pre-work: "Sixty minutes, and here is the agenda so nobody has to improvise: the outcome we are aiming at, the plan and the dates, what we need from you and when, and how you will hear from us. One thing to bring: who on your side signs off on deliverables."
2. Wait until 24 hours before. Send email reminder with the agenda again and any pre-work still outstanding.
3. Wait until 2 hours before. Send SMS reminder if notify_channel includes SMS.
4. Wait until 1 hour before. Send the delivery lead and account owner a brief: the executed scope, the client's stated outcome from the scoping stage, target_delivery_date, the milestone list, and the communication preferences the client chose.
5. Wait until 1 hour after the slot. Branch on status.
6. Showed: create a task on the delivery lead due same day: "Move [project_code] to Discovery and populate client_action_required from the kickoff." Moving the card is what sends the client their first milestone notification, so the task is phrased to make that obvious.
7. No-show: send one rebooking link, wait 1 day, send a second, notify the account owner. A client who misses their own kickoff is a project-risk signal, not a calendar accident.
8. Rescheduled more than twice: notify the account owner and the practice lead, and push target_delivery_date consideration to workflow 7 - a start date that slips has to move the end date or the plan is fiction.

Exit: card reaches Discovery.

5. Awaiting Client Chase

Trigger: awaiting-client applied, by workflow 2 or manually by the delivery lead.

Conditions: project-paused absent. The SLA clock in workflow 3 is frozen for the whole duration of this workflow, and the frozen days are recorded.

Actions in order:

1. Write blocked_since_date and blocked_reason. Send the Client Input Request form from the delivery lead: "Hi [first name], one thing holding us up on [project_name]: [client_action_required]. Here is the form, or just reply to this with it: [form link]. I need it by [client_action_due] to keep [target_delivery_date] intact." Naming the consequence is what gets a reply.
2. Wait until 1 day before client_action_due. BO sends a short reminder naming only what is still outstanding - never a re-list of items already supplied, which is the fastest way to make a client stop reading.
3. Wait until the due date passes by 1 day. BO sends a second chase and, if notify_channel includes SMS, an SMS within quiet hours: "Hi [first name] - [firm] on [project_code]. Still waiting on [item] to carry on. Reply here or [short link]. Reply STOP to opt out."
4. Wait 2 days. BO offers the 15-minute Unblock Call: "Hi [first name], rather than chase you again - 15 minutes and we will get [item] sorted together on the call: [booking link]. Sometimes it is faster than finding it."
5. Wait 3 days. Notify the delivery lead and account owner: "[project_code] blocked [n] days on [item]. [n] days now excluded from the delivery schedule." Create a task on the account owner to call the client.
6. Wait 5 days. Send the schedule-impact notification from the delivery lead, which needs no approval because it states a fact rather than a reason: "Hi [first name], we have been waiting on [item] since [blocked_since_date], which is [n] working days. That time comes out of the schedule, so [target_delivery_date] is no longer realistic unless we get it this week. Not a complaint - I would just rather tell you now than tell you later." Notify the account owner that this went out.
7. Wait 10 days from blocked_since_date. Apply project-red, escalate to the partner, and create an escalation card. A project blocked ten working days on client input is a commercial conversation, not a delivery one.
8. On the input arriving: remove awaiting-client, clear blocked_reason and client_action_required, record the frozen day count against the project, resume the SLA clock, and notify the delivery lead: "[project_code] unblocked. [n] days lost to client wait, excluded from SLA." Confirm to the client: "Got it, thank you - back on it today."

Exit: input received, or the project is paused or escalated.

6. Review and Revision Loop

Trigger: Review and Approval form submission, a Review Session marked showed, or the card moved to Revisions.

Conditions: branch on the form answer, and on revision_round.

Actions in order:

1. Approve as is: remove awaiting-client, move the card to Approved, hand to workflow 8.
2. Approve with minor comments: write the comments, move to Approved, create a task on the delivery lead to action the comments during handover, and confirm to the client: "Approved with your two notes - both will be in before handover."
3. Request changes: increment revision_round, write the structured feedback to the card, move to Revisions, remove awaiting-client, and send the acknowledgement: "Hi [first name], got your feedback - [n] changes logged: [list]. Back with you by [new next_milestone_due]. If I have misread any of these, tell me now rather than when you see the next version." Reading the changes back is what prevents a second revision round caused by a misunderstanding rather than by the work.
4. Create a task on the delivery lead with the revision list attached and a due date.
5. Review Session showed branch: create a task on the lead due same day: "Log the changes agreed on today's [project_code] call and move the card." Moving the card sends the acknowledgement automatically.
6. If no form submission and no booking by client_action_due: hand back to workflow 5's chase ladder - a deliverable sitting unreviewed is the most common silent project stall there is.
7. At revision_round 3: apply revision-loop, notify the account owner and the practice lead, and create a task on the account owner: "Third revision round on [project_code]. Before a fourth, have the conversation: is this a quality problem, a brief problem, or scope that was never agreed? Do not let a fourth round happen by default."
8. At revision_round 4: notify the partner. Suppress the automated revision acknowledgement and require the account owner to write to the client personally.

Exit: approval recorded, or the project escalates.

7. Delay and Date Change Notification

The one workflow in this build with a mandatory human gate.

Trigger: Delay Notice form submission. The form is also the only permitted route to changing target_delivery_date; the field is locked against direct editing.

Conditions: branch on whose side the cause sits, as stated on the form, and on date_change_count.

Actions in order:

1. Write the new target_delivery_date. Increment date_change_count. Apply date-slipped if the new date is later than original_delivery_date. Recalculate next_milestone_due.
2. Draft the client notification from the form's reason and recovery plan, and hold it for approval by account_owner. Nothing sends until they release it. Notify them immediately with a 4-working-hour task: "Delay notification for [project_code] drafted and waiting. Client has not been told yet."
3. Firm-side cause, draft text: "Hi [first name], I need to move the [project_name] delivery date from [old date] to [new date]. The reason is [reason] - that is on us, not on anything you did. Here is what we are doing about it: [recovery plan]. What this means for you: [impact]. If that date causes you a problem on your side, call me and we will look at what can be reprioritised."
4. Client-side cause, draft text: "Hi [first name], the delivery date moves from [old date] to [new date]. The driver is [reason] - the [n] working days we spent waiting on [item] come straight off the back end of the schedule. Nothing to apologize for on either side, but I would rather you heard it from me now than discovered it in two weeks."
5. On release: send the email, write last_client_update_sent, and if notify_channel includes SMS send a heads-up: "Hi [first name] - [delivery lead] has just emailed you about the [project_code] timeline. Worth a read when you get a moment." A delay email that sits unread for three days is a delay the client still does not know about.
6. If the account owner does not release within 4 working hours: notify them again and copy the practice lead. The point of the gate is review, not delay.
7. Post to the internal delivery channel: "[project_code] date moved [old] to [new]. Cause: [firm or client]. Change count: [n]. Health [project_health]."
8. If date_change_count reaches 2: notify the practice lead and partner, and require a recovery plan review before any third change. At 3: the partner takes over client communication on the project entirely.

Exit: notification released and sent.

8. Approval, Handover and Close

Trigger: card moved to Approved.

Conditions: none.

Actions in order:

1. Send the approval notification from the delivery lead: "Hi [first name], signed off - thank you. Last step is handover: I will transfer [handover_items summary] and walk your team through it. Book that here: [handover booking link]. Allow [duration]."
2. Create the handover task set on the delivery lead from handover_items: files and source assets, credentials and access, documentation, training session, and the named internal owner on the client side.
3. On the Handover Session being held: move the card to Handover. Send the handover pack email with everything transferred listed explicitly: "Everything from [project_name], in one place: [list with links]. All of it is yours. Two things worth keeping: [key item] and [key item]."
4. Raise the final invoice in the connected accounting system. If no connection exists, create a finance task.
5. Move the card to Closed. Remove project-active. Apply the client's post-project tag.
6. Wait 2 days. Send the Project Close Feedback form from the account owner, not the delivery lead - a different voice asking makes an honest answer more likely: "Hi [first name], two questions on how [project_name] went, and the second one is the one I actually care about: what should we have done differently? [form link]"
7. On feedback submission: write it to the account record and notify the delivery lead and account owner. A score at the top of the range hands to the firm's review or referral workflow. Anything in the bottom half creates a same-day task on the account owner to call.
8. Notify the account owner with the project post-mortem figures: total elapsed days against planned, days lost to client wait, number of stages that went overdue, date_change_count, revision_round, and final health flag.
9. If the engagement continues as a retainer: hand the account to the reporting cycle and the renewal clock so neither has to be set up from scratch later.
10. Wait 30 days. Send one check-in from the account owner: "Hi [first name], a month on from [project_name] - is it doing what you wanted it to do? No agenda, I just want to know whether it stuck."

Exit: after the 30-day check-in.

9. Weekly Client Digest, Staleness Backstop and Internal Health Report

Trigger: scheduled. The client digest runs Fridays at 16:00 local; the staleness branch runs daily at 07:30; the internal report runs Fridays at 08:00.

Conditions: the client digest goes only to projects tagged notify-digest, plus any project tagged notify-key that has had no milestone change this week. Nothing goes to notify-none or project-paused.

Actions in order, client digest:

1. Compose per project: current_milestone, what moved this week, next_milestone and next_milestone_due, anything outstanding from the client, and target_delivery_date.
2. Send from the delivery lead: "Hi [first name], [project_code] end-of-week: we are at [current_milestone]. This week [what moved]. Next up is [next_milestone] by [next_milestone_due]. [Nothing needed from you / We are still waiting on: [client_action_required]]. Delivery still tracking to [target_delivery_date]."
3. Write last_client_update_sent. Remove update-stale.
4. Suppress the digest entirely if a milestone notification already went out that day - two messages in one afternoon reads as noise, not diligence.

Actions in order, staleness backstop:

1. For any active project where last_client_update_sent is more than 10 days ago: apply update-stale, notify the delivery lead, and send a short holding note from them: "Hi [first name], no milestone to report on [project_code] this week - we are still inside [current_milestone] and it is going fine. Next thing you will hear from me is [next_milestone], due [next_milestone_due]. Nothing needed from you." This message exists purely so a long stage never becomes silence.
2. Cap it at one holding note per 10-day window, so a genuinely long build phase produces a note roughly every two weeks rather than a drip.

Actions in order, internal health report:

1. Email the partner group and practice leads: every active project with its health flag, stage, days in stage, delivery lead, target date and change count; all red and amber projects with the reason; every project tagged awaiting-client with days blocked; every project tagged revision-loop; every project tagged update-stale; and any executed engagement with no project card at all.
2. Append three aggregate figures: median days in stage by stage name, which exposes the real bottleneck across the firm; total days lost to client wait this month; and on-time delivery rate against original_delivery_date.
3. Create one task per project on the no-card list, assigned to its account owner.

Exit: single pass per scheduled run.

The client stops having to ask. Every milestone generates its own notification, so the question "where are we?" gets answered before it is asked, and the delivery team stops being interrupted to write status updates. That alone usually recovers several hours a week per delivery lead - not glamorous time, but time that was being spent on correspondence rather than work.

The second change is that pipeline accuracy becomes self-enforcing. When moving a card is the act that tells the client, delivery leads keep the board current, because the board is now the client communication rather than an administrative chore performed afterwards. Firms that have tried and failed to keep a delivery board up to date usually find this is the mechanism that finally does it.

The third change is the one that protects the relationship: delays stop being discoveries. A date cannot move without a form, the form produces a drafted client notification, and the notification waits on a named human for four working hours and no longer. A client who is told on the day a date moves is dealing with a schedule problem. A client who finds out three weeks later is dealing with a trust problem, and trust problems do not get fixed by hitting the revised date.

What to measure:

• Inbound status requests per project - the clearest proof the build is working. Count them before go-live and again after two months; a well-templated milestone notification should take this close to zero.
• Median days in each stage - across the whole book, by stage name. This is where firms find the bottleneck they have been guessing at, and it is almost never the stage they expected.
• Days lost to client wait - the cumulative awaiting-client total. This number is worth putting in front of clients at the quarterly review; it reframes delay conversations permanently.
• On-time delivery against original_delivery_date, not against the current target. Measuring against a date that moves tells you nothing.
• date_change_count distribution - how many projects move their date once, twice, three times. Multiple changes on one project almost always means the original estimate was wrong, not that delivery was slow.
• Average revision rounds - rising means the brief or the internal QA stage is weak, not that clients are getting fussier.
• Time from delay logged to client notified - should be hours. If it is days, the approval gate has become a bottleneck rather than a check.
• Close feedback scores and the "what should we have done differently" answers - the free text is where the real information is.

Over a few quarters the stage-timing data becomes an estimating tool. A firm that knows its implementation projects historically spend eleven days in discovery and nine in QA can scope the next one from evidence rather than optimism.

Decide these before you build

• Your milestone set, and what each one is called to a client. Internal stage names are rarely the right client-facing words - "Internal QA" is honest but "In final checks" lands better. Write both columns before building anything, and keep the list short. Nine stages is about the limit; a fourteen-stage pipeline produces fourteen notifications and a client who stops reading them.
• Stage SLAs per project type. Base them on what the last ten projects actually took, not on what you hope they will take. An SLA set optimistically turns the whole board amber in week two and the team learns to ignore the flags, which is worse than having none.
• Who writes the templates. One person should write all of them in one sitting so the voice is consistent, and every one should follow the same four-part shape: what happened, what is next and when, what we need from you, when you will next hear from us. The fourth part is what suppresses inbound status requests, and it is the part most firms leave out.
• What a client can choose. Offer real notification levels and honor them. A client who asked for a weekly digest and gets nine milestone emails will unsubscribe from all of it, including the one about the delay.
• Who approves delay notifications, and their deputy. This is the only human gate in the build and it has a four-hour clock on it. If the named person is routinely unavailable, the gate becomes the delay.

Integrations

• Project management tool - if the firm runs delivery in Asana, Jira, Monday, ClickUp or similar, decide now whether the platform pipeline is the source of truth or a mirror. Mirroring through Zapier or Make can work, but every sync is a place where the client gets told something that is not true any more. A one-way push from the project tool into the pipeline, with the notification firing from the pipeline, is usually the cleanest arrangement. Two-way sync is where this build gets fragile.
• Calendar - Google Calendar or Outlook, two-way sync, for every delivery lead and account owner.
• File delivery - Google Drive, SharePoint or Dropbox, for deliverable links and the handover pack. Use permissioned links rather than public ones; client deliverables are confidential.
• Accounting - QuickBooks, Xero or equivalent for the final invoice at close. A finance task is the fallback.
• Internal notifications - Slack or Microsoft Teams webhook into a delivery channel. The red-flag and date-change alerts need to be seen the same day.

Numbers, SMS and deliverability

• Provision one SMS number and complete A2P 10DLC brand and campaign registration in the United States, or the local equivalent. Register it as customer care or account notifications. Allow weeks.
• SMS is opt-in per client through the preferences form, and only used for three things: unblock prompts, review reminders, and the heads-up that a delay email has landed. Routine milestones never go by SMS.
• Opt-out language on first SMS contact, STOP honoured globally. Quiet hours 8am to 7pm recipient local time, weekdays, enforced in the workflow.
• SPF, DKIM and DMARC on the firm domain before go-live. Milestone notifications send from the delivery lead's real address with project_code in the subject line, which keeps the project in one thread and makes it searchable for the client.
• Test the overnight hold. A stage change at 22:00 should produce an email at 08:30, not at 22:01.

Pilot before you roll out

• Run the build on two projects with sympathetic clients before applying it to the whole book, and ask those clients directly whether the volume is right. Notification fatigue is the main failure mode of this build, and it is far cheaper to discover on two projects than on thirty.
• Run the SLA monitor in notification-only mode for two weeks first, so the team sees which projects would have gone amber and can argue about the thresholds before anything flags.
• Check the templates for anything that reads as automated. A milestone notification that sounds generated defeats its own purpose; the client should read it as their delivery lead writing to them, because in substance it is.

Compliance

• Project status notifications to a client under a live engagement are service communications rather than marketing, and sit outside most marketing consent regimes. The 30-day post-project check-in is closer to relationship communication - keep marketing consent as a separate field so the distinction holds.
• In the United Kingdom and European Union, client contact data in these workflows is personal data under the GDPR or UK GDPR. Document the lawful basis, limit retention, and keep the recipient list current - notifications continuing to a person who has left the client's business is a disclosure problem as well as a pointless one.
• Deliverables and project detail are confidential. Use permissioned, expiring links; never attach confidential deliverables to an SMS or to an email address the client has not confirmed; and restrict who inside the firm can open the delivery board if projects carry sensitive client information.
• Where the project itself is regulated - clinical, financial, legal or audit work - the content and timing of client communication may carry obligations of its own, including records of what was communicated and when. The notification log doubles as that record, which is useful, but only if retention is set deliberately.
• None of this is legal advice. Have the firm's own counsel confirm confidentiality handling, retention periods, data processing arrangements where deliverables contain third-party personal data, and any sector-specific communication or record-keeping obligations before go-live. Where the scope and pricing of a build need working out, point the client at a scoping call at bookings.appbo.io.