Last year we wrote about getting supplier packaging data right: what to ask for, and the errors that come back. This post is about the other half of the problem. Even with the right form, collection stalls, because the request itself is usually an email and a spreadsheet of who has replied.

The pressure on that process has gone up. EU PPWR has applied since 12 August, and a Declaration of Conformity is only as complete as the component data under it. UK EPR is in its second year, with fees that now depend on recyclability. Both need data from the businesses that make and supply your packaging, and both need it to stay current.

A supplier declaration request: one task per supplier, a due date and a closing date, and progress anyone can read.

Why the chase stalls

Ask a compliance team how a data collection round is going and the answer is usually an estimate. The tracker is a spreadsheet kept by one person, updated when they get to it. A few patterns account for most of the delay:

  • Nobody owns the reply. The email went to a general address, or to a contact who has moved on, so everyone at the supplier assumes someone else is dealing with it
  • "Done" is a judgement. A supplier sends back a file and the request is ticked off, whether or not every component is complete
  • Reminders depend on memory. Follow-ups go out when someone remembers, so the suppliers who need chasing most are chased least
  • Deadlines have no consequence. A date that passes without anything happening teaches suppliers that the next date is optional too
  • Nothing is fixed at the end. The data can change after it was "collected", and there is no record of what the supplier stood behind on a given day

Vendors and suppliers are different asks

Retailers and brands often deal with two kinds of business. A vendor supplies finished products and knows the SKUs, their bills of materials and which businesses made the packaging. A supplier makes the packaging components and knows the material, weight, recycled content and the evidence behind them.

Treating them as one list leads to the wrong question going to the wrong business. The vendor should be asked to confirm its SKUs and components are complete, and it is often best placed to say which of its suppliers are holding that up. The supplier should be asked about its own components and nothing else. A good process lets the vendor request lead into the supplier requests it depends on, rather than running as two separate exercises.

What a request needs

Whatever tool you use, a request that finishes has a few things in common:

  • A defined scope. Which suppliers or vendors, and which of their components or SKUs, decided when the request starts
  • One task per business, with an owner. Shared by everyone at that supplier or vendor, and claimed by one person so two people do not work it twice
  • A finish line set by the data. The task is complete when the supplier or vendor signs a declaration after the request started, not when someone decides it looks done
  • Dates that mean something. A due date, a grace period after it, and a closing date after which the task closes as not completed
  • Reminders on a schedule. Before the due date, on it and on the closing date, sent to whoever has claimed the task or to the whole group if nobody has
  • Progress anyone can read. How many of the businesses asked have finished, which tasks are overdue and which have closed

A signature as the finish line

The point of a request is not a returned spreadsheet but a record that a named person at the supplier confirmed their data on a date. A signed declaration does that: it fixes a snapshot of the components it covers, with the name, email and job title of the signer and the time they signed. If the data changes later, the declaration still shows what was confirmed.

Two options make the dates firmer, and both are trade-offs. Allowing suppliers to sign only while a request is open stops declarations arriving at random through the year, but means a late supplier has to be asked again. Locking supplier data a set number of days after a request closes stops quiet edits to data that has already been declared, but means a genuine correction has to come through you. Organisations with a fixed reporting cycle tend to want both. Those still building their data tend to want neither yet.

Evidence, not just answers

A recycled content figure or an FSC claim is only as good as the document behind it, and supplier documents need checking before they count. If they are reviewed, a rejection should go back to the supplier as a task to upload a corrected version, with the reason, rather than as an email that starts another chase.

Some organisations go a step further and count only approved documents towards completeness and declarations. That makes the numbers more defensible, but expect completeness to drop when it is switched on, because documents that were counted before are now waiting for review. Plan the review capacity before you make the switch.

Measuring engagement

The most useful report on a supplier programme is not the percentage of data collected but where suppliers have stopped. A simple funnel answers it: not yet invited, invited, active in the portal, engaged with their data, complete, and declared. Each stage has a different fix. Suppliers who were invited but never signed in need a different contact. Suppliers who are complete but have not declared need a request with a date.

How Merchant Packaging supports this

Merchant Packaging has fixed, built-in workflows that an Admin switches on and configures for the organisation. The supplier declaration request creates one shared task per supplier, completed when the supplier signs a declaration after the request started. The vendor data request creates one task per vendor, with a checklist of whether its SKUs and components are complete and whether it can sign, and supplier requests can be started from it, limited to that vendor's suppliers and preselecting those with incomplete components. Both offer declaration windows and data locks after close, and show request progress with an export.

Tasks carry a red, amber or green status from their due date, grace period and closing date, can be claimed and released, and chase themselves: reminders go out on the schedule you set, and daily sweeps complete, close and nudge without anyone keeping a tracker. My Tasks brings everyone's work into one list, with bulk claim, release, approve and reject across up to 200 tasks at a time. Supplier evidence approval can read every document a supplier uploads, including scanned PDFs, check it against what the record claims, and approve it automatically when it passes, leaving your team to review only the exceptions. A rejection gives the supplier a task to upload a corrected version, and an organisation setting counts only approved documents. The supplier engagement dashboard shows the funnel from not invited to declared, with filters and a CSV export. Each workflow instance can have its own message thread, and every task action is kept in its history and the audit log.