納品パッケージ群
納品とは、記録されていない決定が他人の問題になる地点である。
キャプションファイルの欠落、誤ったカバーフレーム、音楽キューに関する答えられない質問でパッケージを却下する買い手は、クリエイティブの失敗ではない。それは簿記上の失敗であり、完全に防げる。
01 / ワークフロー内
パッケージに含まれるもの
- マスター群
- ブリーフが指定したフォーマットで言語トラックごとに受け入れられた主要制作物。
- プラットフォーム版とカットダウン
- 承認されたマスターから生成される9:16、1:1、または16:9の派生版。ブランド案件では、UGC風カットダウンは承認済みキャンペーンの派生であり、単独の制作物ではありません。
- キャプション
- 各トラックごとに、正確さ、タイミング、読み速度をチェックし、宛先が要求する形式で。
- カバーフレームとサムネイル
- 縦型フィードではカバーフレームがフックの一部なので、grabではなくselectedを使っています。
- キューと権利情報
- どの音楽、どのソース資産、どの付与条件で、どの地域と期間か。
- 出所（プロヴェナンス）
- 納品版がどのように作られたか：使用モデル、参照資料、カノン版、修正履歴とそれぞれを受理した人物。
- 納品マニフェスト
- パッケージの中身と仕様が求める要件がすべて満たされていることを示す目録。
02 / ワークフロー内
作り直しではなく派生
9:16のカットダウン、1:1版、3つのプラットフォーム編集が必要なキャンペーンは2通りで制作できる。各々を個別の制作にするか、すべてを1つの承認済みマスターから派生させるかだ。
派生は唯一スケールするバージョンであり、ブランドの一貫性が保たれる唯一の方法です。別々に制作された三つの編集は、製品が誤って表示される三つの可能性を生みます。一つのマスターと三つの派生版は、承認ポイントが一つで出力が三つです。
03 / ワークフロー内
最終納品の受け入れ
- 主要マスター確認ブリーフで指名されたクリエイティブ承認者Blocks: プラットフォーム版とカットダウンの派生
- 言語と市場の審査トラックごとのネイティブレビュアーBlocks: そのトラックのみで、マスターではありません。
- 最終納品の受け入れ必要に応じてブランドまたは法務を含む指名された納品承認者Blocks: パッケージの引き渡し
質問
制作に投入する前に
Tosheoはエピソードを代わりに公開しますか？
いいえ。Tosheoの自動化は外部公開できません—それが人間による制御ルールの一部です。Tosheoは指定した配信先向けの納品パッケージを準備し、あなたまたは配信パートナーが公開します。
Tosheoはプラットフォームの仕様に沿った納品ができますか？
納品仕様の管理はフェーズ1のサービスの一つである：買い手やプラットフォームの仕様を受け取り、それに合わせてパッケージ化する。私たちが行わないのは、配給業者、代理人、または権利代表者を自称することだ。なぜなら私たちはそれらではないからである。
プラットフォームが我々の計画に含まれていない要件を求めたらどうしますか？
それは範囲変更となり費用が発生し、影響を受けるゲートを再び開きます。納品要件がグリーンライトのブリーフに置かれている理由は、これを制作の通常の結末ではなく例外にするためです。
カットダウンは含まれますか？
派生版はコマーシャル単位です：パッケージごとに定義された言語・市場・プラットフォームのバリアント数。数は制作ごとに範囲を定めます。無制限の派生が提供されないのは、無制限の生成が提供されないのと同じ理由です。
マニフェストは何を証明しますか？
仕様に対してパッケージが完成していること、そして各納品バージョンがどのように制作されたか。権利や出自のデューデリジェンスを行う買い手にとって、それは「答え」と「調査」の差です。