写真つきレビューを3.7倍にした米国のコーヒー店｜Compass Coffeeの依頼設計

レビューが増えない、とくに写真つきのレビューが集まらないという詰まりに対して、米国ワシントンDCのコーヒー店 Compass Coffee の公式導入事例は、依頼文の言い回しを変えるのではなく送る条件と、投稿のあとに返すものを組み替えるという答え方をしています。

先に要点を3つ書きます。1つ目は、依頼を送る起点を「注文から何日後」ではなく商品が届いたかどうかに変えたこと。2つ目は、投稿のあとの分岐を写真が付いているかどうかだけで切り、写真つきには割引コードを自動で発行していること。3つ目は、その分岐の条件に星の数と文章の内容を使っていないことです。

公表されている数字は3つです。導入後の最初の四半期でレビューの総数が10%増、四半期あたりのレビュー件数が前四半期比70.5%増、画像つきの投稿が前四半期比3.7倍。売上への影響と、投稿の実数は公表されていません。

この記事では、公式導入事例に書かれている施策の中身を整理したうえで、仕組みの側を提供元の公式ヘルプと突き合わせ、同じ設計をするときに何が前提として要るのかまで見ます。確認日は2026年10月29日です。英語の記載を訳しているため、管理画面の日本語表記とは語が違うことがあります。

どんな店が、どこを触ったのか

Compass Coffee は2014年に始まったコーヒーの会社です。公式導入事例の記載では、ワシントンDC圏で17の店を運営し、2020年にサブスクリプション（定期購入）を軸にしたECを立ち上げています。業種は食品・飲料、ECの土台は Shopify と書かれています。

ここで扱うのは店頭の話ではなく、ECで売ったあとの話です。日本の小さな事業者から見ても、条件はそう遠くありません。焙煎した豆を送る、届いたころに感想を聞く、次の注文につなげるという流れは、商品が食品でなくても成立します。店舗数が17あるとはいえ、やっていることは「出荷した相手へメールを送る」の設計です。

触ったのはレビューの収集だけで、商品や価格を変えた話は出てきません。公式導入事例は、もともとメールとSMSを同じツールで送っていた状態から、レビューの機能も同じツールへ寄せたという順序で書かれています。設定を始めてから1週間ほどで切り替えたという記載があり、乗り換えに長い工期を取っていないことも読み取れます。

前の仕組みで詰まっていたこと

公式導入事例が挙げている不満は、大きく2つに分かれます。

1つ目は、写真を出してもらう動機づけができないことです。特典として渡せるのが独自のポイントだけで、受け取る側に分かりにくかったと書かれています。ポイントは、使えるのが次の買い物のときで、いくらぶんなのかもその場では見えません。「写真を1枚足してもらう」という一手間に対して、見返りが遠すぎたという形です。

2つ目は、依頼メールが配送の状況と無関係に出ていたことです。決まった日程で送られるため、まだ商品が届いていない人にも依頼が届きます。届いていない人が書けるのは、注文体験までです。商品そのものの感想は書けませんし、写真はなおさら撮れません。

この2つは別の問題に見えて、根は同じところにあります。依頼を出す条件と、返すものの条件を、店側が決められないという一点です。公式導入事例でCMOのJoel Shetterlyさんは、以前の仕組みでは既定のレビュー依頼の流れは手に入るが、ツール側で使える自動化の条件や絞り込みをそこへ持ち込めなかった、という趣旨の説明をしています。

詰まっていたこと	前の仕組み	変えたあと
依頼を送る時点	決まった日程で送る。配送の状況を見ない	配送・出荷の完了を条件にする
写真への見返り	独自のポイントだけ。金額が見えない	割引コードを自動で発行する
分岐の条件	細かい条件を持ち込めない	写真の有無で2つに分ける
置き場所	メール・SMSと別のツール	同じツールへ寄せる

依頼が届く時点を、配送の完了にそろえる

ここから先は、仕組みの側を公式ヘルプで確かめます。公式導入事例は施策の結果を語るもので、動作の仕様は書かれていないためです。

依頼メールの起点になるのは「Ready to review」というイベントです。公式ヘルプの説明では、商品が配送または出荷され、店側が設定した条件を満たした時点で記録されるものとされています。注文そのものではなく、注文のあとに置かれた1段の判定が起点になっている形です。

