受託開発が単発で終わる原因｜既存顧客から追加発注につなげる方法

受託開発の追加発注は納品後の確認と相談機会から作る

追加発注が生まれるのは、開発会社が次の商品を説明したときではなく、顧客が稼働後の事実から次の課題を認識したときです。納品、検収、請求で案件管理を閉じても、顧客の業務はそこから続きます。

納品物ではなく稼働後の業務変化を見る

仕様どおりに動くことと、顧客の業務が良くなることは同じではありません。実際に使い始めると、入力の重複、利用部門の追加、例外処理、周辺システムとの連携不足などが見えてきます。

確認する対象は「追加したい機能」だけではありません。当初の目的、利用状況、減った作業、残る手作業、利用者から出た困りごとを順に聞きます。成果が出ていなければ、追加販売より先に現在の導入範囲を見直します。

次の提案より先に次の確認を約束する

納品時に「何かあればご連絡ください」と伝えるだけでは、顧客側で相談のきっかけが生まれません。稼働後に確認する目的と時期を決め、誰が参加するかまで合意します。

次回の目的は商談ではなく、利用状況と未解決課題の確認です。提案するかどうかは、その場で必要性と優先度を確かめてから判断します。

受託開発が単発で終わる原因を四つに分ける

単発終了を「営業力が弱い」で片付けると、必要のない連絡量だけが増えます。この記事では、原因を次の四つに分けます。

契約の終了と顧客課題の解消を同じにしている

開発会社にとっては納品が一区切りでも、顧客にとっては新しい運用の開始です。検収条件を満たした時点で、当初の業務課題まで解消したと決めつけると、改善余地を確認できません。

まず、受注時に置いた目的が稼働後にどう変わったかを確認します。期待どおりなら、その成果を維持する運用が次の論点です。期待との差があるなら、操作定着、データ、業務手順、開発範囲のどこに原因があるかを分けます。

相談窓口と有償範囲が分からない

顧客が「この相談は契約内か」「聞くだけで費用がかかるか」を判断できないと、小さな違和感を抱えたまま別会社へ相談することがあります。問い合わせ窓口、回答までの流れ、保守で扱う範囲、別見積もりになる条件を平易に示します。

開発会社側も、好意で続けた無償対応を後から追加発注に変えようとすると説明が難しくなります。境界は新しい要望が出てからではなく、納品時と定期確認のたびに共有します。

納品後に顧客成果と変化を確認する

確認の目的は、追加要望を集めることではありません。顧客の目的に照らし、今の仕組みで解決できていることと、次に判断すべきことを分けることです。

当初目的と稼働後の事実を比べる

「使えていますか」では、担当者が答えにくくなります。次の順で具体的な事実を聞きます。

• 当初減らしたかった作業やミスはどう変わったか
• 実際に使っている部門と使っていない部門はどこか
• 現在も表計算や手作業で補っている工程は何か
• 問い合わせや例外対応が増えた箇所はあるか
• 次の事業計画や制度変更で影響を受ける業務はあるか

成果が確認できない場合は、すぐ追加機能へ進みません。操作方法、運用ルール、データ品質、当初設計のどこを先に直すべきかを決めます。

確認内容は、次のひな型へまとめると次回の判断に引き継げます。

対象システム・確認日：
当初の目的：
稼働後に変わった事実：
残っている手作業・例外：
利用部門から出た要望：
優先度とその理由：
不具合・運用支援・追加開発の区分：
次回確認日・参加者：

残る手作業と新しい制約を聞く

追加開発の候補は「欲しい機能」ではなく、現在の業務を止めている制約から探します。残業が続く工程、二重入力、特定担当者しか判断できない例外、他部門への受け渡しなど、困る場面と影響を確認します。

同時に優先度も聞きます。困りごとがあっても、発生頻度が低い、回避策がある、他施策が先なら、提案しない方が顧客にとって適切です。

既存顧客との定例会を報告だけで終わらせず、成果・変化・次の行動を確認する進め方も、納品後の確認機会を設計する際に参考になります。

無償対応と有償の追加開発・保守を分ける

有償か無償かは、作業時間の長さだけでは決めません。当初合意した仕様・品質・保守範囲と、今回求められている結果を照らして判断します。

当初合意との一致で不具合か追加要望かを分ける

当初合意した動作を満たさないなら、まず不具合や未完了の可能性を確認します。一方、利用部門の追加、新しい業務への対応、外部サービスとの連携、仕様にない自動化などは、新しい要望として目的と範囲を整理します。

実際の責任や費用負担は個別契約によって変わります。曖昧な場合は営業判断だけで断定せず、契約文書と事実を確認し、必要に応じて専門家へ相談します。

見積もり前に目的と優先度を確認する

要望を聞いてすぐ見積もると、顧客が本当に解きたい課題と開発範囲がずれることがあります。誰が、どの場面で、何に困り、放置すると何が起きるかを確認します。

そのうえで、設定変更、運用改善、保守内対応、追加開発の選択肢を比較します。開発しない方法で十分なら、その判断を先に示す方が長期的な信頼につながります。

売り込みにしないフォローを設計する

フォローは「追加案件はありませんか」と尋ねる活動ではありません。顧客側で状況が変わる時点に合わせ、判断に役立つ確認を行う活動です。

顧客側の出来事を次回確認の起点にする

連絡時期は、開発会社の売上都合ではなく、顧客側の出来事と結び付けます。利用開始後の振り返り、契約更新、繁忙期の前後、利用部門の拡大、制度や業務変更などです。

連絡時には、前回確認した目的と未解決事項を一つ示します。「その後どうですか」だけでなく、何を確かめたいかを明示すると、顧客も準備しやすくなります。

提案しない判断も記録する

確認した課題ごとに、今提案する、顧客側で対応する、時期を待つ、対応しないを分けます。時期を待つ場合は、再確認の条件を残します。

追加提案が適切な場合も、上位契約や別サービスありきで決めません。アップセルとクロスセルの違いを顧客課題から判断する方法を使い、同じ成果を広げる提案か、隣接課題を解く提案かを分けると、押し売りを避けやすくなります。

単発受注を減らす第一歩は、提案数を増やすことではありません。納品後も顧客の成果と変化を確認できる関係を作り、必要な課題だけを次の判断へ進めることです。