機能要望にどう返信する？検討中・見送り・代替案の文例

顧客から機能要望が届いても、実装するか決まっていないと返信が止まることがあります。「検討します」と返したあと、何を伝えればよいか迷う場面もあるかもしれません。

返答に必要なのは、いま何が決まっていて、次に何をするかです。この記事では、受付・追加確認・保留・見送り・代替案の文例を用意します。要望を採用する基準や社内の判断方法は営業・CSからの機能要望をどう扱うかに譲り、ここでは顧客へ返す文章に絞ります。

返信する前に、いまの状態を確かめる

まず、要望を記録した担当者と、採否を判断する担当者の間で状況をそろえます。台帳に載っただけの要望を「開発チームで検討中」とは書けません。社内で確認していない予定を、担当者の見込みで顧客へ伝えることも避けてください。

受付と実装の決定は別の段階です。たとえばAtlassianの新機能方針では、要望に加え、調査結果や製品の方向性などを合わせて実装を判断すると説明しています。これは同社の方針であり、以下の文例が同社の返信文や業界共通ルールという意味ではありません。

以下はすべて、架空の業務ツールへの「週次レポートを自動送信したい」という要望を使った文例です。アーコレや実在する顧客の機能・対応実績ではありません。【 】は送信前に事実に合わせて置き換える欄です。不要な文は削り、記入できない予定を想像で補わないでください。

受付では、記録した内容と次の連絡を伝える

まだ採否を判断していないときは、受け取ったことを返します。顧客が依頼した内容を短く言い直すと、認識のずれも確かめられます。「貴重なご意見ありがとうございます」だけで終えず、何を記録したかを添えてください。

ご要望をお寄せいただき、ありがとうございます。

「週次レポートを自動送信したい」というご要望を記録しました。現在は受付の段階で、実装の可否・時期は決まっていません。

担当の【氏名】が内容を確認し、【次回連絡日】までに確認状況をご連絡します。

この文例は、内容を確認する担当者と連絡日を決めた場合に使えます。期限までに判断が出なくても、確認できたことと残っていることは連絡できます。個別に追跡する運用がない場合はこの約束を付けず、「個別の進捗連絡は行っていません。公開が決まった変更は【実際の案内先】でお知らせします」のように、実際の窓口を案内します。

追加確認では、質問の目的と答えてほしい範囲を添える

解決したい作業が分からない場合は、採否の話より先に背景を尋ねます。すでに聞いた内容をもう一度質問しないよう、問い合わせ履歴を読んでから送ってください。

ご要望の背景を確認させてください。レポートの作成から共有まで、どの部分に手間がかかっているかを把握したいと考えています。

直近でレポートを共有した際、誰に、どのような手順で送ったか教えていただけますか。途中で困った点も、分かる範囲でお知らせください。

レポート本体や個人情報の送付は不要です。文章での説明が難しければ、確認方法をご相談できます。

質問は、次の判断に使うものへ絞ります。「詳しく教えてください」だけでは、顧客が何を答えるべきか分かりません。一方、回答がないことだけを理由に「困っていない」と判断することもできません。追加で聞くか、情報不足のまま保留にするかは、社内で決めて記録します。

保留では、判断が止まっている理由を具体的に書く

「検討中」は、受け付けた直後にも、調査が進んでいる段階にも使えてしまう言葉です。何を調べていて、何が未定なのかを添えます。すでに見送った要望には、この文例を使いません。

ご要望について、現時点では採用・見送りの判断を保留しています。

現在は【確認中の内容】を調べており、【判断に必要だが未確認の点】が残っています。実装の可否・時期は未定です。

【担当者】から【次回連絡日】までに状況をお伝えします。判断に至っていない場合も、確認できた内容と残る課題をご連絡します。

【確認中の内容】には、実際に進めている「送信先の権限をどのように扱うか」などを書きます。「優先順位を調整中」と書くなら、誰がいつ見直すかを担当者が説明できる状態にしておきます。

見送りでは、決まった範囲と理由を伝える

採用しないと決めたら、その結果を明記します。「難しいかもしれません」とぼかすと、まだ判断を待つべきなのか分かりません。今期の計画に入れない判断と、今後も提供しない方針は区別します。

ご要望を確認した結果、【判断の対象期間・範囲】では実装を見送ることになりました。

理由は【顧客に説明できる、確認済みの判断理由】です。レポート共有の負担については把握していますが、今回はご希望の方法での対応を予定していません。

この要望の再検討時期は、現時点では決まっていません。業務の条件に変化があれば、【連絡先】へお知らせください。

理由欄は、社内の判断を顧客に伝わる言葉へ直します。「優先度が低い」の一言ではなく、たとえば実際の判断がそうであれば「今期はレポートの作成・閲覧機能を対象とし、自動送信は開発範囲に含めないため」と説明できます。

再検討の条件や予定が決まっている場合は、最後の段落をその内容に置き換えます。決まっていなければ、安心してもらうためだけに「将来は対応します」と書くことはできません。他社名、売上額、内部の評価メモをそのまま理由として転記する必要もありません。

代替案では、できることと残る手間を並べる

既存機能や運用で一部を補える場合は、顧客の環境で使えるかを確認してから案内します。代替案があることと、元の困りごとが解決したことは別です。

自動送信については【現在の判断状況】です。代わりに、【利用環境で確認した手順】で【達成できること】は可能です。

ただし、【手動で必要になる作業・制約】は残ります。自動送信と同じ方法ではありません。

この方法が今回の業務に合うか、ご確認いただけますか。合わない場合は、どの部分が難しいか教えていただけると、追加の確認に役立ちます。

たとえば、架空の製品でファイル出力が使えることを確認したなら、「ファイルを出力してメールに添付できますが、作成と送信の操作は毎回必要です」と書けます。契約プラン、権限、追加費用などの条件があるなら、手順と一緒に伝えます。未確認の機能や回避策を「できます」と紹介しないでください。

顧客が代替案を使わなかった場合も、すぐに要望を取り下げ扱いにはしません。手間や制約が受け入れられない可能性があるため、確認できた理由を元の要望へ追記します。

送信した内容を、次に返信する担当者へ残す

送る前に、実際の判断と文例の状態が一致するか、約束した連絡を誰が行うかを確認します。不具合や業務停止が疑われる連絡を、通常の改善要望として保留しないことも必要です。迷う場合は不具合と要望の切り分けを参照し、影響の確認を先に進めます。

送信後は、返信文、送信日、次の担当者、連絡予定日または連絡しない方針を、元の要望と一緒に残します。別の担当者が対応しても、同じ質問や違う約束を重ねずに済む記録にします。

要望への返信は、受け取った内容、現在の判断、次の連絡を具体的にするところから始められます。実装の約束は未定のままでも、いま伝えられる事実はあります。記録や担当の決め方を整えるときは、機能要望管理の基本も合わせて確認してください。