この1段があるかないかで、依頼の意味が変わります。注文を起点にすると、送る日は「何日後」で決めるしかありません。配送が早い地域と遅い地域、在庫がある商品と取り寄せの商品を、同じ日数で扱うことになります。配送の完了を起点にすると、どの注文でも「届いたあと」という同じ状態から数えられます。日数を当てにいく作業がなくなるのがいちばんの違いです。

Compass Coffee が絞ったのは、まさにこの点だと公式導入事例に書かれています。依頼を出すのは配送が終わったあとだけ、という条件に変えています。

もうひとつ、公式ヘルプには見落としやすい前提が書かれています。イベントが発生するのは、この機能を使い始めたあとに出された注文だけです。導入直後に過去の購入者へ一斉に依頼が飛ぶことはなく、逆に言えば、過去の顧客からレビューを集めたいなら別の手段が要るということになります。公式ヘルプはキャンペーン（一斉配信）で依頼する方法を別に用意しており、自動の流れと使い分ける形になっています。

投稿が終わったあとに発生するイベントも分かれています。文章を伴う投稿は「Submitted review」、星の数だけの送信は「Submitted rating」という別のイベントです。特典を渡す流れをどちらにつなぐかで、何に対して見返りを出しているのかが変わります。星だけで特典が出る設計にすると、文章も写真も残らないまま特典だけが出ていきます。

投稿のあとを、写真の有無だけで分ける

この事例でいちばん具体的なのは、投稿が終わったあとの分岐です。

分岐に使っているのは「review_has_media」という項目です。公式ヘルプの説明では、レビューに画像または動画が含まれていたかを真偽で表すものとされています。写真が付いていれば真、付いていなければ偽。それだけの項目です。

写真が付いていた側には、15%の割引コードが自動で発行されます。公式導入事例の記載では、以前のポイントに代えて、ECの側で使える割引コードを自動生成する形に変えています。受け取る側から見ると、見返りが「次に使える何か」から「いくら引かれるか」に変わっています。

写真が付いていなかった側には、お礼のメールが届きます。そこに、次は写真も添えてほしいという案内が入ります。投稿そのものを断っているわけではなく、特典だけが出ないという扱いです。ここを「写真がないなら無反応」にすると、せっかく書いた人に何も返らない設計になります。

写真を増やしたい理由は、公式導入事例に数字として表れています。レビューの総数の伸びより、画像つきの投稿の伸びのほうが大きいという形です。文章のレビューは比較の材料になりますが、写真は商品が届いたときの実物を見せます。焙煎した豆、淹れた一杯、届いた箱。言葉で「香りがよい」と書かれるより、実物が1枚あるほうが買う側の判断は早いという性質があります。

分岐の条件に、星の数と内容を使わない

この事例でいちばん持ち帰る価値があるのは、おそらく条件に使わなかったものです。

公式ヘルプには、レビューの項目として星の数（review_rating）も文章（review_content）も用意されています。技術的には「4つ星以上なら特典」も「一定の文字数以上なら特典」も組めます。それでも、この事例が条件にしているのは写真の有無だけです。

公式ヘルプの側にも、揃った記述があります。レビューと引き換えに特典を出す場合は、レビューの内容にかかわらず、投稿された時点で渡すとしています。推奨される運用として書かれているもので、強制の仕様ではありませんが、提供元の立場がどこにあるかは読み取れます。

理由は2つに整理できます。1つは、評価の高さを条件にすると、集まったレビュー全体が買う側にとっての判断材料として使えなくなることです。高い評価だけに特典が出ていると分かった時点で、並んでいる星の数は実態を表さなくなります。もう1つは、各国の表示に関する規制です。日本では、投稿の内容を条件にした依頼や、事業者の関与を隠した投稿が景品表示法の論点になります。この線引きは口コミ依頼はステマ規制に当たるか｜景品表示法の線引きで整理しています。写真の有無は、評価の方向とは無関係な条件です。「写真を1枚足す」という手間に対して払っているという説明が成り立ちます。

ただし、特典を出すこと自体が無条件に安全という話ではありません。投稿先のサービスの規約は、法令とは別に存在します。自社サイトに載せるレビューと、第三者のレビュープラットフォームに載るレビューでは、見返りの扱いが違うことがあります。海外向けのレビュー収集でよく使われるサービスの規定はTrustpilotの招待ルール｜集めてよいレビューと無料枠の上限にまとめてあります。自社で持つレビューの話と、外部のレビューの話を同じ設計で扱わないほうが安全です。

