オンラインの製品掲載は数分で削除できますが、その掲載を説明するために必要な記録は、何年も利用可能な状態に保たなければならない場合があります。欧州連合（EU）に消費者向け製品を販売している場合、製品安全はもはや製造業者だけの書類問題ではありません。あなたの掲載、サプライヤーファイル、顧客メッセージ、在庫記録、返金プロセスはすべて、製品を責任を持って取り扱ったことを示す証拠の一部となり得ます。
一般製品安全規則（GPSR）は2024年12月13日から適用されています。これは、オンラインおよびオフラインで販売される製品の一般的な安全枠組みを定めるもので、トレーサビリティ、通信販売の掲載、苦情、事故、是正措置、リコールに関する規則を含みます。欧州委員会は、2025年に4,671件のSafety Gate警報を報告しましたが、これは記録された最高数であり、2024年から13%増加し、さらに5,794件のフォローアップ措置が報告されました。
このガイドは、規則を小規模オンライン販売者のための実用的なシステムに変換します。これは法的助言や製品固有の適合性要件の代わりになるものではありません。コンプライアンスアドバイザーと話し合うべき記録、責任者、管理策を特定するために使用してください。
まず、サプライチェーンにおけるあなたの役割を特定する
同じ事業者が複数の役割を持つ場合があります。プライベートラベルのショップは、自社の名前や商標で製品を販売するため、製造業者と見なされる場合があります。EU外から商品を輸入する事業者は輸入業者と見なされる場合があります。EUの卸売業者から完成品を購入して再販するショップは、一般的に販売業者です。フルフィルメントプロバイダーも、EUに所在する製造業者、輸入業者、認可代表者、またはその他の責任事業者がいない事業者の製品を取り扱う場合、特定の責任を負う場合があります。
あなたの役割によって、実行すべきチェックと保持すべき記録が決まります。マーケットプレイスを利用することで、あなたの義務がマーケットプレイスに移転すると思い込まないでください。プラットフォームには独自の義務があるかもしれませんが、製品を提供する事業者は、何を販売しているのか、そしてそのオファーに必要な情報が含まれているかどうかを把握する必要があります。
GPSRは、EU市場に上市または利用可能にされる消費者製品に広く適用され、有料で販売される製品や無料で提供される製品を含みます。これは、新品、中古品、修理済み製品、または再生製品に適用される場合があります。より具体的なEU安全法が適用される製品は、単に枠組みの外にあるわけではありません。GPSRは、より具体的な規則が対処しないリスクや側面を依然としてカバーできます。
以下のフィールドを含む1ページの製品役割台帳を作成します。
- 製品またはSKU;
- ブランドおよび製造業者;
- その製品に対するあなたの役割;
- 製造業者が所在する国;
- EU責任経済事業者および連絡先詳細;
- 適用される製品固有の法律または規格;
- 販売チャネルおよびサービスを提供するEU加盟国;
- 安全性、苦情、リコール決定の責任者。
この台帳は、あなたのビジネスが「GPSR準拠」であるという一般的な声明よりも有用です。次の決定、つまり各製品にどの証拠が属するかという決定がはるかに容易になります。
掲載開始前に製品安全ファイルを構築する
中心となる義務は単純です。安全な製品のみがEU市場に上市または利用可能にされ得るということです。難しいのは、どのようにしてその結論に達したかを示すことです。
あなたが製造またはプライベートラベルする製品については、内部リスク分析と技術文書から始めます。ファイルには、製品とその安全に関連する特性を説明し、合理的に予見可能なリスクを特定し、それらを排除または低減するために使用される措置を説明する必要があります。テストレポート、取扱説明書、警告、パッケージアートワーク、部品情報、適用される規格、サプライヤー宣言、承認済み製品バージョンをまとめて保管します。
あなたが販売する製品については、サプライヤーの一般的な保証に頼るのではなく、チェックを実行するのに十分な証拠を収集します。製造業者の身元、モデルまたはバッチ情報、取扱説明書、警告、関連する適合性作業の証拠を求めます。パッケージと製品表示が実際に受け取る在庫と一致することを確認します。サプライヤーがアイテムを正確に特定できない場合、顧客や当局に後で正確に特定することはできません。
有用なファイル構造は次のとおりです。
SKU-1042/
identity-and-versions/
supplier-and-responsible-person/
risk-assessment/
tests-and-standards/
labels-warnings-instructions/
complaints-and-incidents/
corrective-actions-and-recalls/各文書にバージョンと承認日を付けます。製品写真だけでは信頼できる識別子ではありません。モデル番号、バッチまたはロットコード、バーコード、部品バージョン、および各バージョンが販売された期間を保持します。
オンラインオファーを魅力的なだけでなく、完全なものにする
通信販売の場合、製品オファーは、顧客が購入する前に、主要な安全およびトレーサビリティ情報を明確かつ視覚的に表示する必要があります。少なくとも、以下を表示することを計画します。
- 製造業者の名前、登録商号、または商標;
- 製造業者の郵便および電子連絡先住所;
- 製造業者がEU外にいる場合、EU責任者の名前、郵便および電子住所;
- 製品を識別する情報（写真、タイプ、その他の製品識別子を含む）; および
- 関連する加盟国の消費者が容易に理解できる言語での必要な警告および安全情報。
この情報を一般的な利用規約ページ、携帯電話では読めない画像、またはマーケットプレイスがテンプレートを変更したときに消えてしまうリンクに隠さないでください。この情報は、特定のオファーと製品バージョンに添付されたままである必要があります。
公開ワークフローに掲載リリースチェックを追加します。新しいSKUを承認する担当者は、掲載データが製品ファイルと一致し、責任者情報が最新であり、警告が必要な言語であり、オファーが正確なモデルまたはバリアントを識別していることを確認する必要があります。サプライヤーがパッケージ、部品、取扱説明書、または責任事業者を変更した場合は、その掲載をそのチェックに再度通してください。
これは監査証跡を維持するのにも良い場所です。製品が最初に公開されたときと、重要な変更が公開されたときの承認済み掲載コンテンツとタイムスタンプ付きスナップショットを保存します。マーケットプレイスが掲載ページを提供する場合は、プラットフォームが過去のバージョンを保持してくれると想定せずに関連情報をエクスポートします。
トレーサビリティを通常の取引フィールドにする
トレーサビリティは、年に一度のスプレッドシート演習ではありません。これは、アイテム、その供給元、その宛先、および顧客取引の間の接続です。
すべての製品移動について、あなたの役割が必要とする以下の情報をできるだけ多く取得します。
- サプライヤー、製造業者、輸入業者、またはその他の上流事業者;
- 発注書、入荷日、バッチまたはロット;
- SKU、モデル、シリアル番号、またはその他の製品識別子;
- 倉庫の場所と受領数量;
- 販売チャネル、注文番号、宛先国、発送日;
- 安全連絡のために保持される顧客連絡先情報; および
- 返品、返金、交換、修理、または廃棄の結果。
GPSRは、経済事業者に対し、製品が供給された日または下流に供給した日から10年間、製品情報を提供できることを要求しています。サプライチェーンのトレーサビリティ情報は6年間利用可能でなければなりません。これらの期間は、すべての業務文書を永久に保持する理由にはなりませんが、保持ルールを意図的に設定し、アーカイブされた記録が実際に取得できることをテストする理由にはなります。
混合在庫を販売する場合、SKUだけを識別子にしないでください。単一のSKUが複数の製造バッチまたはパッケージ改訂をカバーする場合があります。安全通知が在庫の一部にのみ適用される可能性がある場合は、ロット、シリアル、またはバージョンフィールドを使用します。
苦情を安全シグナルに変える
カスタマーサポートは、製品が安全でないという最初の証拠を目にすることがよくあります。「充電器が熱くなった」「留め金が壊れた」「子供が小さな部品を飲み込んだ」などの苦情は、一般的な受信トレイに消えてはいけません。
少なくとも以下の項目を含む製品安全苦情台帳を作成します。
- 受領日と通信チャネル;
- 製品、モデル、バッチ、注文識別子;
- 何が起こったかについての顧客の説明;
- 負傷、物的損害、またはヒヤリハット情報;
- 写真、ビデオ、返品アイテムの詳細、その他の証拠;
- 初期リスク分類とエスカレーション担当者;
- サプライヤーまたは製造業者への通知日;
- 調査結果と是正措置; および
- 返金、交換、リコール、または当局通知へのリンク。
通常の不満と潜在的な安全上の苦情を区別しますが、スタッフが初期のシグナルを無視するほど閾値を高くしないでください。小さな障害のクラスターは、顧客が負傷を報告しない場合でも重要になる可能性があります。定期的なスケジュールで台帳をレビューし、負傷、火災、感電、窒息の危険、化学物質への曝露、その他の重大なリスクが申し立てられた場合は直ちにエスカレーションをトリガーします。
製品によって引き起こされた事故があなたの注意を引いた場合は、該当するSafety Business Gatewayプロセスを不当な遅延なく使用し、製造業者および責任者と調整します。正しい報告当事者は製品と役割によって異なる場合があるため、誰がどのような理由で決定を下したかを文書化します。
必要になる前にリコールワークフローを準備する
リコールは、ウェブサイト上の通知だけでなく、運用上のイベントです。さらなる販売を停止し、影響を受けるユニットを特定し、顧客に連絡し、上流事業者と調整し、財務上の影響を説明する必要があります。
指名された担当者を含む短いリコール手順書を作成します。
1. 封じ込め
影響を受ける製品および関連するバッチについて、掲載、有料広告、補充、フルフィルメントを一時停止します。物理的な在庫を隔離し、交換出荷が誤ってリリースできないようにシステムにマークを付けます。すべての販売チャネルに、ブロックする識別子と日付範囲を通知します。
2. 範囲
ロット、シリアル、バージョン、注文記録を使用して、影響を受けるユニットを特定します。販売数、在庫数、返品数、廃棄数、転送数、およびまだ説明のつかない数を調整します。範囲を決定できない場合は、保守的な仮定を記録し、専門家のアドバイスを求めます。
3. 通知と直接連絡
製品、危険性、影響を受ける識別子、顧客がすべきこと、助けを得る方法を説明する明確な言葉を使用します。リコール通知が書面で提供される場合は、必要なリコール通知形式を使用します。利用可能な顧客データを使用して影響を受ける顧客に直接連絡します。一般的なホームページのバナーだけでなく。
4. 救済
修理、交換、または適切な返金のためのロジスティクスと会計を計画します。顧客は危険な製品を返品するために支払う必要も、救済を無期限に待つ必要もありません。オファー、顧客の選択、発送または返金日、および連絡試行の失敗の証拠を保持します。
5. 終了
進捗状況を報告し、製品ファイルを更新し、最終的な母集団調整を保持し、掲載と在庫管理がいつリリースされたかを文書化します。リコールは、製品が1つのストアフロントから削除されただけでは完了しません。
財務記録を安全記録と整合させる
製品安全作業は、帳簿の数値を変更します。回収は廃棄在庫を生み出し、リコールは返金と送料のコストを生み出し、交換プログラムは新しいフルフィルメント取引を生み出す可能性があります。運用記録と会計記録が異なる識別子を使用している場合、財務への影響を証明することは困難になります。
リコール関連の活動を個別の勘定科目またはディメンションで追跡します。例：
- 在庫評価損または廃棄;
- 顧客返金;
- 交換製品コスト;
- 返品送料とリバースロジスティクス;
- テスト、検査、コンサルタント費用; および
- サプライヤーからの回収または保険金収入。
安全母集団を元帳に調整します。影響を受けたユニット、返金されたユニット、交換されたユニット、返品されたユニット、廃棄されたユニットにはそれぞれ説明可能な残高が必要です。元の販売を保持し、リコールケースへの参照とともに返金または交換を記録します。最終的な合計をきれいに見せるために履歴を上書きしないでください。
この規律はキャッシュプランニングにも役立ちます。リコールは、元の販売が利益を上げていた場合でも、即時の現金流出を生み出す可能性があります。在庫価値、顧客の露出、潜在的な是正コストを含む毎月の製品リスクレビューは、売上報告書だけよりも運用キャッシュの現実的なビューを提供します。
30日間の実装チェックリスト
あなたのプロセスがまだ非公式である場合は、この順序を使用します。
1〜5日目：露出を棚卸しする。 EU顧客に提供されるすべての消費者製品、販売チャネル、サービスを提供する国、および各アイテムに対するあなたのビジネスの役割をリストアップします。バッテリー、熱、子供の使用、摂取、可動部品、化学物質、またはソフトウェア制御機能を備えた製品にフラグを立て、より詳細なレビューを行います。
6〜12日目：証拠のギャップを埋める。 不足している製造業者、輸入業者、責任者、モデル、バッチ、警告、取扱説明書、テスト、リスク評価の記録を要求します。事業者または製品を正確に特定できない場合は、製品を保留にします。
13〜18日目：掲載と取引データを修正する。 製品情報管理システム、マーケットプレイステンプレート、注文エクスポート、倉庫受領書に必要なフィールドを追加します。すべてのチャネルから1つの掲載をモバイルデバイスでテストし、履歴記録を取得できることを確認します。
19〜24日目：苦情とリコールをリハーサルする。 架空のバッチを使用して、エスカレーション、顧客マッチング、チャネル削除、隔離、返金承認、当局通知の責任をテストします。影響を受ける顧客を特定し、ユニットを調整するのにかかる時間を測定します。
25〜30日目：運用を財務に接続する。 元帳にリコールディメンションを追加し、保持とアクセスルールを確立し、毎月のレビュー担当者を割り当て、製品母集団から返金、交換、在庫移動までのサンプル調整を作成します。
目標は、完全に見えるバインダーではありません。それは、製品設計または調達から、掲載、販売、苦情、是正措置、最終的な会計エントリまでの反復可能なチェーンです。
財務管理を簡素化する
製品安全管理が在庫、返金、リコール取引を生み出すとき、透明な記録は作業をレビューしやすくします。Beancount.ioは、透明でバージョン管理され、AI対応のプレーンテキスト会計を提供します。ドキュメントまたはFavaダッシュボードを探索して、あなたのチームがすでに維持している運用記録に財務履歴を接続してください。
