コラム

顧客のホームページが公開され、制作の打合せは終了した。しかし、顧客から届いた修正依頼を誰が整理するか、フォームの不調をどこへ連絡するか、改善提案をいつ再開するかが決まっていない。制作をパートナーへ委託するマーケターには、公開を境に仕事の受け渡しが途切れる場面があります。

公開後へ引き継ぐのは、ログイン情報や操作説明だけではありません。制作中に残った判断、保守の連絡経路、改善提案の承認、最初に運用状況を確かめる日までつなげます。大阪で協業先を探す場合にも使える、地域に共通する整理方法です。ここではマーケター・制作担当・顧客の三者で、一案件を制作から継続支援へ移す手順を説明します。

公開の完了と、運用の受け渡しを別に確認する

公開できたことと、公開後の担当者が仕事を引き受けたことは同じではありません。制作担当が納品資料を送り、マーケターが受け取っていても、顧客が次の相談先を知らなければ受け渡しは途中です。公開時には、誰に何を渡し、受け手がどこまで確認したかを記録します。

最初に、制作中の課題一覧を見直します。公開前に解決すべき不具合、顧客と合意して公開後へ回した修正、新しく提案する改善を分けます。公開に支障がある問題を、担当が決まらないまま「運用で対応」と書き換えることは避けます。残す場合は、現状、影響、扱いを決めた人、次の担当を明らかにします。

例えば、顧客の原稿待ちで保留した紹介文と、公開後の利用状況を見て検討する導線変更では、次に必要な行動が違います。前者は原稿を誰がいつ確認するか、後者は何を観察して提案するかを引き継ぎます。一括して「改善予定」にすると、制作側もマーケター側も相手が動くのを待つ状態になります。

引継ぎの対象期間も確認します。制作中の窓口をいつまで使い、いつから保守の窓口へ連絡するのか。顧客向けの案内、社内の担当表、協業先との認識をそろえます。公開日から自動的に新しい契約範囲へ移るとは限らないため、開始日が未確定なら決める担当と確認日を残します。

顧客への案内は、協業先同士の内部表とは別に用意します。顧客が知りたいのは、何か起きたときにどこへ連絡し、どの情報を伝えればよいかです。担当者名が並ぶだけの資料ではなく、通常の文章更新、表示や操作の不調、新しい施策の相談など、顧客が使う言葉で連絡の例を示します。内部の調査分担まで顧客に選ばせる必要はありません。

運用資料を置く場所は、三者が役割に応じて参照できるようにします。メール添付にしかない承認記録や、制作担当だけが持つ残件表があれば、必要な情報を共通の記録へ移します。ただし、認証情報をその表へ直接書き込むのではなく、情報の受け渡し方法と管理担当を記載します。

資料を送った後は、受け手が開けるか、担当範囲を理解したか、足りない情報があるかを確認します。送信済みという記録だけを、引継ぎ完了の根拠にしないようにします。

保守連絡と改善提案を、同じ「相談」にまとめない

顧客からの「サイトを見てほしい」には、表示がおかしいという連絡と、もっと問い合わせにつなげたいという相談が混ざります。入口を必ず二つ作る必要はありませんが、受け取った後に誰が確認し、どの経路へ回すかは分けておきます。

保守の連絡では、発生している症状、対象ページ、気付いた時点、確認済みのことを技術担当へ渡します。マーケターが原因を特定してから連絡する運用にすると、原因不明のまま止まる可能性があります。分かる範囲で受け取り、調査する担当へつなぐ役割を決めます。

改善提案では、顧客の事業上の希望、現在の課題、変更の狙いをマーケターが整理し、制作担当が実装範囲や確認方法を検討します。制作側の作業見積が出ただけでは、顧客がその改善を採用したことにはなりません。優先順位と予算を判断する顧客側の担当へ戻す経路が必要です。

二つの経路が重なる場合もあります。フォームの送信不調を調べる中で、入力項目の見直し案が出た場合などです。不調の確認と、新しい構成への変更を別の項目にし、どこまでが今回の対応かを明らかにします。原因調査の依頼に、新しい施策の実施承認まで含まれているとは扱いません。

連絡を受けたこと、調査に着手したこと、復旧を確認したことも区別します。受付時間や返答の目安、担当者不在時の連絡先は、実際の協業条件に合わせて決めます。顧客への返信担当を一人定める場合も、技術担当へ直接確認できる条件や、共有する記録を併せておくと伝言の往復を減らせます。

三者の分担は、依頼・判断・実施・報告まで書く

次の表は、架空の協業案件Pが公開時に分担を整理する例です。マーケター、制作担当、顧客という呼び名だけで役割を固定せず、実際に契約している仕事と承認権限に合わせて調整します。みやあじよの標準契約条件や、必ずこの分担になるという案内ではありません。

公開時に渡す項目	マーケターがつなぐこと	制作担当が確認すること	顧客と決めること
制作中の残件	背景と合意内容を整理	未実施箇所と影響を確認	担当と次の確認日
保守の連絡	顧客への案内と状況共有	受付先と調査の範囲	連絡方法と判断担当
改善候補	目的と優先理由を説明	作業範囲と検証方法を整理	採否・予算・実施時期
管理と計測	必要な閲覧・分析を確認	技術管理と設定の担当を確認	権限の管理者と承認範囲
初回の運用確認	議題と顧客の判断事項を準備	保守記録と残件を共有	参加者と次に決めること

担当欄には会社名だけでなく、役割や連絡先、代わりに確認できる人を必要に応じて記録します。「顧客が承認」と書いていても、日常の窓口と予算を決める人が違う場合があります。何を誰が決められるかを確認し、返信が来ればすべて承認されたと扱わないようにします。

