Publish an update project-wide when content and action are identical for everyone; target individual files as soon as context, planning or consequences differ. One generic message with exceptions in the text is not efficient segmentation.
Updates give a customer journey rhythm. They become unreliable when customers repeatedly need to determine whether a paragraph applies to them. Start with reach, then title and content.
Choose reach using three questions
Does the same factual change apply to every file? Is the intended action identical for everyone? May every customer see all the information mentioned? Project-wide publication makes sense only when all three answers are yes.
Yindle Portal supports updates for an entire project or one file. Both types appear together in the personal overview when relevant. Intermediate groups may need several targeted publications or additional segmentation logic.
Write the title as a change
“October newsletter” does little. “Intake appointments moved back one week” explains what is new. Start with the effect on the customer, then the reason and details. If action is needed, put it in a separate sentence with a date.
Use tags and colour only as additional orientation. “Planning”, “Document” and “Action” can help, but the title must remain understandable without colour.
Worked example: fictional maintenance campaign
In this fictional example, service company Daklijn inspects one hundred properties. A changed phone number applies to every customer. Rain postpones the inspection of property K-18; that is a file-specific update. The access route changes for twelve properties in one street. Because the current setup publishes only project-wide or per file, the team creates targeted messages per file or chooses an appropriate extension.
Customer Mara sees general and personal updates together chronologically, without information about other addresses. This fictional example also shows an honest product boundary: an audience between project and individual file requires a deliberate solution.
Use the publication card
| Field | Decision |
|---|---|
| Reach | Project, group or file |
| Core | What has changed for this recipient? |
| Action | What, if anything, must the customer do? |
| Date | When does this apply and what is the deadline? |
| Attachment/media | Does it genuinely support the message? |
| Owner | Who answers questions and corrects errors? |
When correcting an update, do not make the original disappear without a trace. Publish a short correction and refer to the current information. Decide internally how editorial errors are recorded.
Measure understanding and follow-up
A reading record may show that an update was opened, not understood. Also examine the intended follow-up action and recurring questions. Many identical questions indicate missing context, even with a high reading rate.
Check how title, tag, media and action order work on mobile. Test a customer with two files: the update must clearly identify the intended file.
Plan sensitive or time-critical updates with a second reader. Check audience, names, dates, links and attachments. A spelling error is inconvenient; the wrong reach may reveal information about another file. Make audience checks a separate item, not just part of text editing.
Prevent project-wide updates from becoming an unstructured chronological archive. Use recognisable tags, but also provide a topic filter and mark which information remains current. An old plan must not stay above a corrected plan without a reference.
For a partial group, a file action may sometimes suit better than an update. If twelve customers each need to give the same confirmation, every customer needs an individual task status. A general announcement does not tell the team who responded.
Create a publication calendar to avoid peaks. Three teams may each send a relevant message, giving the customer three emails in one morning. Combine content that can wait and reserve direct contact for blockers or personal changes.
Also test a withdrawn update in advance. Decide whether customers receive a correction, which version remains archived and how employees see that they must no longer refer to the old instructions.
Explore communication within Yindle Portal and read about the broader customer process it fits into. To agree audience selection and editing, work through three real updates with Yindle.