公表されている結果と、その読み方

読むときの条件は3つあります。

1つ目は、すべて率と倍率で、実数が出ていないことです。前四半期比70.5%増と言われても、元が何件なのかは分かりません。10件が17件になったのか、1万件が1万7千件になったのかで、意味はまったく違います。

2つ目は、1社・1期間の値だということです。導入後の最初の四半期という、施策の注意が最も向いている時期の数字です。

3つ目は、この事例を公開しているのがその店が使っているツールの提供元だということです。成功した側の視点で書かれた資料であり、店が自ら公開した数字ではありません。因果についても、公式導入事例は仕組みを入れ替えたあとにこうなった、という書き方をしています。分岐の設計が70.5%の伸びを生んだ、という形では書かれていません。同じ四半期には、商品の出荷量も季節も動きます。

公表されている値	何の値か	公表されていないこと
レビューの総数が10%増	導入後の最初の四半期の伸び	件数、比較の起点
四半期あたりの件数が70.5%増	前四半期との比較	件数、対象の商品
画像つきの投稿が3.7倍	前四半期との比較	枚数、1件あたりの枚数
15%の割引コード	写真つきの投稿に対する特典	利用率、割引の総額

探しても見つからなかった項目も残しておきます。売上と利益、EC全体の注文件数、レビュー依頼の送信数と開封率、割引コードの利用率、依頼メールの通数と間隔、配送完了からレビュー依頼までの待ち時間。いずれも今回の出典には書かれていません。依頼を何通送っているのかが分からないので、この事例を通数の設計の参考には使えません。購入後のメールを何通にするかという論点は14通のうち売るのは3通｜米焙煎店の購入後フォローメールの側で扱っています。

日本の実務者が参考にできる点

持ち帰れる形にできるものを4つに分けます。いずれも、同じ結果が出ることを示すものではありません。

第一に、依頼を送る起点を、日数ではなく状態に置き換えることです。配送完了の通知を受け取れる仕組みがあるなら、「注文から5日後」をやめられます。使っているカートや配送業者の連携でこれが取れるかどうかを、先に確かめる価値があります。取れないなら、依頼の設計を変える前にそこを作る順序になります。

第二に、見返りを出す条件を、評価と無関係なものにすることです。写真の有無は、その条件のひとつにすぎません。レビューを書いた、設置後の写真を添えた、使い始めて1か月後に追記した。どれも、評価が高いか低いかとは独立しています。条件を評価の側に寄せた時点で、集めたレビューは判断材料として使えなくなります。

第三に、見返りの中身を、受け取る側がその場で金額に換算できるものにすることです。この事例が変えたのは、ポイントから割引コードへという一点でした。独自のポイントは、運営側から見れば原価を抑えられますが、受け取る側には換算の手間が残ります。手間を1つ足してもらうための見返りに、別の手間を付けている状態になります。

第四に、写真が付かなかった投稿にも何かを返すことです。この事例では、お礼と次回の案内が届きます。無反応にすると、書いた人の側には「出したのに何もなかった」という記憶だけが残ります。レビューは1回で終わる取引ではなく、次の注文の前段でもあります。

逆に、そのまま持ち込めないものもあります。特典の出し方は、投稿先と国の規制で扱いが変わります。自社サイトに載せるレビューを前提にした設計を、外部のレビューサービスや地図アプリの口コミへそのまま適用しないでください。表示の規制についても、依頼文と特典の設計を決める前に確認する順序が安全です。

まとめ

Compass Coffee の事例は、レビューの集め方を「依頼文の工夫」から「条件の設計」へ置き換えた記録として読めます。依頼を送る起点を配送の完了にそろえ、投稿のあとは写真の有無だけで2つに分け、写真つきには金額の分かる割引コードを自動で出す。星の数と文章の内容は、条件に使っていません。

公表されている値は、最初の四半期でレビューの総数が10%増、四半期あたりの件数が前四半期比70.5%増、画像つきの投稿が前四半期比3.7倍の3点です。いずれも実数と母数は公表されておらず、提供元が公開した事例であることも差し引いて読む必要があります。

それでも、起点を日数から状態へ移したことと、見返りの条件を評価から切り離したことの2点は、規模にも業種にも関係なく持ち帰れます。どちらも、送る文章を書き直す前に決まっている部分です。