How to hand creators one versioned product fact set when teams disagree

Direct answer

Short answer: collect the exact statements Sales and Product disagree about, identify the *audience-facing fact* each statement implies, and ask the owner of that fact for its current source record. Product or service owners should establish what the product actually does and for whom; the owner of the current commercial offer should establish price, package and availability terms; a qualified reviewer should assess claims that need special substantiation. Put the supported wording, conditions, source version, decision owner and review date into one versioned creator packet. Mark a disputed line unresolved until its owner can support or narrow it. Give every creator the same current packet and send a dated replacement when a fact changes. A sales slide, a product roadmap and an enthusiastic creator are not interchangeable evidence of what a buyer can get today.

This task happens before creative copy approval. The served UGC brief guide asks the brand to list claims it cannot support among the guardrails; its brief template has a general must-show and dos/don'ts field. N10026-007 supplies the missing upstream fact decision when two internal teams are still giving different answers. The claim-to-evidence guide is the later review of one creator's exact spoken, written or visual claim against evidence before publication. This page does not reproduce that final-cut substantiation check. It makes sure creators start from one coherent, dated product and offer packet rather than settling a company dispute in a group chat.

Use the blank fact-handoff card, CSV register, and decision map. Use one card or CSV row per disputed fact, with the same packet ID and version for facts sent together to the same audience. They contain no real client facts or customer data. A version number is an editorial reference to an accepted snapshot, not a claim that a particular software product, legal rule or platform requires this exact format.

Freeze the disagreement as exact audience-facing statements

Ask Sales and Product for the words they are currently using, not for a summary such as “the calendar feature is controversial.” Copy the actual line from the sales deck, landing page, product release note, offer sheet or creator draft, with its date and owner. Then write the likely takeaway: “Every buyer can do this,” “the action is available on the free plan,” “the result is instant,” “this package includes that feature,” or whatever the sentence would lead a reasonable viewer to expect. Two teams may be arguing about different claims without realizing it. “The feature exists” and “the feature is included in this plan for this market today” are not the same fact.

Separate the disputed content into fact units. Feature behavior, entitlement, geography, timing, pricing, included items, delivery or warranty can each have a different source. Do not force them into one vague approval cell. A creator only needs enough detail to say the right thing, but the client needs to know what each sentence is built from. Record the product/version or service revision, audience role, plan, market, channel and intended posting window when any of those conditions change the claim. A fact without scope is a future disagreement waiting to happen.

For an ad or sponsored endorsement directed at U.S. consumers, this precision matters beyond internal tidiness. The FTC's advertising FAQ explains that the FTC considers the whole ad—words, pictures, express and implied messages—and that objective claims need support before the ad runs. The FTC's substantiation policy similarly says advertisers and agencies need a reasonable basis for objective claims before dissemination. Those sources do not mandate a versioned spreadsheet; the sheet is our practical way to keep current wording and its basis together before it reaches creators.

Assign each fact to the team that can prove it

Do not resolve “Sales versus Product” by choosing a department as a universal winner. Ask which team controls or can verify the specific fact. For a current feature, product behavior or plan entitlement, the product owner may have release records, an audience-facing plan matrix and a repeatable task path. For a time-limited discount, quote, bundle or sales promise, the commercial owner may have the signed offer or current campaign terms. For fulfillment, stock or regional availability, operations may own the actual inventory or service capacity. A claim that combines these facts needs a join across them; neither a slide nor a product screenshot alone answers the whole sentence.

Give each fact one decision owner who can close or explicitly leave it unresolved, while retaining the contributing source owners. The decision owner is not a new permanent committee. It is the person who can say which wording the client will hand to a creator for this campaign and can tell the affected people when it changes. If Sales promised a feature that Product says is not publicly available, the product owner cannot make the feature real by approving copy, and the marketer should not hide the customer promise. The account or commercial owner needs to address any affected customer expectation through the appropriate business channel. The creator should not be recruited to reconcile that promise in public.

Look at the *primary record*, not only its presentation. A release note may describe a feature that is rolling out to selected accounts, while a pricing page or contract says which plans include it. A live screen can show what one test account saw but may not prove that the advertised audience has access. A sales deck may show what a rep intended to offer but not whether the product currently delivers it. The packet should name the source record and revision, its owner, what was observed or agreed, and what it does not establish. If the actual source is unavailable, record that absence rather than creating an “approved” sentence from memory.

