店舗向けSaaSにおける顧客要望活用の実践アプローチ（20241205_pmconf）

by Yujiro Ichikawa

Slide 1

Slide 1 text

店舗向けSaaSにおける顧客要望活⽤の実践アプローチプロダクトマネージャー市川雄⼆朗

Slide 2

Slide 2 text

2 ⾃⼰紹介株式会社tacoms プロダクトマネージャー市川雄⼆朗 2024年3⽉に株式会社tacomsに⼊社し、モバイルオーダー「Camel Order」のプロダクトマネジメントを代表から引き継ぎ、顧客とユーザーの課題解決に取り組みながら、プロダクトマネジメントのプロセス整備やチームの構築を推進。前職は楽天ラクマ、電通デジタル、IMJ。⼆児の⽗。趣味はお酒とサウナとキックボクシング（超初⼼者）。

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

4 飲⾷業界向けVertical SaaS「Camelシリーズ」の提供デリバリー、テイクアウトサービスからの注⽂⼀元管理 POS/基幹システムへの連携⾃社店舗/ブランドのオリジナルのテイクアウト‧ デリバリー注⽂サイトの⽴ち上げ受け渡し⽇時指定〜商品選択〜決済‧購⼊まで⽀援

Slide 5

Slide 5 text

飲⾷業界のオンライン注⽂‧CRMをマルチプロダクトで⽀える売上データ‧顧客データ‧商品データ‧外部API連携注⽂管理オンライン決済店頭 Kiosk CTI / IVR 対⾯決済デリバリーPF 連携 POS 連携店外モバイルオーダーオープン API 店内モバイルオーダーオンライン注⽂顧客管理セグメント分析サブスク管理メルマガ / SMS プッシュ通知外部 CRM連携クーポン公式アプリ⾃社ポイントハウスカード CRM / マーケティング

Slide 6

Slide 6 text

6 toCとtoBにおける、顧客要望の位置の付け違い toCとtoBでは⼀票の重みが異なる顧客の要望：⽜丼が⾷べたい顧客の課題：すぐにお腹を満たして満⾜したいソリューション：⽜丼、おにぎり、ゼリー飲料、ハンバーグ atoCa ⼀つの要望に惑わされず、本質的な課題を⾒極め最適で全体としてインパクトのあるソリューションを提供すべき atoBa そうは⾔っても、⼤事なお客様の要望は叶えたい

Slide 7

Slide 7 text

7 店舗ビジネスにおける要望の多層性業態（和⾷‧洋⾷‧中華‧スイーツetc.） × 規模（チェーン‧個⼈店） × 運営形態（フランチャイズかどうか） × 利⽤者ユーザーの役割（本部社員‧店⻑‧店舗スタッフ）掛け合わせで視点が無限に増える

Slide 8

Slide 8 text

8 Camelシリーズに集まる顧客要望 1,000件以上

Slide 9

Slide 9 text

9 相反する要望 ○○○は⽬⽴たせてほしい ↑ ↓ ○○○は⽬⽴たせないでほしい特定の業態特有の要望ピザのハーフ&ハーフを選択しやすいUIにしてほしいニーズはあるが売り上げに繋がりにくい要望通知⾳を⾃由に選べるようにしてほしい Camelシリーズに集まる顧客要望

Slide 10

Slide 10 text

10 相反する要望 ○○○は⽬⽴たせてほしい ↑ ↓ ○○○は⽬⽴たせないでほしい特定の業態特有の要望ピザのハーフ&ハーフを選択しやすいUIにしてほしいニーズはあるが売り上げに繋がりにくい要望通知⾳を⾃由に選べるようにしてほしい Camelシリーズに集まる顧客要望

Slide 11

Slide 11 text

11 顧客要望から着想を得た新プロダクト Camel ピアノ⾃分で作曲することもお店の雰囲気に合わせて AIが⾃動で作曲する機能もシチュエーションに合わせて⾳を切り替え ※ウソです。開発の予定はありません。

Slide 12

Slide 12 text

12 ‧‧‧という判断をしてしまわないために、 PdMはどうしたら良いか？

Slide 13

Slide 13 text

13 店舗向けSaaSの顧客要望活⽤における課題 ①本部（飲⾷店企業本社など）と店舗どちらから実装すべきか？ ③重要顧客、かつ特定業態や企業特有の要望の扱いは？ ②toB要望とtoC要望どちらを優先すべきか？

Slide 14

Slide 14 text

14 皆さんならどうするか⼀緒に考えながら聞いてもらえるとうれしいです！

Slide 15

Slide 15 text

① 本部（飲⾷店企業本社など）と店舗どちらから実装すべきか？ 15

Slide 16