顧客から制作担当へ直接依頼が届く場合の扱いも決めます。直接連絡を禁止するかどうかより、その依頼がマーケターの提案内容や他の作業に影響するかを共有できることが重要です。実施を確約する前に、既存の範囲に含むか、追加判断が必要かを確認します。

報告の担当まで置くと、作業後の受け渡しが明確になります。制作担当が変更を完了したら、確認した画面や残る制約を共有し、マーケターは顧客へ事業上の説明が必要かを確かめます。誰かの「対応しました」だけで終えず、顧客へ何を伝え、次の確認へ何を残すかまでつなげます。

引継ぎ表の空欄は、担当者を推測して埋めず、決めるための項目として扱います。例えば改善提案の費用が未合意なら、「制作担当が見積条件を整理し、マーケターが顧客の判断者へ確認する」と次の行動を記録します。未合意の仕事を実施担当へ渡すことと、合意に必要な情報を集める担当を決めることを分けます。

操作できる権限と、変更してよい範囲を分ける

引継ぎ資料に管理画面の一覧があっても、必要な人が必要な情報を見られるとは限りません。担当者名、対象のサイトや計測先、閲覧だけか設定変更も必要かを確認します。別の顧客のデータまで見える状態や、以前の制作担当しか権限を管理できない状態が残っていないかも確認対象です。

Google アナリティクスは、アカウントとプロパティの単位で役割を管理し、上位で与えられた権限が下位へ継承される仕組みを説明しています。担当表に「解析を担当」と書くだけでなく、どの範囲へどの役割でアクセスするかを確かめる参考になります。Googleのアクセス権とデータ制限の説明

ただし、管理画面で変更できることと、顧客から施策の実施を任されていることは別です。分析に必要な権限を付与されたからといって、目標の定義や計測設定を独自に変えてよいとは限りません。技術的な権限と、案件内の承認ルールを別々に記録します。

保守では、通知が誰に届くかも引き継ぎます。WordPress公式の自動更新の説明では、テーマ・プラグインごとの設定、更新試行後の通知、問題時に元へ戻せる状態の確認を扱っています。自動更新を設定しただけで担当が不要になるわけではなく、設定と通知と確認役を対応させておく必要があります。WordPressの自動更新の説明

案件の引継ぎでは、自動か手動かという設定、通知の受け手、確認する範囲、不具合時に相談する先を制作担当にまとめてもらいます。この記事はすべての自動更新を推奨するものではありません。利用環境や支援範囲に合わせた判断を、公開後の担当者が追える状態にすることが目的です。

初回の運用確認には、数字より先に受け渡しの状態を持ち込む

公開後の最初の打合せを「アクセス数を報告する会」にすると、引き継げていない仕事が見えないままになります。初回は、顧客が連絡先を理解しているか、残件が担当へ渡ったか、必要な資料を見られるか、保守の通知を受け取れるかを確認します。

マーケターは、公開前に話していた改善候補をそのまま実施予定へ移すのではなく、今も必要かを顧客へ確かめます。制作担当は、公開後に分かった技術的な条件や、実施すると影響する箇所を共有します。その情報を合わせて、次に提案するものと保留するものを決めます。

計測の数字を使う場合は、どの期間から、何を同じ定義で見られるかも確認します。公開直後にデータが少ないことと、計測ができていないことは別です。判断材料が足りないなら、成果の良し悪しを急いで決めず、何を確認し、いつ再び見るかを残します。

打合せの終わりには、次の担当、必要な承認、確認する日を更新します。「改善を検討する」で終わるのではなく、例えば目的の確認、実装範囲の整理、顧客の採否判断のどこまで進んだかを示します。制作中の課題表から運用の記録へ移した項目には、元の資料へ戻れる参照先も残します。

三者全員が毎回同じ会議へ出る必要があるとは限りません。技術的な確認が必要な議題だけ制作担当に参加してもらう方法もあります。ただし、不参加の人が後で確認する内容と、誰が決定事項を伝えるかは決めます。会議の出席と、担当としての受け取りを同じものにしないことが要点です。

初回までに不調の連絡が入った場合は、定例の日を待つ扱いなのかを曖昧にしません。合意した連絡方法で保守担当へ渡し、対応した内容を後から定例の記録へ合流させます。逆に、急ぎでない改善候補まで不調対応の連絡へ混ぜると、確認の優先順位が伝わりにくくなります。急ぐ理由と通常の検討事項を分けて共有しましょう。

協業先へは、残件と最初の判断事項をセットで渡す

制作後の支援を相談するときは、「公開後もお願いします」だけでなく、顧客の窓口、保守で確認したい範囲、改善候補、未決定の項目を示します。現状の資料を見ながら、マーケターが継続して担うことと、制作パートナーへ相談したいことを分けると話を進めやすくなります。

みやあじよのWebトータルパートナーでは、顧客を交えた打合せ、制作、納品後の運用サポートを案内しています。実際に任せる範囲、受付方法、レビューの進め方は案件ごとに確認します。常時対応や無制限の改修を前提にせず、自分たちの引継ぎ表で未確定の項目を相談材料にしてください。

まずは公開予定の一案件で、残件を誰が受け取り、保守の連絡を誰へ渡し、改善案を誰が承認するかを一枚にまとめます。そこへ初回の確認日と議題を加えると、制作の完了から継続支援の開始までを具体的につなげられます。

参照資料：Googleのアクセス権とデータ制限の説明、WordPressの自動更新の説明。2026年9月21日確認。管理権限の範囲、通知や復旧準備の確認を参照し、契約上の承認・常時対応・成果を保証するものではありません。