An influencer gifting tracker should separate approved, promised, packed, shipped and delivered milestones. Add an exception field alongside them, plus a final outcome for cancelled or returned shipments. This lets you see both where a parcel reached and what needs attention. A printed label should never be enough to mark a gift shipped.
Use the schema below in a spreadsheet or your existing operations system. These are recommended internal definitions, not universal carrier status names.
Define the evidence for each state
A state change needs an event, a timestamp and a source. Otherwise, two people can use "sent" to mean different things.
| Milestone | Evidence required | What remains unproven |
|---|---|---|
| Approved | Named brand approver authorizes the product and quantity | The creator has accepted it |
| Promised | Creator accepts the gift and the agreed items are recorded | The parcel exists |
| Packed | Warehouse confirms the parcel contents against the agreed items | A carrier has received it |
| Shipped | Carrier acceptance or documented handover | Delivery to the recipient |
| Delivered | Carrier records final-destination delivery and its timestamp | The creator has personally received and checked the contents |
Keep label creation as its own event. UPS explains that "Label Created" means it has received shipment and billing details. Possession and movement through its network come later. This supports a firm tracker rule: a tracking number alone cannot advance a parcel to shipped.
Do not infer packed from label creation either. A warehouse may print labels before it finishes packing. Ask for a packing confirmation tied to the parcel record.
Record out-for-delivery in the carrier-status field while the milestone stays shipped. For a pickup location, keep a separate awaiting-pickup flag. UPS distinguishes final delivery from delivery to an Access Point, where the parcel awaits collection. Your tracker should preserve that distinction.
Use three fields instead of one crowded dropdown
Put these fields beside each other:
- Milestone. The latest evidenced step in the table above.
- Exception. The current issue, or none, with an opened date and owner.
- Outcome. Open, completed, cancelled or returned.
An exception must not erase the last confirmed milestone. A creator who reports a missing parcel after a delivery scan should appear as delivered, with a receipt-disputed exception and an open outcome. Retain the scan and the creator's report as separate evidence.
UPS uses exception for an unexpected issue in its network that may change the delivery date. Your internal exception field can also cover pre-shipment problems, such as an unavailable item. Label the source as internal, carrier or creator so readers can tell the difference.
Use specific reasons: packing discrepancy, awaiting handover confirmation, carrier delay, awaiting pickup, receipt disputed or damage reported. Avoid a single "problem" label with no next action. A lack of recent scans alone should not become a confirmed-loss outcome.
Tracker schema
Start a record when the gift receives internal approval. Assign a stable gift ID, then a parcel ID when fulfillment plans the package. Keep the same parcel ID through packing and transit.
| Field group | Fields to keep | Purpose |
|---|---|---|
| Identity | Gift ID, parcel ID, creator ID, campaign ID | Find the correct gift without relying on a display name |
| Approved contents | SKU, variant, quantity, approval reference | Define what the warehouse should pack |
| Acceptance | Gift acceptance date, agreed-item reference | Separate approval from the promise to the creator |
| Shipping readiness | Address-record reference, confirmation date, ready or hold | Show whether fulfillment can proceed |
| Milestones | Current milestone; approved, promised, packed, shipped and delivered timestamps | Preserve the history after the status changes |
| Carrier evidence | Carrier, tracking reference, raw status, event time, last checked time | Keep the source alongside your interpretation |
| Exceptions | Reason, source, opened time, owner, next action, review date | Make unresolved work assignable |
| Closure | Receipt confirmation if available, outcome, closure date, resolution note | Explain why the record no longer needs action |
Use one documented time zone for internal review dates. Preserve the carrier's event time and time zone where supplied. "Last checked" records when your team looked; it must not replace the event time.
Keep shipping addresses in a restricted fulfillment record and use its reference in the general tracker. That is a recommended access design. In the UK GDPR context, ICO guidance requires data to be relevant and limited to the stated purpose. It also recommends reviewing held data and deleting what is no longer needed. The ICO marks this guidance as under review following legislative changes.
For the collection form and retention decisions, use the separate guide to collecting creator shipping details with explicit consent. This schema does not establish a lawful basis or permission for future marketing.
Ten hypothetical shipment records
The records below are illustrative. IDs, events and assignments are invented to demonstrate the schema. Every row belongs to a separate gift; none represents a real creator or carrier incident.
| Parcel | Item | Milestone | Exception | Outcome | Owner and next action |
|---|---|---|---|---|---|
| G01-P1 | Tote, 1 | Approved | None | Open | Creator manager: record acceptance before packing |
| G02-P1 | Notebook, 1 | Promised | Address unconfirmed | Open | Creator manager: confirm shipping details |
| G03-P1 | Cap, 1 | Promised | Item unavailable | Open | Creator manager: ask about an alternative |
| G04-P1 | Tote, 1 | Packed | None | Open | Warehouse: hand over; label already created |
| G05-P1 | Notebook, 2 | Packed | Handover unconfirmed | Open | Warehouse: find acceptance evidence |
| G06-P1 | Cap, 1 | Shipped | None | Open | Operations: review on recorded delivery estimate |
| G07-P1 | Tote, 1 | Shipped | Awaiting pickup | Open | Operations: check collection status |
| G08-P1 | Notebook, 1 | Delivered | None | Completed | Operations: file delivery evidence; receipt also confirmed |
| G09-P1 | Cap, 1 | Delivered | Receipt disputed | Open | Operations: investigate the delivery record |
| G10-P1 | Tote, 1 | Shipped | None; return resolved | Returned | Operations: retain return-receipt evidence |
G04 and G05 are both packed. Only G05 has an unresolved handover question. Neither belongs in a shipped count without evidence of transfer to the carrier.
G08 and G09 both have delivery scans. Only G08 has completed this example's closure process. The disputed record stays visible to the person responsible for resolving it.
If a gift needs multiple parcels or a replacement, retain separate parcel IDs under the gift ID. Do not overwrite an original tracking number. For matching those records to warehouse exports, use the seeding and warehouse reconciliation guide.
Review the action queue before the totals
At each review, filter for open records whose review date has arrived, then inspect exceptions. Require an owner and a concrete next action for every unresolved issue. Use carrier information and your fulfillment plan to set the next review date; do not impose one universal lost-package deadline.
Check for impossible or unsupported transitions: delivered without evidence, shipped with only a label, or completed while a receipt dispute remains open. When evidence arrives late, record its actual event date rather than inventing intermediate timestamps.
Keep content activity in a separate record. Modash's gifting-platform guide covers both fulfillment and tracking creator posts, but those tasks need different evidence. A delivery scan should never set a "posted" field or create a posting obligation. For the next creator conversation, use a delivery follow-up that offers support without demanding a post.
Before the next batch leaves, review every row currently marked "sent." Reclassify it from its evidence, then assign an owner and review date wherever the handover or delivery remains unresolved.
