解約理由をサービス改善につなげるには？

解約理由に「料金が高い」と書かれていた。だから値下げすればよいのかというと、その一言だけでは判断できません。予算が変わったのか、使う機会がなかったのか、期待した仕事を終えられなかったのかで、考える改善は変わります。

この記事では、解約理由を利用中の出来事と照らし合わせ、次に確かめる改善候補へまとめる方法を紹介します。解約を引き止める話術や、解約率の計算ではなく、理由の読み方と改善への渡し方を扱います。

「解約した」と「理由が分かった」を分ける

最初に、どの状態を振り返るかを決めます。解約を申し込んだ段階と、契約期間が終わった段階は同じではありません。一時停止やプラン変更も混ぜず、対象期間と集計の単位をそろえます。

また、利用者が解約を選んだ場合と、支払いの失敗に伴う契約終了を分けて確認します。Stripeの決済回復に関する公式資料でも、支払い失敗による意図しない離脱を扱っています。契約が終了したという事実だけで、サービスへの不満が原因だとは言えません。

理由を取得できたかどうかも、契約状態とは別の情報です。回答がない場合は「理由不明」と残し、「不満がなかった」「価格の問題だろう」などと埋めないようにします。

分析対象を決めたら、解約した契約の一覧と、理由を確認できた契約の一覧を見比べます。回答のある人だけを読んでいることが分かる状態にしておくと、全体の傾向と言い切るのを避けられます。

選択肢の回答を、調べる入口にする

解約フォームの選択肢は、理由を一覧にする入口として使えます。Stripeの解約理由収集の説明にも、料金、機能、代替サービス、利用の必要性などの選択肢と、その他の自由記述が示されています。

ただし、選択肢は短い言葉にまとめられています。「機能が足りない」という回答だけでは、何をしようとしていたか、代わりの方法を試したか、その機能が解約の決め手だったかまでは分かりません。

本記事では、一件ごとに次の情報をつなげて読む方法をおすすめします。すべて聞き直すのではなく、すでにある記録から確認できる部分を先に埋めます。

• 利用の目的：何の仕事や課題のために導入したか。
• 利用中の出来事：どの作業で困り、どう対処していたか。
• 解約の経緯：いつ見直し始め、何をきっかけに決めたか。
• 解約後の選択：別サービス、手作業、業務自体の終了など、分かる範囲の状況。
• 情報の出どころ：本人の回答、問い合わせ記録、担当者の推測のどれか。

社内向けの共有では、検討に不要な氏名や個人情報を広げず、必要な人だけが元の記録を確認できるようにします。改善の論点と、個別の契約手続きも分けて扱ってください。

追加で聞くなら、実際の出来事を尋ねる

追加の確認は、相手が応じられる場合に、目的と負担を伝えて行います。解約手続きを進めることと、調査に協力してもらうことを混ぜず、答えたくない項目は飛ばせる形にします。

「安ければ続けましたか」だけでは、実際に起きたことが見えません。先に、解約を考え始めた場面や、最後に使おうとした仕事を尋ねます。

• 「利用を見直し始めたのは、どのようなことがあったときですか」
• 「最後にこのサービスで終えようとした作業を教えていただけますか」
• 「その作業で困ったあと、どのように対応しましたか」
• 「最終的に利用をやめる判断をしたとき、重視したことは何でしたか」

GOV.UKのインタビューのガイドも、中立的な質問を使い、一般論より実際の出来事を聞くことを勧めています。基本的な聞き方はユーザーインタビューの記事で確認できます。ここでは、解約までの順序が分かるように記録するのがポイントです。

値下げや新機能の提案を途中で始めると、何が起きたかを聞く時間と、今後の条件を相談する時間が混ざります。改善調査として聞いた内容と、その後の営業上の相談は記録も分けます。

架空例で「料金が高い」の背景を整理する

以下は、架空の案件管理サービスを使った説明用の例です。実際の顧客事例や、解約防止の実績ではありません。

ある契約の解約理由は「料金が高い」でした。利用目的と経緯を確認すると、担当者は案件の集計資料を作るために導入していました。しかし、必要な区分で集計する手順が分からず、表計算ソフトでの作業を続けていたと回答しました。その後、予算の見直しがあり、契約を終了したとのことでした。

この記録は、次のように整理できます。

「集計機能を作れば解約しなかった」とはまだ言えません。使い方の案内で対応できた可能性も、料金や予算の制約が残った可能性もあります。ここから選ぶのは、解約を取り戻せるという約束ではなく、確認する課題です。

まず既存機能と案内を確認し、同じ用途の利用者がつまずくかを調べます。その結果に応じて、案内の改善、導入時の支援、機能の検討へ進めます。

似た理由を比べ、変えられることを選ぶ

複数の記録を読むときは、同じ選択肢を選んだ人を一括りにせず、利用期間や目的も見ます。導入直後に作業を始められなかった人と、長く使った後で対象業務がなくなった人では、改善の候補が違います。

件数を示すなら、対象期間、解約した契約数、理由を確認できた契約数を添えます。一つの契約に複数の理由を付けた場合は、その数え方も示してください。少数の回答だけで、顧客全体の主な解約原因を確定しないようにします。

改善候補は、画面や機能に限りません。初期設定の支援、料金の説明、問い合わせへの対応など、自分たちで見直せることを選びます。一方、顧客の事業終了など、サービスを変えても対応できない事情は別に残します。

一件の具体的な困りごとには調べる価値がありますが、それだけで最優先の開発案件にはなりません。対象となる顧客、困る程度、他の記録との共通点をそろえて判断します。

改善後は、解約率だけで判断しない

改善を試す前に、何が変われば前進と考えるかを決めます。架空例なら「目的の集計を自分で終えられるか」が、解約率より先に確かめられる項目です。

その後、対象となる利用者の継続状況も追えます。ただし、料金や契約条件、顧客の構成が同時に変われば、数字の変化を一つの改善だけの効果とは言えません。まず困りごとが解消したかを確認し、長期の変化はほかの条件と一緒に読みます。

記録には、改善候補、担当者、確認日、確認できた結果を残します。効果を確かめる流れは、機能改善の効果を確かめる方法も参考にしてください。

よくある質問

まとめ

選んだ改善候補を今後の計画へつなげるときは、プロダクトロードマップの作り方も参考になります。

解約理由は、利用目的と、解約までに起きた出来事を合わせて読むと、次に調べる課題が見えてきます。分からない点を残し、変えられることから小さく試してください。

少数の記録は表でも扱えます。解約時の声に加えて日々の要望も増え、似た困りごとを探す負担が大きくなったら、改善候補をまとめる方法を見直せます。

アーコレ！は、集まった要望を整理し、改善の検討につなげるためのサービスです。解約の原因や効果を自動で確定するものではなく、チームが判断する前の情報整理にどう使えるかを確認できます。

アーコレでどう整理できるかを見る