The Routine Change Inventory: What Marketing Should Track Every Month 

The next useful content-operations improvement may already be hiding in last month’s request list. 

Offer changes, location details, campaign variants, action labels, and product information can be returned repeatedly. Each request looks minor on its own. Together they reveal where the team keeps paying for the same work. 

A routine change of inventory turns those requests into evidence. It does not need to become another system to maintain. 

Start with the requests you already have 

Review a recent period using the records available: task lists, content calendars, agency requests, or website-update logs. Capture the recurring categories rather than every message. 

For each category, note what changes, how often it changes, who requests it, who completes it, and who approves it. Record the page or content record affected and the action the customer should be able to take afterwards. 

Do not infer frequency from the loudest complaint. A memorable emergency may be less important than a quiet task that repeats every week. 

Separate facts, structure and functionality 

A product description update is different from a new page layout. A new layout is different from a new form of connection. Mixing them together makes website content updates look either simpler or more technical than they really are. 

Use plain categories: approved fact changes, campaign copy, existing template variant, new structure or new functionality. Add a category for corrections if errors create repeated work. 

This distinction helps identify the right intervention. Shared facts may need structured records. Repeated layout work may need a better template. New functionality may still require technical delivery. 

Record the work around the edit 

Do not stop at the person who types the change. Include the work needed to find the correct information, request approval, identify affected pages, and verify the live result. 

The inventory should show active effort and the main waiting reason where available. Keep uncertain estimates labeled. A rough frequency with a clear evidence source is more useful than a precise number invented after the event. 

Also note whether the change required a developer, agency or other specialist. This is about understanding dependency, not blaming the people providing support. 

Choose candidates for reuse 

Look for tasks that repeat, use stable structures, and have clear acceptance conditions. An approved offer-field update across known pages may be a good candidate. A new customer journey with different data requirements may not be. 

Ask what could be reused: the fact, the component, the review rule, the page structure, or the verification checklist. Reuse is more specific than duplicating an old page and hoping its assumptions still apply. 

Keep exceptions visible. If every supposedly routine update needs a different structure, the category may be too broad to standardise. 

Put ownership beside the opportunity 

A list without an owner becomes another observation. For each candidate, identify who can approve a change to the process and who will perform the next task. 

Clearer instructions, reusable copy and an agreed definition of done give each team a practical starting point. Assign the proposed improvement to an accountable owner. At the next review, compare the actual repeat task rather than simply checking whether a new process was documented. 

Review what changed, not how large the list became 

At the next review, ask whether the selected task required less repeated effort, less help or fewer corrections. Note whether another team inherited additional work. Keep the scope comparable. 

Remove categories that are no longer useful. Add new ones only when they reveal a decision. The inventory is a tool for choosing work, not a permanent catalogue of everything marketing has ever requested. 

A practical first output is one sentence: ‘This task repeats often, uses an approved structure and still needs unnecessary reconstruction.’ That is a strong starting point for a template improvement, a process change or a scoped Experience Suite test. It is much stronger than deciding that every website request needs a new platform.