Wine Brand Asset Management for Importer Operations Teams

Govern wine brand assets through their full lifecycle

This guide is for alcohol importer operations teams responsible for bottle images, logos, technical sheets, sell sheets, presentations, producer stories, maps, photography, and other wine brand materials. It focuses on lifecycle governance: where an asset comes from, what it represents, who owns it, how it becomes approved, where it may be released, when it must be reviewed, and how it is retired.

This is different from arranging a shared drive. A clean folder can still contain an unapproved label image, a tasting note for the wrong vintage, or two files that both appear current. For tactical folder, metadata, and filename guidance, use the guide to organizing wine brand assets for distributors. The operating model here controls the decisions around those files.

Define what the asset system governs

An asset is more than a file. It is a controlled record that includes the file, the product relationships it describes, its source, its lifecycle state, its permitted audience, and its history.

Start with an asset register. Each governed asset should have:

a stable asset identifier
an asset type
a source file or source location
a named owner
linked producer, wine, vintage or release, and market item
approval and publication state
revision identity
intended audience and channel
rights or use conditions where applicable
predecessor and successor relationships
review and retirement triggers

The register is the source of truth for asset status and relationships. It does not have to be the source of every product fact represented inside a file. Product name, vintage, alcohol content, pack, and importer SKU may be governed in a product record. Producer photography may originate with the winery. Approval evidence may come from a qualified reviewer. The asset record should point to those authorities rather than duplicate them without attribution.

Do not make a PDF the only known source for a product value. When a colleague must open last year’s sell sheet to recover the current alcohol content, the output has become an unofficial product database. Keep structured product details under their assigned authority and treat the PDF as a published expression of an approved revision.

Establish one controlled intake path

Assets often enter an importer through email, file-transfer links, supplier portals, messaging apps, and agency handoffs. Do not let arrival location determine approval or currentness.

Route new material through one intake process. At intake, capture who provided it, when it arrived, which producer and product it concerns, what the sender says it may be used for, and whether a prior asset is expected to be replaced. Preserve the original source file before resizing, retouching, translating, or placing it into a template.

Keep source, working, and released forms distinct:

Source: The file received from its originator, preserved with its provenance.
Working revision: An edited, translated, resized, or composed version under review.
Released revision: The exact approved file made available to a defined audience.

A source file is not automatically approved. An approved file is not automatically current for every market. A released file should never change in place. If the content changes, create another revision and route it through the required review.

Use approval states with precise meanings

Lifecycle states should describe decisions, not locations. Define the allowed transition into and out of each state.

A practical state model is:

Received: Captured with source provenance but not yet assessed.
In preparation: Being edited, mapped, translated, or completed.
In review: Submitted as an exact revision to named reviewers.
Approved: Cleared for a defined product, market, audience, and use.
Current: The approved revision intended for active distribution in that context.
Superseded: Replaced by a named successor and removed from current distribution.
Retired: No longer approved for routine use because the product, market, rights, or business need ended.
Rejected: Assessed and not accepted for release.

Approved and current answer different questions. Approval records that the required people accepted a revision for a defined purpose. Currentness records which approved revision the organization wants recipients to use now. A team may approve a future-vintage package before it becomes current, or retain an approved prior-vintage package while inventory remains active.

Do not use final as a workflow state. It cannot explain who approved the asset, what market the decision covered, or whether a newer revision replaced it.

Store approval against the exact revision. Record the reviewer, decision, date, scope, and any conditions. If a file changes after approval, even through a small copy edit, it needs a new revision and an explicit decision about which reviews must be repeated.

Assign ownership by decision

Asset management fails when everyone can upload but nobody owns currentness. Assign ownership to the decisions that move an asset through its lifecycle.

A workable responsibility split may include:

Source owner: Confirms provenance and supplier context.
Product owner: Confirms that the asset describes the intended producer, wine, and release.
Operations owner: Confirms market item, volume, pack, codes, availability, and distributor context.
Brand owner: Confirms visual identity, approved copy, composition, and brand use.
Compliance reviewer: Reviews regulated identity, claims, and publication context where required.
Publisher: Releases the approved revision and removes its predecessor from current access.
Library owner: Maintains the state model, relationships, audit process, and exception queue.

Every current asset needs one accountable owner who can answer whether it remains usable. Shared responsibility without a named decision owner usually becomes deferred responsibility.

Link assets to products, vintages, and markets

A producer-level folder is too broad to govern product assets. Build explicit relationships among producer, wine, release, market item, and asset.

Attach a producer logo or estate history at producer level when it applies across the portfolio. Attach a tasting note or accolade to the specific release it describes. Attach a bottle shot to the package and market item it depicts. Attach a translated sell sheet to its intended language and market.

Do not copy shared assets into every vintage record simply to make them easier to find. Link one governed asset to each applicable record. Duplication creates several apparent originals and multiplies the work required to retire a logo, correct a map, or change usage guidance.

Vintage rollover should reopen every relationship that may no longer be valid. Do not carry forward a bottle image, technical sheet, review quotation, blend description, certification file, or sales presentation as confirmed merely because the wine name is unchanged. Classify each prior asset as reusable, requires revision, requires replacement, awaiting evidence, or not applicable.

Market is its own governance dimension. The same release may have different back labels, importer statements, bottle sizes, item codes, languages, pricing materials, and distributor access. Current must therefore include product, release, market, and audience context.

TTB separates required and optional wine label information and provides specific guidance for imported wine on its official wine labeling page. Keep the qualified reviewer’s approved label evidence connected to the applicable market item. Do not infer that a bottle image is correct for every market because the front label looks familiar.

Preserve versions and release history

