要点
ECのサポート問い合わせ率は、通常注文100件あたり19から46件のチケットです。この範囲のどこに位置するかは、販売する商品のカテゴリーによってほぼ決まります。2026年3月のGorgiasのデータでは、おもちゃ・ゲームが19.4、電子機器が46.3です。スパムと自動返信を除いてから、問い合わせ件数を注文数で割り、100を掛けて算出します。
日々問い合わせ対応をする中での私の考えは、総数だけを追わないことです。問い合わせを理由別に分類し、避けられるもの、主に「注文はどこにありますか」と返品ポリシーに関する質問をなくしましょう。eeselのようなAIヘルプデスクのチームメイトなら、Shopifyでリアルタイムに情報を確認して回答できます。問い合わせ率自体は変わらなくても、チームが抱える業務は減らせます。eesel CLIを使えば、AIコーディングエージェントが返品ポリシーをアップロードし、本番稼働前に回答をテストできます。
ECのサポート問い合わせ率とは？
ECのサポート問い合わせ率とは、同じ期間の注文100件に対して、ストアが受け取るカスタマーサポートへの問い合わせ件数です。「注文あたりのチケット数」「注文あたりの問い合わせ件数」「問い合わせ対注文比率」と呼ばれることもあります。これらは同じ数値を3通りで表したものです。注文100件あたり25件のチケットは、問い合わせ率25%、または注文1件あたり0.25件の問い合わせに相当します。
私は毎日eeselのサポートキューを担当していますが、初回応答時間やCSATより先に壁に掲げるなら、この指標です。チケットの総数からわかるのは、どれだけ忙しかったかです。問い合わせ率からは、販売数が増えたから忙しくなったのか、それとも何か問題が起きたからなのかがわかります。注文が倍になり、チケットも倍になるストアは問題ありません。注文数が横ばいなのにチケットが増えているストアには、配送業者、商品、またはポリシーの問題があります。
この指標があれば、チケット数の予測もできます。注文100件あたり25件のペースで、ブラックフライデーには12,000件の注文が来るとわかっていれば、当てずっぽうではなく、約3,000件の問い合わせに対応する人員を配置できます。
問い合わせ率はどう計算しますか？
計算式はシンプルです。
問い合わせ率 = (顧客からの問い合わせ件数 ÷ 注文数) × 100
難しいのは、それぞれに何を含めるかを決めることです。同じ方法で測定していない数値を比較するチームを見てきたので、私なら何を数えるかをまとめます。
| 数えるもの | 数えないもの |
|---|---|
| 顧客が開始したメール、チャット、SNSのDM、SMS、電話 | スパムや営業メッセージ |
| メッセージ数にかかわらず、1つの会話を1件の問い合わせとして扱う | 自動返信や不在通知 |
| 購入前の質問（別途報告する） | 発送通知や注文確認通知 |
| AIエージェントが回答した問い合わせ | 社内やB2Bパートナーとのやり取り。ただしB2B販売を行っている場合は除く |
スパムの項目は、見た目以上に重要です。ドイツのジュエリーECブランドの実際の受信トレイで行ったeeselのトライアルでは（ZendeskとShopifyを利用し、月間チケット数は約1,000件）、受信チケットの22%がスパムでした。これを含めたままにすると、そのストアの問い合わせ率は実際より5分の1ほど悪く見えます。eeselの公開導入事例に登場する顧客の1社、スイスのスーツケース販売店Koffer.chも、同じ理由から、ほかの処理を行う前に注文確認や発送通知を除外するフィルターを使っています。
分母については、Shopifyの期間別の注文数レポートで、その期間に受けた注文の総数がわかります。両方の数値に同じ日付範囲を使ってください。
自動で計算してくれるヘルプデスクはありますか？
各社のドキュメントを見る限り、主要3サービスのいずれにも標準機能はありません。チケット数をエクスポートし、自分でShopifyの注文数で割る必要があります。
- Gorgias: ヘルプデスクのパフォーマンスレポートでチケットを集計し、チケット属性タブで問い合わせ理由をグラフ化できます。推移グラフには前年同期を重ねて表示できます。注文あたりのチケット数という指標はありません。
- Zendesk: 問い合わせ理由フィールド別にチケットを数えるには、Suite Professional以上が必要なExploreのレシピを使います。
- Freshdesk: 問い合わせ理由はタイプフィールド、または3階層の連動ドロップダウンに入力します。データに漏れが出ないよう、クローズ時に必須にすることができます。
最初は、週ごとのチケット数と注文数という2列のスプレッドシートがあれば十分です。eeselのGorgiasレポートガイドでは、1列目のデータをどこから取得するかを紹介しています。
ECではどのくらいの問い合わせ率が良いのでしょうか？
良い問い合わせ率とは、自社のカテゴリーの中央値以下であり、自社の過去の数値と比べて低下している状態です。私が見つけた中で最も優れた公開ベンチマークはGorgiasのものです。2026年3月の自社プラットフォームのデータを使い、年間売上$10Mの区分について、14の商品カテゴリー別の中央値を公表しています。
問い合わせが最も少ないカテゴリーと最も多いカテゴリーの差は2.4倍です。Gorgiasの言葉では、電子機器ブランドは"nearly one ticket for every two orders,"、食品・飲料は"roughly one in five."です。
| カテゴリー | 注文100件あたりのチケット数 | 初回応答時間の中央値 |
|---|---|---|
| 電子機器 | 46.3 | 4.8時間 |
| 車両・部品 | 46.0 | 4.4時間 |
| 工具・金物 | 41.2 | 1.6時間 |
| スーツケース・バッグ | 32.3 | 7.7時間 |
| ホーム・ガーデン | 31.9 | 4.4時間 |
| スポーツ用品 | 31.8 | 5.8時間 |
| 業務用・産業用品 | 24.9 | 4.0時間 |
| 動物・ペット用品 | 24.8 | 3.6時間 |
| ベビー・幼児用品 | 24.4 | 5.3時間 |
| 衣料品・アクセサリー | 22.4 | 8.8時間 |
| 健康・美容 | 21.1 | 5.2時間 |
| アート・エンターテインメント | 20.8 | 9.1時間 |
| 食品・飲料 | 20.4 | 5.1時間 |
| おもちゃ・ゲーム | 19.4 | 8.3時間 |
出典：Gorgias Ecom Lab、年間売上$10Mにおける中央値、2026年3月時点のGorgiasプラットフォームのデータ。
これを自社の基準にする前に、2つ注意点があります。数値の対象はGorgiasを利用する事業者のみで、大半はShopify上の消費者直販ブランドです。また、スパムやAIが処理したチケットを除外したかどうかはページに記載されていません。小数点単位で追う目標ではなく、おおよその範囲として捉えてください。
その調査ページで私が最も共感するのは、次の捉え方です。
"This is not good or bad. It reflects product complexity and how much customers need to ask before and after buying. If you are in a high-ticket-volume vertical, that is your baseline, not a problem to fix."
eeselの商談で聞いた実例も、これに合致します。GorgiasとShopifyを利用する消費者直販のサプリメントブランドは、月間約30,000件の注文に対して約7,000件のチケットを処理しているとチームに話しました。これは注文100件あたり約23件のチケットで、健康・美容カテゴリーの中央値21.1に近い数値です。それでも、チームが対応しきれないほどの量でした。
あなたのストアはどの位置にありますか？
先月の数値を入力してください。この計算ツールは、カテゴリーの中央値と比較し、問い合わせの一部に自動で回答した場合にチームが抱える負担を表示します。
注文あたりの問い合わせ件数を左右するものは？
問い合わせの大半は、いくつかの理由に集約されます。私が見てきたどの一覧でも、注文状況がトップです。2023年のGorgiasの記事によると、"where is my order"が、同社を利用する事業者への問い合わせの平均18%を占めています。直近90日間のデータを使うリアルタイムのEcom Labダッシュボードでは、2026年11月4日に私が確認した際、全業種表示で"Order"が17.1%と、最も多い問い合わせ意図になっていました。
問い合わせ対応の現場から見ると、受信トレイを埋めるのは次の5つの分類です。
- 注文はどこにありますか。 配送業者の遅延、更新されない追跡情報、そもそも追跡番号が付いていない注文です。
- 返品・返金。 対象になるか、どう手続きを始めるか、返金はどうなっているか、といった質問です。
- 注文の変更。 住所の修正、キャンセル、発送前のサイズ変更です。
- 商品に関する質問。 サイズ感、互換性、在庫、再入荷日です。
- トラブル。 商品の破損、不足、誤配送です。
Redditのあるアパレルストアのオーナーは、注文状況に関する問い合わせを、私がチケットで見ているのとまったく同じように説明していました。
"Apparel, 190 orders a day, 3 person support team. Pulled the tags last week and 41% of tickets are some version of where is my order. What we have now: shopify's default shipping confirmation and then nothing. Customer gets one email with a carrier link and then silence for 6 days."
eeselの公開導入事例も、別の角度からこれを裏付けています。GorgiasとShopifyを利用する手帳・文房具ストアのSTIL Classicsでは、eeselがある月に回答を用意した320件のチケットのうち230件で、Shopifyの注文情報を取得しました。チケットのおよそ10件中7件が、特定の注文に紐づいていたことになります。
季節性によっても数値は動きます。ノルウェーのクライミングウェアブランドRúngneでは、6月22日の週に198件だったチケットが、7月20日の週には852件になりました。各週は前月ではなく前年の同じ週と比較してください。そうしないと、繁忙期のピークが毎回失敗に見えてしまいます。eeselの季節的なサポート急増の記事では、その計画方法を解説しています。
問い合わせ率の低下を追うと、なぜ逆効果になることがあるのでしょうか？
すべての問い合わせが悪いものとは限らないからです。問い合わせ率を下げる最も手っ取り早い方法は、問い合わせフォームを見つけにくくすることです。数値は下がりますが、顧客の怒りは増します。私は、顧客が連絡を諦めた結果100件あたり15件になるストアより、100件あたり30件でも全員に回答するストアのほうが良いと思います。
対策は、問い合わせを減らそうとする前に分類することです。
- 未然に防ぐ。 連絡が途絶えたからこそ、顧客が問い合わせてきたものです。遅れている荷物について何も更新がないケースが典型です。
- 即座に回答する。 注文状況、返品可能期間、配送日数など、答えがすでにShopifyやポリシーページにあるものです。
- 人の対応が必要。 商品の破損、返金の例外対応、人の声を必要としている怒った顧客です。
- 歓迎する。 購入しようとしている人からの、購入前の質問です。目標のためにチームがこうした質問を抑え込むことがないよう、別途報告してください。購入前の質問の記事では、この分類をさらに詳しく解説しています。
人が対応するキューから取り除くべきなのは、最初の2つだけです。
あるGorgiasの顧客は、適切に分類することの効果をG2で次の一文にまとめています。
"It provides our customer experience team with clear visibility to address root problems instead of just handling repetitive tickets, which has resulted in a sustained reduction in volume."
顧客から隠れることなく、問い合わせ率を下げるには？
私なら、費用のかからない改善から始めて、次の順で取り組みます。
1. すべての問い合わせに理由別のタグを付ける
見えないものは減らせません。Gorgiasには、AIで入力できるContact Reasonチケットフィールドがあります。その指針はどのヘルプデスクでも参考にする価値があります。理由は、顧客自身が説明できるものでなければなりません。"Delayed Shipment"は良い理由です。"Warehouse Problem"はそうではありません。顧客には倉庫の様子が見えないからです。選択肢は少なく保ち、理由同士が重ならないようにしてください。EC向けAIチケットタグ付けとチケットタグの活用のガイドで、さらに詳しく解説しています。
2. 問い合わせが来る前に追跡を機能させる
ほとんどのストアにとって、これが最も大きな、避けられる問い合わせの分類です。Shopifyの注文状況ページでは、顧客が自分で配送の更新情報を確認できます。ただし、同社のドキュメントには注意点があります。"If you fulfill an order without a tracking number, then no shipping updates are received, so the status remains Confirmed." 6日間"Confirmed"を見続けている顧客は、メールを送ってくるでしょう。
Shopifyによると、完全な追跡情報は"reduce support inquiries from customers about order status,"に役立ち、Track with Shopはデフォルトでオンになっています。すべての出荷に追跡番号を追加してください。Shopify Flowで追跡情報を更新する手順ガイドでは、自動化する方法の1つを紹介しています。
3. 顧客が気づく前に遅延通知を送る
米国では、これは任意ではありません。FTCの通信販売規則では、約束した期間内に発送できない場合（期間を約束していない場合は30日以内）、顧客に対して、遅延を受け入れるか、キャンセルして速やかな返金を受けるかを選べるようにしなければならないとしています。また、その通知は当初の期限が過ぎる前に送る必要があります。適切なタイミングで遅延メールを送れば、「注文はどこにありますか」という問い合わせは発生せずに済みます。通常の発送メールよりも、例外発生時のメールのほうが重要です。
"Trigger a message when tracking shows no scan for 3 days or a delivery exception, and say what you are doing about it, like a reship or refund window. Those are the orders that turn into where is my order tickets, and also into lost package claims later."
ストアがこれほど多くの注文メールを送るのも、そのためです。Hacker Newsのある投稿者の言葉を借りると、メールを送らないストアでは、顧客が"blasting support screaming this-site-is-a-scam-where-is-my-order!?? over a two day shipping delay"という事態になります（pembrook、Hacker News）。配送遅延通知の記事では、そのワークフローを解説しています。
4. 疑問が生まれる場所にポリシーを置く
返品に関する問い合わせの多くは、ポリシーを見つけられなかった人からのものです。注文確認メール、注文状況ページ、フッターからリンクしてください。返品ポータルを使っているなら、すべての返信で案内しましょう。eeselを利用するあるEC運営者は、まさに次のルールに沿ってAIのチャット返信を手作業で修正していました。"we cant start for them they need to do it via the portal." ECのセルフサービスとプロアクティブサポートのガイドで、設定方法を解説しています。
5. 残りに自動で回答し、正直に測定する
手順1から4を実施しても残るのは、大半が注文状況、ポリシー、在庫に関する質問で、その答えはShopifyにあります。ここをAIエージェントに任せるべきです。そこで問題になるのが、次のセクションで説明する測定の落とし穴です。
AIが回答した問い合わせも問い合わせ率に含めるべきですか？
はい。注文がどこにあるかをAIエージェントに尋ねた顧客も、あなたのストアに問い合わせたことに変わりはありません。AIが回答した会話を集計から外すと、顧客体験は変わらないまま、見かけ上の問い合わせ率だけが改善します。これは、形を変えた問い合わせ回避と解決の混同です。
そこで、2つの数値を並べて追跡しましょう。
| 指標 | わかること | 変化させるもの |
|---|---|---|
| 注文100件あたりの問い合わせ件数 | 顧客がどれだけサポートを必要としているか | 追跡の改善、遅延通知、より明確なポリシー、商品の品質 |
| 注文100件あたりの担当者対応問い合わせ件数 | チームがどれだけ負担を抱えているか | AIの回答、マクロ、完全な解決につながるセルフサービス |
eeselの公開導入事例からは、2つ目の数値が実際にどうなるかがわかります。
- **Question Beauty**は、GorgiasとShopifyを利用する化粧品ブランドです。配送に関する質問に回答する前に、必ずShopifyを確認しています。追跡情報ですでに答えがわかる場合、eeselがその内容を伝えてチケットをクローズします。ある月には、処理した990件のうち、280件のチケットを人を介さずクローズしました。
- スマートフォンアクセサリーブランドの**ClutchLoop**では、eeselが会話のおよそ10件中7件に直接返信しました。主に、返品ポータルへの案内で対応する返品の問い合わせと、Shopifyのリアルタイム在庫情報から回答する商品に関する質問でした。
- **Rúngne**は、回答対象を意図的に絞っています。配送・返品ポリシー、注文の所在、在庫と予約注文です。その結果、約7件に1件のチケットに単独で回答し、キャンセル、商品の破損、荷物の紛失、関税に関するトラブルはマニラのチームに引き継いでいます。
いずれも、顧客が連絡してくる頻度を変えたわけではありません。変わったのは、そのうち何件が人の対応を必要とするかです。チケット1件あたりの作業量も変わると考えてください。簡単な「どこにありますか」というメールがなくなると、残るのは配送が止まった荷物や例外対応です。
"wismo email went from about 240 a week to 155. support team swear their day feels identical. what i think has actually happened is the easy "where is it" emails disappeared and what's left is all the genuinely stuck parcels, which take way longer each."
これは自然なことであり、両方の率と併せて対応時間も見るべき理由です。測定について詳しくは、AIと人による問い合わせ回避の記事と、AIカスタマーサービスの指標の一覧をご覧ください。
AIに任せてはいけない問い合わせはどれですか？
「人の対応が必要」に分類されるものは、人が担当します。何かを有効にする前に、その基準を文書化しておく価値があります。Rúngneの設定は良いひな型です。金銭が関わる場合、配送業者による調査が必要な場合、注文が3営業日を超えて未出荷のままの場合、事実を確認できない場合には、下書きエージェントは事実のみのメモを書き、返信は人に任せます。再入荷日や、未確認の配達日を伝えることは一切ありません。
私なら、最後のルールを最初に取り入れます。AIが誤った配達日を自信満々に伝えると、その日を過ぎたときに2度目の問い合わせが発生します。問い合わせ率を下げるのではなく、上げてしまうのです。ECにおけるAIのベストプラクティスの記事では、ほかのガードレールについても解説しています。
注文に関する質問にeeselを試してみましょう
タグを見ると注文状況やポリシーに関する質問が上位に来ているなら、そこはeeselが得意とする領域です。AIヘルプデスクのチームメイトとして、既存のGorgias、Zendesk、Freshdeskのキューに加わります。Shopify連携を完全に接続すると、注文番号やメールアドレスで注文情報をリアルタイムに検索し、追跡番号、配送業者、配送状況を確認して、推測ではなくその情報に基づいて返信します。
どのトピックには自律的に回答し、どのトピックではチーム向けの下書きだけを作成するかを選べます。返金やキャンセルなどの操作は、承認設定に従います。コーディングエージェントがCLIを通じて残りの設定を行う場合でも、Shopifyとヘルプデスクの接続には、ストアオーナーまたは管理者の承認が必要です。プランは100クレジット無料から始まり、その後は500クレジットで月額$299です。注文情報を何回検索しても、チケット1件につき1クレジットです。キュー全体を任せたい場合は、Managed Supportが代わりに運用します。
eeselを試して、まずは先月の注文状況に関するチケットを対象にしてみてください。担当者の対応件数が最も早く減るのは、そこです。