Update content when the document structure still works and the source is maintainable. Repair the template when recurring layout problems make changes difficult. Consider restructuring and redesign when the audience or business has changed enough that the current document no longer answers the right questions. Age alone is not a reason to replace everything.
Start with the version people actually send to customers, not the file everyone assumes is current. Collect its editable source and available assets, then ask sales and operations which passages they avoid sharing or have to correct verbally.
Classify the problem before buying a solution
| Finding | Likely workstream | Check before committing |
|---|---|---|
| Old contacts or service information | Targeted content update | Every occurrence and both languages |
| Inconsistent spacing or difficult page editing | Template repair | Whether a new update fits reliably |
| Different audience, services and confusing sequence | Restructure and possibly redesign | Reader needs, evidence and page organisation |
| Flattened document without a usable source | Recovery or defined rebuild | Re-entry work and asset rights |
A project may combine workstreams. Changed services do not require replacing every photograph, while repairing the template does not establish that the wording is accurate. Ask the supplier to identify what will remain, what will change and why. This makes quotations comparable.
Build a change register
For each item, record its location, existing content, requested change, source, approver and affected outputs. Replacing a telephone number and rewriting a service section are different tasks. Identify items awaiting information rather than expecting the designer to estimate their substance.
A company profile refresh becomes easier to scope around this register. If staff describe services inconsistently, resolve the reference content through content strategy and production before reproducing those contradictions in a cleaner layout.
Maintain a “retain” list as well. It protects useful existing material from unnecessary change and keeps the project focused on what affects the buyer's understanding. A new colour preference should not automatically reopen an approved content structure.
Worked hypothetical: a contractor with a bounded update
Imagine a contractor with a twenty-page profile. It has discontinued two services, completed three projects suitable for approved descriptions and changed its contact owner. These are illustrative quantities, not LAB client results or market benchmarks.
Inspection shows that the main structure is clear, but project cards are manually formatted. The English version still includes the discontinued services. The team scopes removal of those services in both languages, three updated project cards, a reusable card layout and contact changes throughout the file. Unaffected pages do not need to be redrawn simply to expand the engagement.
After the first card is repaired, the internal owner adds a test card. A long title reveals a layout weakness, which is fixed before the pattern is reused. The team then produces two digital releases and marks the previous release as superseded. The acceptance outcome is a maintainable, accurate document, not an unmeasured sales-performance claim.
Test source health
Open the source in the environment your internal editor will use. Check missing assets, available fonts and permitted usage. Determine whether tables are real text or images. Add a representative service or project and observe what happens to following pages. Changing one word on the cover is not a meaningful maintenance test.
A reusable document template is not, by itself, a product design system. If inconsistency also affects website or application interfaces, a separate design systems scope may be appropriate. Define digital components, ownership and implementation alignment separately rather than asking a company-profile update to solve an entire product's interface problems.
Keep the new release current
Assign an owner to the reference and establish who reports service, project and team changes. Use clear review triggers: a service launch or withdrawal, an expired fact, a new approved project or a changed contact route. A periodic review may also help, but its frequency should reflect how the business changes rather than a universal schedule.
At release, keep one approved location, update sharing links you control and tell internal users which attachments to retire. You cannot guarantee removal of copies already downloaded by customers. A visible release date and a clear route to obtain the current version help readers recognise that limitation.
Keep the archive separate from the distribution folder. Old documents can be useful for traceability without appearing to be current options. Do not delete the record of earlier claims merely to make the folder look tidy; agree retention and access with the organisation's responsible owner.
Acceptance checklist
- Each requested change is closed with the appropriate factual approval.
- Discontinued services are removed from text, tables and both languages.
- A realistic source edit has been tested through export.
- New content has not broken pagination, links or reading order.
- The current release, archive and next update owner are identified.
- Out-of-scope material remains unchanged unless a specific change was agreed.
- Sales and other users know where to obtain the approved version.
Common mistakes include paying for a new cover while inaccurate claims remain, modifying only one language, and accepting a source that nobody internally can maintain. Another is treating every late suggestion as a correction. Distinguish factual fixes from new requirements and record their effect on scope.
Frequently asked questions
Does a missing editable source mean a complete redesign?
Not necessarily, but it may require content recovery or template reconstruction. Inspect the available assets and price that work separately from visual improvement.
Should the identity change during every refresh?
No. The identity may remain appropriate while facts change. Reconsidering the identity requires a broader problem than old figures or projects in one document.
How do we avoid unlimited revision rounds?
Agree the change register and final approver, then distinguish corrections from new material. A new request should identify its effect on pages, languages and delivery rather than entering an untracked comment stream.
What should we send LAB?
Provide the circulating version, editable source and known changes. Those inputs support a proportionate choice between targeted updating, template repair and a justified rebuild.