Decide one permitted wording or keep the fact open

For each disputed line, write a disposition: supported as stated, narrower wording, not for creator use, or unresolved pending source. These are editorial decisions, not legal classifications. The permitted wording should be short enough to quote in a brief and specific enough that a creator can use it without adding a hidden assumption. For example, “available to eligible Team-plan workspaces in the U.S. web app” is more informative than “available now” when the source actually limits plan, market and surface. If a number or comparison is proposed, preserve the method and cohort behind it or keep it out of creator copy until its own evidence is reviewed.

Do not solve a conflict by averaging claims. If Sales says “all plans” and Product says “Team plan only,” “most plans” is not a compromise supported by either source. Do not replace “instant” with “fast” if the current product still waits on a variable process and the word implies a result the team cannot back. A qualifier can make a line true only if the whole sentence, including visuals and omission, conveys the supported limit. The FTC FAQ's express and implied claim explanation is why an approved line must be checked for what a viewer is likely to understand, not only for technically correct words.

If a fact remains open when creators need to work, choose a different supported angle rather than asking them to script around an unresolved promise. They can demonstrate a verified task, describe their own actual experience, or focus on a buyer problem without claiming the disputed capability. The FTC's endorsement FAQ says an endorsement has to reflect the endorser's honest opinion or experience and cannot be used to make a claim the marketer itself could not legally make. A creator's genuine enthusiasm is valuable creative material; it does not turn an unsupported product statement into a substantiated one.

Release one versioned packet, not competing documents

Assemble the decided facts into a single creator-facing packet for the campaign. Its header should carry a packet ID, version, decision date and time zone, intended market and product release scope, effective publishing window, decision owner, and the link to the current copy. Each fact row should carry a stable fact ID, approved wording, essential limits, source reference and revision, owner, status, and next review trigger. Include a short do-not-say line for wording that was rejected or remains unresolved. The packet is a view of several owned records; it is not a claim that one department's document has authority over every subject.

Keep the creator portion concise. A creator needs the product name and version they will use, the task or feature they can show, permitted plain-language facts, material limits and where to ask a question. They do not need the entire internal argument, private customer contracts or raw regulatory analysis. Keep the private source references in the authorized client record and put only safe IDs or public references in the packet being shared. A public downloadable worksheet should remain blank. If a fact depends on a plan or region, put that condition next to the wording, not in a separate footnote the creator may never see.

The same scoped version should reach every creator speaking to the same plan, market and release. If creators are addressing different audiences, give each the applicable scoped packet or clearly marked rows instead of pretending one feature claim fits all. A link to a mutable document can be convenient, but it is not enough if no one knows which text they saw when filming. Record the version and sent-at time for each recipient, and ask them to confirm receipt of a replacement that affects their script or footage. An email, existing project record or shared document version can carry this; no second content-management system is required. The purpose is to be able to answer: “Which product fact set did Creator B use for the draft we are reviewing?”

Use the original decision map to explain the move from competing lines to one packet. It shows different fact owners feeding one versioned handoff and a later change becoming a new version rather than silently rewriting history. It does not depict an FTC-required workflow or a Superdirector automated feature.

Handle a changed product fact before it becomes stale copy

The packet needs a change path because release notes, plan terms and offers change. When a source owner reports a change, compare it with the exact fact rows and creator deliverables already in flight. A cosmetic interface change might affect a screen shot while leaving approved wording true. A feature removal, plan change, market restriction, price change or new limitation may alter what the creator can honestly say. Create a new packet version with a dated reason and the affected fact IDs. Retain the old version and its recipient list so a draft made under it can be identified.

Send a specific difference: “F-02 changed from Team and Basic to Team only; remove the Basic-plan line,” rather than “please use the latest facts.” Identify which scripts, filmed scenes, captions, links and pending posts need re-review. The change owner should notify the people who received the earlier version and record the response. If a creator has already filmed, the product owner can supply a current reference and the content owner can decide whether a pickup, corrected caption, narrower line or new scene is needed. This later visual comparison is the job of the outdated-product-UI guide, while the final exact claim review belongs to the claim-evidence guide.

Do not backdate the new version or quietly replace the old text in a shared folder. A retrospective correction can explain a mistake, but it does not make the prior claim supported at the time it was said. If the product changes after a post is public, keep the live post's wording and publication context, then decide whether an update, creator correction or withdrawal is needed. The record should show what changed and when; the public should not be left with a false claim because the internal packet was updated privately.