Slide 16 text

16 （前提の説明）本部と店舗本部（飲⾷店企業本社など）店舗店舗店舗店舗店舗メニュー作成や設計、販売促進、全体の売上げ管理など調理や受け渡しなどの実際の店舗業務

Slide 17

Slide 17 text

17 （前提の説明）Camelシリーズにおける管理画⾯本部（飲⾷店企業本社など）店舗管理画⾯的な役割が⼆つ存在するダッシュボード（全体の管理）注⽂受注画⾯タブレット設定ユーザー注⽂サイト各種デリバリープラットフォーム（UberEats等）

Slide 18

Slide 18 text

18 本部と店舗の要望の性質の違い⾃由本部（飲⾷店企業本社など）店舗個別即時管理⼀括予定本部と店舗では求められる機能の性質が異なる

Slide 19

Slide 19 text

19 本部と店舗どちらでも設定できるのがベターな場合もあるかもしれないが、最初から⼆つ開発するのは避けたい ※開発したいものは他にもある、メンテナンス性が下がるなど理由は⾊々‧‧‧

Slide 20

Slide 20 text

20 ①本部を優先するケース（例：店舗の休業⽇設定）本部（飲⾷店企業本社など）店舗ダッシュボード（全体の管理）注⽂受注画⾯タブレット設定ユーザー注⽂サイト各種デリバリープラットフォーム（UberEats等）年末年始は全店舗⼀括で休業⽇を設定したい

Slide 21

Slide 21 text

21 ②店舗を優先するケース（例：プリンタ設定）本部（飲⾷店企業本社など）店舗ダッシュボード（全体の管理）注⽂受注画⾯タブレット設定ユーザー注⽂サイト各種デリバリープラットフォーム（UberEats等）印刷されるレシートの設定を変えたい

Slide 22

Slide 22 text

22 ③迷ったケース（例：配達員への固定メッセージ）本部（飲⾷店企業本社など）店舗ダッシュボード（全体の管理）注⽂受注画⾯タブレット設定ユーザー注⽂サイト各種デリバリープラットフォーム（UberEats等）デリバリー配達員へ⼊⼝の場所などの固定メッセージを設定したい

Slide 23

Slide 23 text

23 変更頻度×本部管理重要性（≒⼀次情報の持ち主） ①店舗の休業⽇設定 ③配達員への固定メッセージ ②プリンタ設定管理の重要性が⾼く、頻度が少ないものも本部向けから個別性が⾼く、頻度が多いものは店舗向けから店舗の休業⽇設定企業によっては、各店舗で設定したいという要望も多かったため、店舗向けも開発管理⾼ ≒⼀次情報が本部管理低 ≒⼀次情報が店舗頻度多頻度少

Slide 24

Slide 24 text

24 ①本部（飲⾷店企業本社など）と店舗どちらから実装すべきか？管理の重要性と設定頻度がキーになりそう。企業によって状況が異なるので、リリースした後も要望を継続注視（リリースによって要望が出やすくなる⾯も）。

Slide 25

Slide 25 text

② toB要望とtoC要望どちらを優先すべきか？ 25

Slide 26

Slide 26 text

26 ⾃社店舗/ブランドのオリジナルのテイクアウト‧ デリバリー注⽂サイトの⽴ち上げ受け渡し⽇時指定〜商品選択〜決済‧購⼊まで⽀援 BtoBtoC

Slide 27

Slide 27 text

27 aB to B to Ca tacoms 飲⾷企業（顧客）エンドユーザー会社の直接の顧客は飲⾷店企業

Slide 28

Slide 28 text

28 “結局のところ、あなたがやるべきなのは、要件を満たすことでない、世界を変えることなのだ” ユーザーストーリーマッピング Jeﬀ Patton (著), 川⼝恭伸 (監修), ⻑尾⾼弘 (翻訳)

Slide 29

Slide 29 text

29 tacoms 飲⾷企業（顧客）エンドユーザーエンドユーザーに価値を感じてもらうことが、飲⾷店企業にとっても⼤切 aB to B to Ca

Slide 30

Slide 30 text

30 対⾯がBなので、toB視点の要望が相対的に多くなる。また、toC視点要望は個々ではインパクトも⼩さくなりがち。オペレーション ‧プロモーション関連は要望強い →B視点ではあるが、これらを通してユーザー体験が向上する⾯も⼤きいキラーファンクションになりうる使いやすさなどの UIUX改善 →C視点の要望に近い

Slide 31

Slide 31 text

31 要望を増やす or ⼿数を増やす

Slide 32

Slide 32 text

