What actually gets a non-technical client to read your project update?

[Andrey - Guenov Labs]

I'll be upfront at the start: I build in this space, so I have a bias — and that's exactly why I want to hear from people who do this daily before I trust my own conclusions.

The problem I keep circling: how do you keep a client genuinely informed about a Jira project when they don't have Jira access and never will — a marketing director or a business owner, not a PM? Technically informed is easy. Actually informed, in a way they read and trust, is the hard part, and I'd like to know what's worked for people in practice.

The patterns I most often see recommended are a weekly written summary (verdict first, then a few plain-language bullets, no ticket keys or story points), a shared Confluence page, or exporting a report. Each seems to break down somewhere:

• A written update is a snapshot, not a state — stale by mid-week, and if the client wonders on Wednesday they email instead of checking anywhere.
• Rewriting Jira into plain English by hand doesn't scale past a couple of projects.
• It's hard to tell if it even landed. No reply usually means "fine," occasionally it means "didn't read it, quietly unhappy."

So for people doing this regularly:

1. What format did you land on, and what did you have to remove before people actually engaged with it?
2. Does anyone push status somewhere the client can check on their own — a page, a dashboard — rather than emailing it? Does it actually get looked at, or does the email still do the work?
3. Has anyone shortened the translate-Jira-into-plain-English step without the result sounding automated? My worry is that the moment an update reads like a machine wrote it, people stop trusting it — curious whether others have found that, or solved it.

Genuinely open to the answer being "it's just a manual writing job." That's a common conclusion, but I'd rather be shown a better one.

[Lisa Ness]

What I've settled on for now is a weekly Rovo summary with manual tweaks to remove some of the AI junk and make it sound a little more personal.  The way that development teams need to organize their work doesn't necessarily align with the way a customer is envisioning things, so there's always going to be a level of disconnect when trying to export status updates directly from your work management system. A project management forum might have some more creative suggestions on how to solve this problem.  This is something they deal with on a daily basis.

[Marc -Devoteam-]

Hi @Andrey - Guenov Labs 

You could use the JIra Guest option, see manage-guest-access-in-jira .

This option is only available on paid plans.

[Martin Runge]

This would have been my first answer.

[Martin Runge]

Hi @Andrey - Guenov Labs,

A few things that have worked for me:

• Report at the epic or outcome level, never at the ticket level.
• Give each outcome a plain status, such as on track, at risk, or done.
• Add one human sentence only on the at-risk ones.

Regarding the stale snapshot problem, I would make the page live rather than write it from scratch each week. A Confluence page with a Jira roadmap or timeline macro and a status-by-epic view updates itself as the team moves work. The weekly email then stops being content and becomes a two-line nudge pointing to the page. 

To know whether it landed, I included one small decision or open question for the client in every update. A scope choice, a date to confirm, anything. If they answer, they read it. Silence on a direct question tells you far more than silence on a paragraph.

What does your client actually act on when they read an update? If it is dates, I would build the whole thing around a small milestone view. If it is risk, I would lead with the at-risk line and drop nearly everything else.

Cheers, Martin