Create a client-friendly weekly status report from Jira by grouping work under client milestones, checking progress against acceptance evidence, and assigning red, amber or green status with a written reason. Lead with the sponsor decision needed, then show milestone forecasts, risks and next actions with owners and deadlines. Automate preparation where your existing tools allow it, while keeping a delivery lead responsible for the client-facing assessment.
How do I map Jira work to client milestones?
Map work to the deliverables the client has agreed to accept. Record each milestone’s agreed date, forecast, owner and acceptance condition. Keep links to the underlying Jira work for the sponsor to inspect, but explain progress in the client’s language: what they can review, sign off, or expect to use.
Start with the agreed rollout plan. For each milestone, ask the delivery owner: “What must the client be able to review, use or approve before we call this complete?” Record the answer before assigning a status.
Field mapping: Jira to client report
Use the following as a proposed reporting convention. Check the field names and values with your administrator before using them in searches; consult the Atlassian JQL guide for search syntax. Locally configured fields and workflow values need local confirmation.
| Client report element | Proposed field or source mapping | What the delivery lead checks |
|---|---|---|
| Client milestone | fixVersion, where the existing version grouping matches the client commitment; otherwise the existing milestone record |
The grouping covers the agreed deliverable and acceptance condition |
| Supporting work | Work selected by fixVersion; an existing epic relationship where applicable |
Related work covers delivery, review and dependencies |
| Agreed date | Approved plan or locally maintained [agreed date field] |
The date reflects the approved commitment, not the latest forecast |
| Forecast date | due for a relevant work item, or locally maintained [forecast date field] |
The milestone owner confirms whether the date represents the whole milestone or only a supporting task |
| Acceptance | Review record or locally maintained [acceptance field] |
Reviewer, acceptance decision, date and evidence are explicit |
| Risk or blocker | issuetype or labels, using the team’s existing values |
The record explains impact, response, owner and affected milestone |
| Client action | Existing action record, with assignee and due where appropriate |
The person named can approve, decide or provide the requested help |
The field names above are search candidates, not a requirement to change your setup. If the existing records cannot hold an essential reporting detail, agree a place for that detail in your report or ask the administrator whether an existing field can serve the purpose.
Where your team uses an epic relationship, ask the administrator whether the search field is "Epic Link" or a different field in your configuration. Record the confirmed field in the reporting checklist rather than assuming a universal name.
Keep completion and acceptance separate. Use a completed work record as delivery evidence, then check the agreed acceptance condition before describing a milestone as signed off.
Ask the owner to confirm: “Does this work cover the whole acceptance condition, including client review?” Check for dependencies outside the delivery board, such as access, training or approval.
Keep agreed and forecast dates separate. The milestone table in ProjectManager.co’s status report template includes planned dates alongside actual or forecast dates. Follow that distinction so a changed forecast remains visible until a revised commitment is approved.
What should I collect before writing the report?
Collect evidence for completed outcomes, upcoming work, unresolved blockers and sponsor decisions using a consistent reporting period. Review milestone-related work even when nothing changed during that period. Ask owners to confirm forecasts and acceptance evidence, then separate internal delivery detail from information the client needs to act on.
Agree a reporting cutoff and record it in the report header. Ask work owners to update their records before you prepare the draft.
Use this message in your existing team channel:
Please confirm the forecast for [milestone], the evidence for [reported outcome], and any dependency that could affect [client commitment]. For each open action, include [owner], [needed-by date] and [effect if late]. Flag anything that still needs client acceptance.
Use these search specifications as a configuration checklist, then check the results against your team’s actual workflow and milestone mapping.
| Reporting view | Search criteria to configure | What the lead checks |
|---|---|---|
| Report scope | Work belonging to the client engagement | No unrelated client work appears |
| Progress | In-scope work completed or materially advanced during the reporting period | The outcome and evidence support the wording |
| Milestone readiness | All work supporting each upcoming milestone, including unchanged work | Remaining dependencies and acceptance conditions are visible |
| Risks and blockers | In-scope work identified by the team’s agreed risk or blocker convention | Each item has an impact, response and owner |
| Next actions | Open work supporting the upcoming client commitments | The owner confirms the next step and expected date |
| Decisions | Unresolved approvals or decisions in the team’s decision record | The person named has authority to answer |
Treat the list above as configuration requirements; use the sample JQL section below for queries to adapt and test against your workflow. Confirm how your team records completion, milestone membership and blockers before relying on the results.
Compare the candidate results with the last report. Carry unresolved items forward until they are closed or explicitly superseded. Investigate missing ownership or dates rather than silently dropping those items from the update.
Which sample JQL queries can I paste and test?
Use milestone, progress, risk and next-action searches to assemble the report’s working evidence. Replace every bracketed placeholder before running a query, and confirm field names and workflow values with your administrator. Check the results against known work items before saving a search or using the results in a client report.
Use these example queries as starting points; see the Atlassian JQL guide for syntax and operators.
Work supporting a milestone by version
project = "[project key]"
AND fixVersion = "[milestone version name]"
ORDER BY priority, updated
Check that the version grouping matches the client commitment. Include review and approval work in the milestone assessment even when those records sit elsewhere.
Work supporting a milestone by epic, where the field exists
project = "[project key]"
AND "Epic Link" = "[epic key]"
ORDER BY status
Use the epic query only after confirming the relationship field in your environment. If the field is unavailable, ask the administrator to substitute the supported relationship search rather than changing how the team organises delivery.
Open work updated during the reporting period
project = "[project key]"
AND updated >= "[period start date]"
AND updated < "[cutoff date]"
AND statusCategory != Done
ORDER BY updated DESC
Review these results for meaningful progress. Check completed outcomes separately against delivery and acceptance evidence; the open-work query deliberately excludes completed work.
Unresolved risks and blockers
project = "[project key]"
AND (
issuetype = "[risk issue type]"
OR labels = "[risk label]"
OR labels = "[blocker label]"
)
AND statusCategory != Done
ORDER BY priority DESC
Keep only the clauses that match your team’s existing conventions. Ask owners about unrecorded dependencies as part of the review.
Assigned next actions within the agreed planning window
project = "[project key]"
AND assignee IS NOT EMPTY
AND statusCategory != Done
AND due >= "[window start date]"
AND due <= "[window end date]"
ORDER BY due ASC
Check overdue and undated actions separately so the planning window does not hide them. Confirm that each selected action supports an upcoming client commitment.
Adjust date ranges and field names to match your workflow. Use the Atlassian JQL guide as the syntax reference, and test the final queries in your own configuration before reuse.
How should I decide whether a milestone is red, amber or green?
Assign RAG status by judging whether the client commitment remains achievable, using the forecast, dependencies and acceptance evidence. Agree the meaning of each colour with the sponsor before reporting. Explain the reason beside every status, and distinguish a possible future risk from a blocker that is already affecting delivery.
Use the following as a proposed reporting policy to agree with the client, not as a universal scoring standard:
| Status | Proposed rule | What to write beside it |
|---|---|---|
| Green | The commitment remains achievable, and required dependencies and acceptance steps are accounted for | Evidence supporting the forecast and the next checkpoint |
| Amber | The commitment is threatened, but a credible recovery action could protect it | Threat, recovery action, owner and decision needed |
| Red | The commitment is no longer achievable under the approved plan, or recovery needs a sponsor decision | Impact, available options and the decision required |
Review the evidence with the milestone owner. Ask: “What must happen for this forecast to remain credible?” If the answer depends on an unconfirmed client response, make that dependency visible in the status reason.
Where evidence is missing, write “Assessment pending,” name the missing information and assign someone to confirm it. Keep that label distinct from RAG until the assessment is complete.
For the overall project status, assess the effect on the client commitment rather than averaging milestone colours. Escalate a threatened critical milestone even when unrelated work is progressing well.
Keep risk assessment separate from milestone health. Describe a risk’s likelihood and impact in words, then explain whether the risk changes the milestone’s RAG status. For a blocker, state the current effect and the action needed to resume progress.
Which concrete filters should support the RAG assessment?
Use overdue and upcoming-due searches to flag work for a RAG review, then check the effect on the client commitment. Agree a review horizon with the sponsor and use that date in the queries. Confirm acceptance evidence separately; an empty overdue list is a check, not proof of green status.
Proposed red review rule: Review a milestone for red when its forecast exceeds the agreed date, or overdue critical supporting work makes the commitment unachievable. Compare milestone dates in the report; use the following search to identify overdue supporting work for inspection.
The query examples use the Atlassian JQL guide as their syntax reference; replace the placeholders and validate the results locally.
project = "[project key]"
AND fixVersion = "[milestone version name]"
AND statusCategory != Done
AND due < "[assessment date]"
ORDER BY due ASC
Ask the owner which returned items affect the client commitment. Record the impact, recovery options and decision needed. Keep the approved date separate from the forecast, following the date distinction in ProjectManager.co’s milestone table.
Proposed amber review rule: Review a milestone for amber when required work remains incomplete inside the agreed review horizon and threatens the commitment.
project = "[project key]"
AND fixVersion = "[milestone version name]"
AND statusCategory != Done
AND due >= "[assessment date]"
AND due <= "[review horizon date]"
ORDER BY due ASC
Agree the review horizon around the time needed for client feedback, recovery and approval. Ask: “What action protects the commitment, who owns that action, and when must the sponsor respond?”
Proposed green check: Confirm that the forecast remains achievable, relevant overdue work has been addressed, and evidence supports the reported delivery and acceptance state. Inspect undated incomplete work before concluding the review.
project = "[project key]"
AND fixVersion = "[milestone version name]"
AND statusCategory != Done
AND due IS EMPTY
ORDER BY priority DESC
Ask owners to clarify the timing of relevant undated work. Keep green as a reviewed assessment rather than a default colour assigned to everything outside the other filters.
What client-friendly weekly status report template can I use?
Use a stable report format that starts with the overall position and the response needed from the client. Follow with milestones, evidenced progress, risks and next actions. Keep internal task detail in your working notes, and include enough explanation for the sponsor to understand the report without opening the delivery board.
Report outcomes rather than activities, and record decisions with an owner, deadline and effect if late, following Superthread’s client-report guide.
Copyable client report
Subject: [client engagement] weekly status report: [reporting period]
Prepared by: [delivery lead]
Information current as of: [cutoff date]
Overall status: [RAG status]
Reason: [Effect on the client commitment, supporting evidence and what changed]
Client response needed
Please [approve, review or decide] [specific item] by [needed-by date]. We recommend [option] because [reason]. Without a response, [effect on milestone or next step].
Milestones
| Milestone and acceptance condition | Agreed date | Forecast or actual date | RAG and reason | Evidence or acceptance state |
|---|---|---|---|---|
| [Milestone and acceptance condition] | [Agreed date] | [Forecast or actual date] | [Status and reason] | [Evidence reference and acceptance state] |
Progress since the previous report
- [Client-facing outcome]. Evidence: [evidence reference]. Acceptance: [acceptance state].
- [Material change or decision]. Effect: [what changes for the client].
Risks and blockers
| Risk or blocker | Effect on client commitment | Response | Owner | Needed by |
|---|---|---|---|---|
| [Risk or current blocker] | [Affected milestone and consequence] | [Mitigation or recovery action] | [Owner] | [Needed-by date] |
Next actions
| Action or deliverable | Owner | Needed by | Completion evidence |
|---|---|---|---|
| [Specific next action] | [Owner] | [Needed-by date] | [Evidence or acceptance condition] |
Decisions and changes recorded
[Decision], confirmed by [decision owner] on [date]. Effect on the approved plan: [effect]. Next step: [action and owner].
If no client response is needed, say so explicitly. If acceptance is pending, preserve that wording rather than describing the milestone as signed off.
How do I turn technical updates into clear client actions?
Translate each technical update into an outcome, its effect on the client and the next step. Give requests a named decision owner, a deadline and a consequence. Separate work the delivery team owns from approvals the client owns, so the sponsor can see exactly where a response is needed.
Use these wording patterns when editing the draft:
| Instead of an activity-only update | Write a client-facing update |
|---|---|
| [Technical task] completed | [Deliverable] is ready for [client review or use]. Evidence: [reference]. Acceptance remains [state]. |
| Waiting on [client team] | [Decision owner] to approve [item] by [date] so [dependent action] can proceed. |
| [Issue] is being investigated | [Owner] is checking [problem]. The possible effect is [client impact]. The next update will confirm [finding or decision]. |
| Working on [deliverable] | [Owner] will prepare [reviewable outcome] by [date], subject to [dependency]. |
Before sending a request, confirm that the named person can make the decision. Include your recommendation and the relevant trade-off rather than asking the client to reconstruct the options.
When the sponsor answers, record the response and change the affected next action. In the following report, explain what the decision enabled or changed.
What should I automate, and what should I review myself?
Automate repeatable collection and draft preparation where your existing tools support them, but keep forecast judgment, RAG assessment and client wording under delivery-lead review. Start with a repeatable manual report. Configure automation only after the team agrees on milestone mapping, source records, reporting boundaries and the approval step before sending.
Use the checklist below with whoever manages your existing reporting tools. Treat subscription, export and scheduling steps as options to confirm in your environment, not promised capabilities.
- Prepare the searches. Replace the placeholders in the sample queries. Run each query and inspect the results against the agreed milestone scope. Use the Atlassian JQL guide to check syntax before saving the configuration.
- Save or record the searches. Where saved filters are available, use names such as
REPORT: [engagement] [milestone] progress,REPORT: [engagement] risksandREPORT: [engagement] next actions. Otherwise, keep the query text in the internal reporting checklist. Record the owner and purpose alongside each search. - Set the preparation trigger. In your existing scheduling or reminder settings, arrange preparation after the reporting cutoff. Ask the administrator whether an internal subscription can deliver the results. If unavailable, assign the delivery lead a recurring reminder to run the searches.
- Move results into the draft. Use an available export option, or copy the relevant results into your working notes. Populate the client template with outcomes, not the full task list. Preserve references for checking and carry unresolved items forward.
- Route the draft for review. Keep the recipient internal. Ask the delivery lead to confirm the milestone forecast, acceptance evidence, RAG reason and client request. Mark missing evidence or ownership as unconfirmed.
- Release after approval. Send through the agreed client channel once the delivery lead approves the wording. Include only evidence the recipient is authorised to inspect, and retain the sent version with its reporting period.
Do not auto-send the client report without the delivery lead’s approval; Superthread’s guide describes AI preparing a draft while a person reviews the message, adds judgment and owns what goes to the client.
If you use an approved drafting assistant, provide only information permitted for that environment and use this instruction:
Draft the client status report using only [approved source material] and [report template]. Preserve agreed dates, forecasts and acceptance states separately. Flag missing evidence, conflicting dates and unassigned actions. Leave RAG judgment to [delivery lead]. Use [client terminology]. Return a draft for review.
Check the output against the source records. Do not assume that a fluent summary establishes acceptance or resolves conflicting forecasts.
What should I check before sending the report?
Check that the report describes the current client commitment, supports its status with evidence and makes every requested response actionable. Compare the draft with the previous update, confirm access to shared evidence and remove unrelated internal information. Use the sponsor meeting for unresolved decisions rather than reading the report aloud.
Work through these checks with the milestone owners:
- Commitment: Are agreed and forecast dates still distinct? Is any approved change recorded?
- Evidence: Does each completed outcome have support? Is sponsor sign-off explicit where required?
- Status: Does every amber or red assessment explain the impact and response?
- Ownership: Does each next action name someone who has accepted responsibility?
- Decision: Can the sponsor answer the request without another explanation?
- Access: Can the intended recipient inspect shared evidence without seeing unrelated client or internal material?
- Continuity: Are previously open risks and decisions closed, carried forward or explicitly replaced?
Open the sponsor discussion with: “The decision needed is [decision]. Our recommendation is [option]. The effect on [milestone] is [impact].” Record the answer, confirm who acts next and update the affected work.
For the next reporting cycle, reuse the milestone mapping, agreed RAG policy and report structure. Improve any source record that forced you to chase clarification, so the next update starts from better evidence.
Which sources should I use to check the reporting approach?
Check search syntax against the Atlassian JQL guide, milestone date presentation against ProjectManager.co, and outcome wording against Superthread. Use those references for their stated purpose. Confirm local fields, permissions and reporting settings with your administrator, and agree acceptance conditions and status definitions with the sponsor before reusing the report.
- Atlassian JQL guide: reference for constructing work searches.
- ProjectManager.co weekly status report template: planned and forecast milestone dates.
- Superthread weekly client status report guide: outcome wording, decision ownership and human review of drafts.