What this automation does
Every Thursday afternoon, each project lead receives a draft status update built from what actually changed in the project tool. They spend five minutes editing instead of an hour writing.
- Snapshot. Once a week the workflow records every task or issue in each project with its status, owner, due date, estimate and parent milestone.
- Diff. Code compares this snapshot with last week’s to find work completed, tasks added (possible scope growth), due dates that moved, items blocked for more than a few days and overdue work.
- Suggest a status color. Written rules turn the diff into a suggested green, amber or red. For example, any milestone moved past its committed date suggests red, and overdue work above a set share of open tasks suggests amber.
- Gather context. Recent comments on blocked or slipped items are collected, along with approved action items from that project’s meetings.
- Draft. A model writes the update in a fixed structure (status, done this week, next week, risks, decisions needed) in separate versions for the team, leadership and the client.
- Review. The project lead gets the drafts in Slack or a Google Doc, confirms or overrides the color with a reason, and edits the text.
- Publish. Approved updates post to the project channel, go to the client by email and update the status field in the project tool. Leadership gets a one-page rollup of all projects.
When it is worth building
This pays off when project leads run several projects at once and each one needs a weekly written update, which is common at agencies, consultancies, software teams and construction firms. If PMs spend Friday afternoons rewriting what the project tool already knows, the time adds up fast.
It is the wrong first step if the project tool does not reflect reality. Automation on stale data creates polished, confident updates that mislead people. Fix the habits first. It is also unnecessary if your tool’s built-in AI summary already meets your needs. Build when data spans tools (Jira plus a time tracker plus Slack), when client-facing formatting matters, or when leadership wants one view across the portfolio. For agencies that also report marketing results to clients, combine this with automated client reporting. Our custom vs off-the-shelf comparison helps with that build-or-buy decision.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Sources | Jira, Asana, Linear or monday.com APIs | Read the current state of every task and milestone |
| Snapshot store | Postgres | Most project tool APIs show current state, and history is awkward to reconstruct |
| Diff and status rules | SQL and a code step | Slips, scope changes and color rules must be exact and explainable |
| Context | Task comments, and approved meeting action items | Explains why something slipped, not only that it did |
| Drafting | Claude Sonnet 5.5 with audience-specific templates | Clear writing in a consistent format for each audience |
| Review | Slack interactive message or a Google Doc draft | The project lead stays accountable for what is said |
| Publish | Slack, email, status field in the project tool | Updates land where each audience already looks |
Our Jira notes cover the API limits that matter when you pull comments across a large instance.
How to build it
- Agree on the format and color rules. Sit with two or three project leads and write down the update structure and the exact rules for green, amber and red. Get sign-off before building anything.
- Map projects across tools. Give each project one ID that links its Jira project, Slack channel, client contact and time tracking code.
- Start snapshots. Record weekly snapshots from day one. Two weeks of history is the minimum before diffs mean anything.
- Build the diff. Completed, added, moved, blocked and overdue, each with the task names and owners attached.
- Write the drafting prompts. One per audience. Rules: mention every red or amber item, never invent a date, never assign blame by name in client or executive versions, and say plainly when data is missing.
- Set the review rhythm. For example, drafts at Thursday 3pm and sending at Friday 10am. Unapproved drafts are never sent automatically.
- Add the portfolio rollup. A single page for leadership listing every project, its color, and the one-line reason for anything not green.
- Track edits. Measure how much leads change each draft and use the biggest edits to improve prompts and rules.
What breaks in production
- Bulk closing. Teams that close a week of tasks at once on Friday make Thursday’s snapshot look stalled. Align the snapshot time with how the team actually works.
- Watermelon projects. Green on the outside, red inside. If leads routinely override red to green, review the overrides monthly with leadership.
- Hidden scope growth. New work added as subtasks under existing items does not show up as new tasks. Count subtasks and story points, not just top-level items.
- Internal comments leaking. “Client still has not sent the content” is fine internally and harmful in a client email. Keep internal comments out of the client prompt entirely, not just filtered afterward.
- Tools that disagree. Jira says a feature shipped, but the client sign-off task in Asana is still open. Decide in advance which source wins for each milestone type.
- API limits on large instances. Pulling every comment for every issue each week can hit rate limits. Fetch only items that changed since the last snapshot.
Timeline and cost
One project tool, one Slack workspace and three audience templates typically take two to three weeks. Lumeor prices this work at $4,000 to $10,000. Pulling from several tools, adding the portfolio rollup and client email delivery move it toward the upper end. Running costs are hosting plus model usage once a week per project.
How to measure success
- PM hours per week spent writing status updates
- Share of updates sent on time
- Share of drafts approved with light edits
- Projects that went red with no amber warning in a prior week
- Stakeholder questions that the update should have answered
- Project data hygiene, such as the share of open tasks with an owner and a due date