検索ブランド相談室 | 検索と評判の専門メディア

法人向けサービスサイトの情報更新を誰が持つ?営業・法務・制作で料金・実績・契約条件を管理する方法

部署:マーケティング担当者部署:経営者・責任者レベル:実践
営業・事業・法務など複数部門の資料がWebサイト更新用のパソコンへ集まる様子

法人向けサービスサイトでは、料金改定や契約条件の変更が社内で決まっているのに、Webサイトだけ古いまま残ることがあります。原因は「Web担当者が更新していない」ことだけではありません。営業・事業・法務などが持つ元情報の変更を、誰がWeb担当へ伝え、誰が内容を確認し、いつまでに公開するか決まっていないことが問題です。

必要なのは、すべてをWeb担当者へ集約することではなく、料金・実績・契約条件などの情報ごとに「元情報の責任者」「変更を知らせる人」「承認者」「Web反映担当」「更新期限」を決めることです。

この記事では、法人向けサービスサイトの情報が古くならないための役割分担と更新フローを、実務で使える形に整理します。

サービス情報の更新は「Web担当者一人の仕事」にしない

法人向けサービスサイトの情報管理では、情報の正しさを保証する人と、Webサイトへ反映する人を分けることが基本です。

たとえば営業部門が新しい料金体系を最も早く把握しているなら、料金の元情報までWeb担当者が独自に管理する必要はありません。事業部がサービス仕様を決め、法務が契約条件を確認している企業であれば、それぞれの部門が自分たちの情報について責任を持ちます。

Web担当者は、各部門から確定情報を受け取り、サイト上で分かりやすく整理し、必要な確認を経て公開する役割を担います。

公的機関のWeb運用でも、情報の専門担当者が事実の正確性を持ち、Web・コンテンツ担当が掲載形式や公開を担当する分業が採用されています。Medway Councilは、専門担当者が情報の正確性を保ち、変更があればコンテンツ担当へ知らせる役割を明示しています。Westmorland and Furness Councilでも、サービス側・コンテンツオーナーが事実の正確性を担い、Webチームが利用しやすさや掲載形式を担う形です。

重要なのは、「サイトを触れる人=情報の責任者」としないことです。

Web運用全体の編集フロー・役割分担・品質チェックを整理する場合は、コンテンツ制作・運用体制の全体像も確認してください。

最初に料金・実績・契約条件ごとの「元情報」を決める

情報更新の仕組みを作るときは、Webページから考えるのではなく、その情報が社内のどこで決まっているかから整理します。

一例として、次のように分けられます。

Webに掲載する情報 元情報を持つ部門の例 確認が必要な部門の例 Web側の役割
料金・初期費用・月額費用 営業・事業責任者 経理・責任者 表示内容を反映
サービス内容・対応範囲 事業部 営業 サービスページを更新
導入実績・件数 営業・事業部 顧客担当・広報 掲載可否を確認して反映
導入事例 営業・顧客担当 顧客・広報 原稿・画像を整理して公開
契約期間・解約条件 事業部・法務 法務 Web上の説明を更新
キャンペーン・期間限定条件 営業・マーケティング 責任者 開始・終了日に合わせて更新
料金・契約条件・導入実績の各担当部署からWeb担当へ情報が集まる責任分担の図

料金や契約条件などの正しさを判断する担当と、Webへ反映する担当を分けると、確認先が明確になります。

この表で大切なのは、部署名そのものではありません。

自社について、「この数字・条件が正しいか最終的に答えられるのは誰か」を決めることです。

Webサイトの運用責任者だけ決めても、料金の確定権限や契約条件の判断権限までWeb担当者にあるとは限りません。情報の種類ごとに責任者を置いた方が、変更時の確認先が明確になります。

変更を検知できなければ更新フローは機能しない

更新責任を決めるだけでは不十分です。

料金改定、サービス内容の変更、契約条件の変更、新しい導入実績の追加などが起きたときに、Web更新が必要だと気づける仕組みまで決めます。

更新を始めるきっかけは、大きく2種類あります。

社内の変更をきっかけに更新する

たとえば、次のような変更です。

  • 新料金が決定した
  • プラン構成が変わった
  • 提供対象地域が増えた
  • 契約期間や解約条件が変わった
  • 新サービスが追加された
  • 掲載可能な導入実績が増えた
  • サービス名称が変わった

この場合、「料金変更が確定したら営業責任者がWeb担当へ連絡する」といったルールを決めます。

