shika-review-demo

概要

歯科医院向けGoogle口コミ集めアプリ shika-review の、商談でその場で触ってもらうためのデモ版。本体を複製したうえで、ログイン・外部サービスへの接続・実際の送信をすべて取り外している。

• ログイン不要。 トップを開いた瞬間に中身が見える(認証画面を1枚も持たない)
• データはすべて架空。 医院は1件、患者は見本／例示／サンプル姓の11名のみ。電話番号は全国で未使用の局番、メールは RFC 2606 の example.com だけを使用
• 外部サービスの鍵をひとつも使わない。 設定ファイルが無くてもビルドと起動が通る
• 送信ボタンは見た目だけ動く。 押すと行の状態が変わり、再読み込みで元に戻る。メールもSMSも1通も出ない

鍵ゼロは「デモモード」のようなフラグでは担保していない。フラグは入れ忘れると本物のデータベースに繋がる側に倒れるため。かわりにSupabaseの依存パッケージ自体を package.json から削除し、本物のクライアントを読み込んだ瞬間にビルドが落ちる状態にしてある。メール送信・SMS送信の実体はファイルごと存在しない。9ルートを実際にブラウザで開いて、外部ホストへのリクエストが0件であることを実測している。

なぜ作ったか

営業先に「こういうものが作れます」と見せるとき、資料やスクリーンショットでは伝わらない部分がある。とくにこのアプリの価値は「口コミ文を代わりに書かない」「満足度で送り先を振り分けない」というやらないことの設計にあるので、現物を押してもらわないと説明が空回りする。

そこで、スクリーンショットの置き場ではなく訪問先のスマホで実際に指で押せる画面として、本体とは別に用意した。ログインを挟まないのは、URLを送った30秒後には触ってもらえるようにするため。

どういう場面で使うか

歯科医院へ営業に行き、実物をお見せする場面。相手のスマホやタブレットでURLを開いてもらい、実際に押してもらう。

とくに見てもらいたいのは患者が受け取る画面。「Googleに口コミを書く」と「ご意見・ご要望を医院に送る」の2つのボタンが、同じ大きさ・同じ色で常に並んでいる。これは見た目の好みではなくGoogleの規約を守るための作りで、商談ではここが一番の説明どころになる。

自動化されているポイント

デモで「自動でやっていること」として見せられる部分(本体アプリでは実際に自動で動く)。

1. 今日案内すべき患者の自動抽出 — 来院日から決められた日数が経った人を自動で拾い出し、一覧に並べる。受付が名簿を見返して探す必要がない。予定日を過ぎている人は「もう遅れています」として上に出る
2. 案内文面の自動組み立て — 医院名・患者名・口コミページへのリンクを自動で差し込む。1件ずつ書く必要がない
3. 送信状態の自動追跡 — 送信待ち → 送信しました(到達確認中) → 届きませんでした、を各行が持つ。届かなかった人だけを拾い直せる
4. 口コミ件数と平均評価の推移の自動グラフ化 — 週ごとに記録した数字を、折れ線1本と大きな数字1つにまとめる

デモ版では1〜4すべて架空のデータで再現している。画面は変わるが、実際の送信は1件も行われない。

使い方(画面の流れ)

① 患者が受け取る画面。チップを押して、2つのボタンから自分で選ぶ

「どんな点がよかったですか?」の下に4つのチップが並ぶ。何個でも選べるし、1つも選ばなくても先に進める。その下に「Googleに口コミを書く」と「ご意見・ご要望を医院に送る」が同じ大きさ・同じ色で並ぶ。上部の黄色い帯は、スクロールしてもずっと画面に残る。

② チップを選んでも、2つのボタンは1pxも変わらない

ここがこのアプリの中核。選んだ内容は箇条書きで下に出るだけで、口コミの文章にはならない(自動生成した文をコピー&ペーストさせない)。そして何を選んでも2つのボタンの大きさ・色・位置は変わらない(満足度で送り先を振り分けない)。375px幅で選択0個／1個／全部の3通りを実測し、ボタンの下端が512pxで固定されていることを確認している。

③ 受付が見る「今日の送信予定」。送るボタンは見た目だけ動く

今日案内すべき人が並び、予定日を過ぎた人は「もう遅れています」として上に出る。それぞれに「今この方を出している理由」が日付つきで書いてある。「送る」を押すとその行だけが「送信しました(到達確認中)」に変わる。**届いてもいないのに緑にはしない。**再読み込みで元に戻る。

④ 口コミ件数と平均評価の推移

折れ線1本と大きな数字1つだけ。グラフのすぐ下に「(デモのため、この画面の数字は架空のものです)」を置いている。上部の帯と重複するが、打消しの表示は打ち消す対象のすぐ隣にあるべきなので両方置いている。

訴求ポイント

1. 「口コミ文を代わりに書かない」ことが、そのまま差別化になっている 競合の多くは、選んだ項目から口コミの文章を自動生成してコピー&ペーストさせる。これはGoogleの規約に触れる可能性があり、最悪の場合集めた口コミがまとめて消える。このアプリは選んだ項目を箇条書きで見せるだけで文章を作らない。「消えない口コミしか集まらない」が売り文句になる。

2. 満足度で行き先を振り分けない 競合には、満足度アンケートを先に取り、高評価の人だけGoogleへ、低評価の人は院内フォームへ振り分けるものが実在する。Googleが明確に禁止している行為。このアプリは2つの選択肢を常に対等に出し、どちらを選ぶかは患者が決める。「そもそも振り分けられない作りになっている」と現物で示せる。

3. その場で触れるデモがあること自体が強い 資料ではなく相手のスマホで実際に押してもらえる。ログイン不要なのでURLを送るだけで中が見える。

4. 患者の操作が少ない 「押す→選ぶ→書く」の3ステップで終わる。長いアンケートを挟むサービスと比べて、患者が途中でやめにくいことを実際の画面で示せる。

5. 受付の負担がほとんど増えない 受付がやることは「今日の一覧を見て、送るボタンを押す」だけ。誰に送るかを考える手間がない。

完成の基準にしていること

「型が通った」「ビルドが通った」を完成に含めていない。実際に起動し、375px(iPhone SE 相当)で全画面を目で見て、1つずつ押して確認している。

検査	結果
設定ファイル無しでのビルド・起動	通る
全体の検査	PASS 72 / FAIL 0 / NOT-RUN 0
ブラウザ検査(9ルートを実際に開く)	PASS 10 / FAIL 0
375px 目視チェックリスト	25手順すべて実際に押して OK 25 / NG 0
外部ホストへの通信	9ルートを開いて 0件(実測)

この基準は、実際に1件の不具合を捕まえた。ご意見フォームの送信ボタンが本番ビルドで500エラーになる問題で、原因はコード1行の書き方だった。**型検査もビルドも通り、フォームの画面も普通に開く。**壊れるのは送信ボタンを押した瞬間だけだったので、既存の検査72件・ブラウザ検査10件・目視25手順のすべてを通り抜けていた。これまでの検査が「フォームが開くか」までしか押していなかったため。修正のうえ、送信を最後まで押しきる検査を追加した。