Fictional case: a sales promise outruns the product release

Entirely fictional teaching case. “LedgerNest” is an invented software product; its plans, releases, team messages, source records and creator packet below are not Superdirector or client facts. No real account, sales deck, feature test, creator script, customer promise or campaign outcome was observed.

Imagine a LedgerNest sales slide dated October 7, 2026 says, “Every plan instantly syncs every calendar.” A product release record for fictional web release 4.2, dated October 12, says only the Team plan can connect a supported calendar in the web app. Its sync timing varies, and the Basic plan has no calendar connection. A creator brief drafted from the older slide says, “I linked all my calendars in seconds on the free plan.” These are three different texts: an old sales statement, a limited current capability, and a creator's proposed first-person experience. None should be treated as equivalent.

The campaign fact owner splits the claim into F-01, calendar connection exists; F-02, plan entitlement; F-03, sync timing; and F-04, creator's personal experience. The fictional Product owner can support F-01 only for the web app and supported calendars on the Team plan. The current plan matrix supports F-02 for Team but not Basic. No source supports “instant” or “every calendar,” so F-03 is not for creator use. The creator must actually use the applicable path before saying “I linked”; F-04 is not supplied by either Sales or Product. The sales owner also checks whether any customers were promised Basic-plan sync and handles that separate commercial repair. The creator does not make that customer promise true by repeating it.

Version LN-CREATOR-1, dated October 13 in this fictional case, permits: “On the Team plan in LedgerNest's web app, I connected a supported calendar to my workspace,” but only if the creator personally performs that path and the statement matches their genuine experience. The packet also states: “Do not say every plan, every calendar or instant sync.” If the creator has not yet tried it, the packet instead offers a non-first-person product fact with the same scope and asks them to verify the demo before an endorsement. The invented source IDs and dates are illustrative; they do not prove any actual software capability.

Suppose the fictional Product team later changes the eligible calendar list before the creator publishes. The fact owner issues LN-CREATOR-2 with F-01's revised scope, identifies the creators who received version 1, and names affected scripts and footage. A creator who already filmed a calendar no longer supported may need a new demonstration or a different claim. The earlier packet remains attached to the earlier draft; it is not overwritten. This is the practical value of versioning: it makes a disagreement and its correction inspectable without asking a creator to remember which meeting settled the issue.

The blank handoff card and CSV deliberately contain no LedgerNest rows. The fictional example does not imply an actual Superdirector workflow has verified plan entitlements or resolved a client conflict.

Give the creator a usable answer and retain the owner

The handoff message can be short: “Use packet [ID/version/date] for [product release, audience, market and posting window]. Facts F-01 to F-03 are the permitted product wording; do not use the disputed older line. If your account shows something different, contact [owner] before describing it as generally available. Use your own honest experience and voice. We will send a new version if a source changes.” This is not a demand for the creator to read the company's internal tickets. It gives them one coherent current answer and one person who can resolve a mismatch.

At the next content review, compare the creator's actual script and footage with the version they received, then apply the claim-to-evidence method to any exact claim they added. A creator may honestly notice a limitation or make a narrower observation; the client should not force the creator to recite an approved line that is inconsistent with their experience. Conversely, an unscripted statement about a capability the company cannot support needs review before it is amplified. The FTC policy requires reasonable support for objective advertising claims before dissemination, and its endorsement guidance preserves the creator's honest voice. The versioned packet helps the team meet those aims; it is not legal approval or a substitute for claim-specific evidence.

Track a small number of useful facts: how many disputed rows have a current owner and source; which packet version each creator received; whether a changed fact reached affected drafts; and whether the final approved wording matched the published post. Do not celebrate the number of packet versions. The success condition is that a creator and a client can point to the same truthful product scope at the moment the content is made and released. No new scheduler, database or approval bureaucracy is needed for this editorial handoff.

Source and scope note

Primary sources checked 2026-10-29 UTC: the FTC Policy Statement Regarding Advertising Substantiation, the FTC Advertising FAQ, and the FTC Endorsement Guides FAQ. They support U.S. advertising and endorsement boundaries, not a mandated product-fact versioning process. The per-fact authority method, dispositions, packet format and LedgerNest case are original editorial teaching material. No live client source record, current product entitlement, customer promise, creator experience, campaign result or keyword volume was verified for this page.