重要なのは、Web担当者が会議や社内チャットを見回して変更を探す運用にしないことです。

定期確認で取りこぼしを見つける

すべての変更をリアルタイムに伝達できるとは限らないため、定期確認も必要です。

英国のDepartment for Educationのコンテンツ設計ガイドでも、コンテンツの正確性や最新性を維持する方法、変更の合意方法、メンテナンスの責任をあらかじめ決める考え方が示されています。Medway Councilでは「変更が起きたとき」に加え、少なくとも年1回のレビューも運用に含めています。

法人向けサービスサイトでは、情報の変わりやすさに合わせて確認頻度を変える方法が使えます。

情報 変更時の連絡 定期確認の例
料金 必須 月次・四半期
キャンペーン 必須 終了日前にも確認
契約条件 必須 四半期・半期
サービス仕様 必須 四半期
導入実績 随時 月次・四半期
会社概要 変更時 半期・年次

これは一律の正解ではありません。自社で変更頻度と誤掲載時の影響を見ながら決めます。

「原本・変更検知・承認・反映・期限」の5項目を決める

各情報について、最低限5つの項目を整理すると更新責任が明確になります。

サービス情報を原本から変更検知、承認、Web反映、更新期限まで管理する5段階の流れ

Web更新の担当者だけでなく、元情報の管理から公開期限まで一連の責任を決めることが更新漏れ防止につながります。

管理項目 決めること
原本 何を正式情報として扱うか
変更検知 誰が変更発生をWeb側へ伝えるか
承認 Web掲載内容を誰が最終確認するか
Web反映 誰がCMSへ反映するか(制作会社への依頼を含む)
更新期限 変更確定後いつまでに反映するか

たとえば料金であれば、次のように設計できます。

原本
事業部が管理する正式な料金表

変更検知
料金改定決定時に事業責任者からWeb担当へ連絡

承認
営業責任者が金額、法務担当が注記や契約条件を確認

Web反映
Web担当または制作会社

更新期限
新料金の適用開始前まで

ここまで決めると、「誰かが更新するはず」という状態から「変更が起きたらこの流れで更新する」という状態へ変わります。

情報によって承認ルートを変える

すべての更新を同じ承認フローにすると、簡単な修正まで止まりやすくなります。

国内のWebガバナンスに関する企業記事でも、コンテンツのリスクや種類によって承認フローを分ける設計が紹介されています。

たとえば、次の3段階で分けられます。

Web更新内容を軽微な修正、事業部確認、複数部門承認の3段階に分けた図

変更内容の重要度に応じて承認ルートを分けると、軽微な修正まで止めずに運用できます。

レベル1:Web担当だけで修正できる情報

  • 誤字脱字
  • 明らかなリンク切れ
  • 表示崩れ
  • 文章の読みやすさを改善する軽微な修正

元の意味や条件を変更しない範囲です。

レベル2:事業部の確認が必要な情報

  • サービス内容
  • 対応範囲
  • 導入実績
  • プラン名称
  • サービス提供の流れ

Web担当だけでは事実確認できない内容を含みます。

レベル3:複数部門の承認が必要な情報

  • 料金
  • 契約条件
  • 解約条件
  • 保証に関する表現
  • 実績数値
  • 法令・規約に関係する表示

内容によって営業、事業責任者、法務などを加えます。

CMS側でも、ページの変更後に承認を求めるワークフローを設定できる仕組みがあります。Microsoft SharePointでは、更新されたページを公開する前に承認要求を行うページ承認フローが提供されています。

ただし、ツールを導入する前に「誰が何を承認するか」を決めることが先です。

料金・契約条件は「変更日」とWeb反映日をセットで管理する

料金や契約条件では、「最新版がどれか」だけでなく、いつからその条件を適用するのかも重要です。

たとえば10月1日から料金が変わる場合、社内料金表だけ9月中に変更され、Webサイトが10月中旬まで旧料金のままであれば、営業資料とWebの情報が食い違います。

料金変更の適用開始日とWeb更新日のずれを防ぐための時系列図

料金や契約条件は、正式決定日だけでなく適用開始日とWeb更新日までセットで管理します。

そのため、変更管理表には次の項目を入れておくと確認しやすくなります。

  • 変更内容
  • 正式決定日
  • 適用開始日
  • Web更新予定日
  • 対象ページ
  • 元情報の責任者
  • 承認者
  • 反映担当
  • 公開確認日