32 要望を増やす飲⾷店企業がよりエンドユーザーに向き合える⼿助け PdM起点で社内メンバーを巻き込み飲⾷企業にユーザー⾏動をインプットするダッシュボード＋定期的な社内勉強会 CSやセールスがファクトベースの提案ができるように

Slide 33

Slide 33 text

33 ロードマップ検討サイクル顧客要望収集サイクルプロダクト⽅針 Aプロダクトロードマップロードマップアイテムロードマップアイテム Bプロダクトロードマップストーリーストーリーストーリー顧客要望リスト顧客要望プロダクトバックログ開発サイクル顧客要望顧客要望バックログアイテムバックログアイテムバックログアイテムロードマップアイテムと顧客要望をつなげて管理顧客要望⼿数を増やすロードマップアイテムの中で実装する顧客要望の記録

Slide 34

Slide 34 text

34 should nice to have must ⼿数を増やすロードマップアイテムの中で実装する開発が肥⼤化しないように優先度はつける例1 店舗や注⽂⽅式を切り替えやすくするためのナビゲーション例2 注⽂⽅式名を店の呼び名に合わせる（飲⾷店によって異なるため変更可能に）

Slide 35

Slide 35 text

35 ②toB要望とtoC要望どちらを優先すべきか？直接の顧客はBだが、C視点も重要。 C視点を取り⼊れ、ロードマップアイテムと合わせて実⾏できるような仕組みを⽤意することで、BとCどちらにも応えていく。

Slide 36

Slide 36 text

③ 重要顧客、かつ特定業態や企業特有の要望にどう向き合うか？ 36

Slide 37

Slide 37 text

37 例えばこういう要望（モバイルオーダー）ピザのハーフ&ハーフを選択しやすいUIにしてほしい当選者限定のキャンペーン機能（抽選）が欲しい商品に名前を⼊れてカスタマイズしたいマグロの⽇だけ価格を⾃動で変えたいコーヒーのサブスクリプション機能 🍕 ☕ 🍜 麺の種類について細かく説明したい 🍰 🍣 🎁

Slide 38

Slide 38 text

38 例えばこういう要望（モバイルオーダー）ピザのハーフ &ハーフを選択しやすい UIにしてほしい当選者限定のキャンペーン機能（抽選）が欲しい商品に名前を入れてカスタマイズしたいマグロの日だけ価格を自動で変えたいコーヒーのサブスクリプション機能 🍕 ☕ 🍜 麺の種類について細かく説明したい 🍰 🍣 🎁 これら全て⼤⼿飲⾷チェーンの要望ビジネスとしては要望を満たして新規受注やアップセルにつなげたい

Slide 39

Slide 39 text

39 まず、向き合う（気持ち！）

Slide 40

Slide 40 text

40 開発しないで実現できる⽅法を探す既存機能の活⽤実現したいことを把握し、既存機能の活⽤で実現できないか？他社サービスの機能の活⽤先⽅が契約済みのサービスや公開サービスで代替え可能か？内部向けの開発やオペレーションで回避トライアルとして⼯数を1/5くらいにすることはできるか？開発しないで実現する⽅法にも段階がある

Slide 41

Slide 41 text

41 汎⽤性を⼀気に上げるユースケースを10倍にする（この機能で座席番号の指定もできるように）商品に名前を⼊れてカスタマイズしたい（英数字7桁、特定の記号のみ⼊⼒可能にしたい）カスタム注⽂フィールド機能 ‧⾃由な項⽬を作れる ‧任意‧必須の指定 ‧注⽂⽅式（テイクアウト‧デリバリー‧店内飲⾷）の指定 ‧⼊⼒内容のバリデーションを正規表現でできる

Slide 42

Slide 42 text

42 ③重要顧客、かつ特定業態や企業特有の要望にどう向き合うか？まず、向き合う（気持ち！）。その上で、限られた開発⼯数の中で、課題を解決できる⽅法を探す。開発する機能は、別の課題も解決できないか、という視点も持つ。

Slide 43

Slide 43 text

学び 43

Slide 44

Slide 44 text

44 PdMとして⼤事にしていること ①本部（飲⾷店企業本社など）と店舗どちらから実装すべきか？ ②toB要望とtoC要望どちらを優先すべきか？ ③重要顧客、かつ特定業態や企業特有の要望にどう向き合うか？複雑さを⼀旦受け⼊れつつも、⾃分なりに論理⽴てて筋の通った判断をする toBだからといって、toCの視点を諦めない安易なゼロサム思考に陥らず、広い課題を解決できるアイディアを探す

Slide 45

Slide 45 text

45 採⽤情報新規プロダクトを担当してくれるPdM を全⼒で募集中です！！！ https://herp.careers/v1/tacoms/NYY8stjzzP7b