追加費用は、ページ数が増えたときだけでなく、原稿支援や機能追加、承認後の変更でも発生することがあります。大切なのは、当初の範囲と追加の境界を共有し、金額と予定への影響を確認してから着手することです。
追加になりやすい依頼の例
| 変更内容 | 作業が増える理由 | 先に確認すること |
|---|---|---|
| 事例ページを追加 | 入力だけでなく専用の設計が必要な場合がある | 既存の型が使えるか |
| 原稿作成を依頼 | 支給予定の原稿を取材・執筆する | 対象ページと確認回数 |
| デザインの方向を変更 | 確定済みの画面と実装を戻す | 変更範囲と工程への影響 |
| 予約・会員機能を追加 | 機能調査、連携、試験が必要になる | 外部サービス利用料も含むか |
| 旧記事の移行件数が増加 | 本文・画像・リンクの確認が増える | 件数と手作業の範囲 |
| 公開後に文章を変更 | 制作完了後の新しい作業になる場合がある | 保守範囲か個別見積もりか |
不具合対応と要望変更は分けて確認
決めた仕様と違う動作の修正と、決めた仕様を後から変える依頼は同じではありません。例えば、合意済みの通知メールが届かない問題と、通知先の自動振り分けを新設する要望では、確認すべき範囲が違います。
費用負担を名称だけで決めず、契約内容、合意した仕様、発生原因を確認します。「公開後だからすべて有料」「修正だからすべて無料」と一律に考えないことが大切です。
変更を依頼するときの記録例
「対象:料金ページ。変更:新しいプランを一つ追加。理由:サービス追加。希望日:○月○日。確認事項:追加費用、既存レイアウトへの影響、公開日に影響するか。」
制作側から回答を受けたら、実施する内容と費用、期限を双方で確認します。未確定の変更は元の制作範囲と混ぜずに管理すると、最終請求での認識違いを減らせます。
公開日が迫っているときの変更判断
変更依頼は、公開に不可欠な事実修正、運用上必要な変更、公開後でも対応できる希望に分けます。料金の誤りと装飾の追加を同じ優先順位で依頼すると、重要な修正が遅れる可能性があります。
公開を優先して一部を後回しにする場合は、残件と対応時期、費用を記録します。「公開後に対応します」だけでは、制作費に含むのか、新しい見積もりになるのか分かりません。先送りする項目も、条件を確認したうえで決めます。
発注側で防ぎやすい手戻り
社内の決裁者に構成段階から確認してもらい、各部署の意見は窓口でまとめます。原稿支給なら用意できるかを早めに判断し、難しい場合は着手前に相談します。
見積もりに「別途」とある項目を一覧にし、公開に必須か、希望があるときだけ必要かを確認しましょう。追加費用を一切なくすことより、何を追加するといくら変わるかが分かる状態を作ることが重要です。