消費者向け表示については、消費者庁も商品・サービスの価格などの取引条件を正確かつ明瞭に表示する必要性を示しています。また、価格などの取引条件についても、表示内容を確認するための管理措置が求められると説明しています。法人向けサービスでは取引形態や適用法令が異なるため個別確認が必要ですが、Web上の価格・条件と正式な取引条件の不一致を防ぐ運用自体は重要です。

実績は「件数」だけでなく掲載条件も管理する

導入実績は料金とは違う更新事故が起きやすい情報です。

たとえば、

  • 累計導入数が古い
  • 顧客ロゴの掲載許可期間が切れている
  • 以前提供していたサービスの事例が残っている
  • 現在とは異なる成果条件の事例が掲載されている

といった状態です。

そのため、実績は数字だけでなく、何を根拠に掲載しているかまで管理します。

管理項目 確認内容
実績数値 集計元と集計期間
顧客名・ロゴ 掲載許可の有無
成果 何を測定した数字か
サービス内容 現在も提供している内容か
更新日 最後に確認した日
責任者 数字・事例を確認できる担当者

Web担当者が過去資料から数字を拾って更新するのではなく、元データを持つ担当者から確定情報を受け取る形にします。

制作会社を使う場合も情報責任まで外注しない

Webサイトの更新を制作会社へ依頼している場合でも、「公開作業」と「情報の正しさ」は分けて考えます。

制作会社が担当できるのは、たとえば次の範囲です。

  • CMSへの反映
  • レイアウト調整
  • 表や画像の修正
  • 公開前の表示確認
  • 更新履歴の記録

一方、料金が正しいか、契約条件が現在の社内ルールと一致しているか、実績数字が最新かどうかは、原則としてその情報を持つ社内担当者が確認できる状態にします。

外注先へ「最新情報にしておいてください」とだけ依頼しても、制作会社側は社内の変更を知ることができません。

制作会社への依頼書にも、

元情報 → 承認済み情報 → Web反映 → 公開確認

という順序を明確にすると、責任範囲を切り分けやすくなります。

更新漏れを防ぐ管理表は1枚から始める

大規模な管理システムを最初から導入する必要はありません。

まずは主要なサービス情報だけを一覧にします。

情報項目 原本部署 変更通知 承認者 Web反映 更新期限 最終確認日
基本料金 事業部 事業責任者 営業責任者 Web担当 適用開始前 YYYY/MM/DD
契約期間 事業部 事業責任者 法務 Web担当 変更適用前 YYYY/MM/DD
導入実績 営業 営業担当 営業責任者 Web担当 月次 YYYY/MM/DD
導入事例 営業 顧客担当 顧客・広報 制作会社 随時 YYYY/MM/DD
対応範囲 事業部 事業担当 事業責任者 Web担当 変更時 YYYY/MM/DD

ポイントは、「Web担当」という列だけを作らないことです。

誰が正しい情報を持っているか、誰が変更を知らせるか、誰が承認するかまで1枚で確認できるようにします。

自社サイトで最初に確認する5項目

運用体制を作り直す場合は、主要サービスページを開き、次の5点から確認すると始めやすくなります。

  1. この情報の正式な元データはどこにあるか
  2. 内容が変わったとき最初に知る部署はどこか
  3. Web掲載内容を承認できる人は誰か
  4. 誰がサイトへ反映するか
  5. 変更から何日以内に更新するか

特に料金・実績・契約条件から始めると、複数部署にまたがる情報管理上の抜けを見つけやすくなります。

その後、対応地域、サービス仕様、導入フロー、よくある質問などへ対象を広げます。

まとめ

法人向けサービスサイトの情報を最新に保つために必要なのは、Web担当者へ責任を集中させることではありません。

料金・実績・契約条件などの情報ごとに、

原本を持つ部署 → 変更を知らせる人 → 承認者 → Web反映担当 → 更新期限

を決めることが重要です。

社内では新しい情報へ変わっているのに、Webサイトだけ古いという状態は、公開作業だけを改善しても解決しません。変更が発生した時点からWeb更新へつながる流れを作る必要があります。

まずは主要なサービス情報を一覧にし、「情報項目×原本部署×承認者×更新期限」を整理してみてください。

参考文献・データ元

この記事で参照した情報を確認できます。

‹ 親記事: コンテンツ制作・運用体制とは?編集フロー・役割分担・品質チェックの仕組みを体系的に整理

関連記事

関連テーマ