Versioning should answer what changed, why it changed, who approved it, where it was released, and what it replaced.

Give each asset a stable identity and each change a distinct revision. Record a short change summary and the triggering evidence. Preserve the previous released file without leaving it in the default distributor view.

Use predecessor and successor links instead of relying on dates alone. The newest upload is not always the approved replacement. A future vintage asset may arrive before the current vintage leaves distribution. A translation may be newer than the source-language file without replacing it.

Release history should show the audience and channel. A file shared with one distributor for one market may not have been published to every partner collection. When a correction occurs, the history provides the recipient list and locations that need review.

Publish complete release packages

Manage distributor delivery as a release package rather than a series of unrelated uploads. A release package is the approved set for a defined product, vintage, market, audience, and effective context.

The package can include the current bottle images, technical sheet, sell sheet, producer copy, wine copy, logo, and any market-specific material the distributor needs. The exact contents should follow the portfolio’s operating requirements, not a universal checklist.

Before release, verify that:

every included asset points to the same intended product context
required product and market fields agree across the package
each revision has the required approvals
usage conditions and audience are recorded
the package has a named owner
prior assets are identified for supersession or continued parallel use
distributor permissions have been tested

Publish the package as one controlled event. Record the publisher, release date, audience, included revisions, known exceptions, and predecessor package. If one required asset is unresolved, make that gap visible rather than filling it with a prior-vintage file that appears complete.

A package can support overlapping vintages. Keep both clearly labeled and connected to their active market items. Do not describe one as old and the other as new when distributors may legitimately need both.

Give distributors access to approved views

Distributor access should expose current release packages, not the working archive. Drafts, original supplier files, internal review notes, unreleased products, restricted pricing, and superseded revisions should remain outside the default partner view.

Assign access by actual relationship, such as distributor, territory, market, portfolio, or brand assignment. Separate permission to view and download from permission to upload, edit metadata, approve, publish, retire, or administer users.

Test access with a distributor-level account. Confirm that the user can find the right product, vintage, market, and asset type, and can explain why the file is current. Also confirm that the same user cannot retrieve unreleased or out-of-scope assets through search, shared links, inherited permissions, or direct URLs.

Sales materials can fall within the federal wine advertising definition depending on their content, use, and distribution. That definition includes trade booklets, catalogs, promotional material, and sales pamphlets in 27 CFR 4.61. Covered advertising has mandatory-statement requirements under 27 CFR 4.62, and federal rules address false, misleading, and label-inconsistent statements in 27 CFR 4.64. Keep the review decision with qualified people who understand the material, publisher, audience, and destination market.

Audit on events and a defined cadence

A calendar review is useful, but it should not be the only way the team finds stale assets. Run targeted audits when the portfolio changes.

Useful audit triggers include:

a new vintage or non-vintage release
a package, label, bottle size, or importer statement change
a new market or distributor assignment
a product discontinuation or inventory transition
a brand refresh or agency handoff
an expired or changed use condition
a corrected product fact or claim
a departing employee, distributor, or supplier contact

Set a recurring cadence based on portfolio change and operational risk. The team should define the interval rather than copying a generic schedule. Review current release packages, unresolved intake, pending approvals, expiring conditions, shared links, inactive accounts, and assets with no accountable owner.

Sample the files themselves, not only their metadata. Open the released PDF, inspect the image, follow links, and compare visible content with the connected product and approval records. Search distributor views for superseded vintage strings, retired item codes, old contacts, and predecessor filenames.

TTB’s COLA Public Registry can support label research and review. Treat registry material as evidence to assess, not as proof that an importer asset is current for a particular release package, market, or distributor audience.

Record audit scope, reviewer, findings, accepted exceptions, owners, and due actions. An audit that produces only a cleanup conversation is difficult to close and impossible to compare with the next review.

Retire assets without erasing history

Retirement removes an asset from ordinary use while preserving the record needed to understand prior releases. It is not the same as deleting the file.

Start retirement when an asset is replaced, a vintage leaves active distribution, a product is discontinued, a market relationship ends, a claim is withdrawn, or a use condition no longer permits distribution. Identify every current package, collection, page, direct link, and partner view where the asset appears.

Use one controlled retirement sequence:

Confirm the reason and effective context.
Identify a successor when one exists.
Remove the asset from current packages and distributor search.
Disable or redirect current-use links according to the correction plan.
Preserve the released revision, provenance, approvals, and distribution history internally.
Record who completed retirement and what exceptions remain.
Notify affected recipients when continued use creates a material operational or compliance concern.

Do not silently delete the predecessor after publishing its replacement. The history may be needed to answer which file a distributor received, why it was approved, or which product facts appeared at that time.

Implement governance with one complete lifecycle

Pilot the model with one producer that has a current vintage, a successor release, market-specific material, and an active distributor audience. Move a representative asset package from intake through review, approval, release, audit, replacement, and retirement.

During the pilot, test whether the team can answer these questions without searching personal inboxes:

Where did this asset come from?
Which exact wine, vintage, package, and market does it represent?
Who approved this revision and for what use?
Which distributors can access it?
What did it replace?
Which current packages contain it?
What event should trigger its next review or retirement?

Fix state definitions, ownership gaps, and relationship problems before migrating the full archive. Do not import duplicate and ambiguous files as though migration itself makes them governed.

Depletement is a pre-launch workspace being designed for alcohol importer operations teams to organize current product details, sales assets, distributor asset access, technical sheets, sell sheets, and vintage updates. Whatever system supports the work, effective wine brand asset management depends on controlled provenance, exact product relationships, explicit approvals, audience-specific release packages, and retirement that preserves history.