すべての SaaS に公開チェンジログが必要な理由(そして継続率が上がる仕組み)

SupDesk Team

先の四半期に 40 件の改善をリリースしました。そこへ顧客から「この製品はまだ開発されているんですか」というメールが届きます。

これは珍しい失敗ではありません。何もしなければこうなる、という標準の結果です。ソフトウェアは目に見えない形で良くなります。直したバグは「問題がない状態」でしかなく、追加した機能は誰もたまたま開かなかったメニュー項目でしかありません。何が変わったかを伝えなければ、あなたの製品を使う正直な体験は「何も変わらない」なのです。

チェンジログはその最も安上がりな解決策であり、リリース告知よりずっと多くの仕事をします。

チェンジログが実際にもたらすもの

製品が生きている証拠になる。 あなたを検討している人にとって、今月の更新が並んだ公開チェンジログは、どのみち聞かれるはずだった質問への答えです。ランディングページと証拠の違いがここにあります。

フィードバックのループを閉じる。 6 週間前に要望を出した人は、それが実装されたことを知りません。伝えるその瞬間に、その人は「この会社に話すと結果が出る」と学びます。それが、次もまた話してくれる理由になります。

離れた人を呼び戻す。 製品を使わなくなった人には理由があります。その理由が「ある機能がなかったこと」なら、その機能ができたという一文は、あなたがその人に送る中で最も関連性の高いメッセージです。ニュースレターでも、復帰キャンペーンでもなく、望んでいたものについての一行の事実です。

サポートを減らす。 直近の変更が一覧で見える状態は、「これ壊れました?」「これ新しいですか?」という問い合わせの相当部分を、書かれる前に吸収します。

読まれる項目の書き方

ユーザーが今できることから書く。 「エクスポート処理をリファクタリング」ではなく「エクスポートにアーカイブ済みの項目が含まれるようになり、数分ではなく数秒で完了します」。目的は社内的な正確さではなく、当事者性が伝わることです。読者は 4 語で「これは自分の話か」を判断できるべきです。

すべての項目にラベルを。 3 種類で足ります。存在しなかったものに 新規、良くなったものに 改善、壊れていたものに 修正。読者は自分に関係するラベルを探して読み飛ばしますし、バグだけを気にする人はバグを見つけられます。

短く、分ける。 1 つの変更につき 1 項目、3 文ずつのほうが、すべてを網羅した月次記事より優れています。短い項目は個別にリンクでき、サポートの返信で引用でき、読み飛ばしても文脈を失いません。

視覚的なものは見せる。 画面が関わるものなら、スクリーンショットや 5 秒の動画は段落より雄弁です。バックエンドの作業では省きましょう。何も写っていない画像は、画像がないより悪いです。

その機能を使ったことがない人に向けて書く。 前提知識をゼロと考えます。画面の名前を書きます。設定が必要なら、どこにあるかを書きます。

気後れしてまとめない。 小さな項目は弱さではありません。先月に地味な 11 件が並ぶチェンジログは「勢い」と読まれます。四半期に 1 本の凝った記事は「四半期ごとにしか出さない会社」と読まれます。

人の目に届ける

誰も見に来ないチェンジログは日記です。価値の大半は配信にあります。

  • メール購読。 登録できるようにして、公開時に送ります。先に自社アプリを開く必要がないため、休眠ユーザーに届く唯一の経路です。
  • RSS。 提供コストは安く、開発者層は今も本当に使っています。
  • 製品内。 ナビゲーションのリンクや、アカウントメニューの控えめなバッジは、まさに試せる瞬間のアクティブユーザーを捕まえます。
  • 要望した本人に個別に知らせる。 最も価値が高いのは一斉配信ではなく、投票した 11 人に「できました」と伝える通知です。

SupDesk はどこに入るか

SupDesk はポータル上にチェンジログ機能を備えています。独自ドメインでの運用も可能です。

  • 新規 / 改善 / 修正のラベル を各項目に。ページが増えても一覧性が保たれます。
  • メール購読と RSS フィード。 項目を公開すると購読者にメールが送られ、配信停止の処理も任せられます。
  • 要望者への自動通知。 チェンジログの項目を、それが解決したフィードバック投稿に紐付ければ、公開時にその投稿へ投票した全員に通知されます。名簿を管理せずにループが閉じます。
  • 機械翻訳。 項目は Cloudflare Workers AI で対応言語に翻訳でき、公開前に自分で確認・修正できます。速度は機械、最終判断は人間です。
  • 配信対象の指定。 全員に公開することも、まだ一般公開でない変更をベータプログラムだけに公開することもできます。

範囲について正直に補足します。項目はあなたが公開した時点で出ます。予約投稿はないので、朝 6 時に出したリリースがチェンジログに載るのはボタンを押したときであって、その前ではありません。

難しいのは習慣のほう

チェンジログの仕組みを整えるのは半日の作業です。リテンションへの効果を生むのは、デプロイのたびに 3 行書く規律であり、まさにそこが最初に途切れます。

リリース後のタスクではなく、リリースの一部にしてください。そうすれば、その変更がなぜ重要だったかを覚えているうちに書けます。そしてそれは、いちばん書きやすいタイミングでもあります。

チェンジログを用意し、最初の購読者を集め、次のリリースに自分で自分を告知させましょう。supdesk.app ではじめる