返金・補償を約束する前に――サービス保証の対象と請求手続きをどう決めるか

配送の遅延やサービスの停止に対して、返金や利用料の減額を約束する。契約前の顧客には、安心して選ぶ理由になり得る。提供する側にも、約束を守るための基準ができる。ただ、宣伝に載せる一文と、顧客が実際に補償を受け取るまでの仕事には距離がある。

何をもって約束違反とするか。誰が証拠を集め、いつまでに申し出るのか。返すものは現金か、次回の利用料か。サービス保証の導入では、補償額と同時に、保証の対象と請求から支払いまでの経路を決めたい。 請求件数が少ないという結果だけでは、約束を守れたのか、請求されなかったのかが分からない。

保証の効果は、品質改善だけではない

保証を掲げることで、顧客が提供者の品質を信頼しやすくなる可能性がある。一方、失敗時の支払いを避けるために、現場が品質を改善するという働きも考えられる。両者は同じではない。元から品質がよい会社が、その自信を伝えるだけでも顧客の評価は変わり得る。

Chenらの2009年のホテル研究は、北米の中価格帯ホテルチェーンの保証導入を、複数拠点の回帰不連続による準実験として分析した。大学著者稿によれば、データは1998年1月～1999年4月の16か月分で、解析対象は81ホテルである。保証は、導入前のサービス評価が高いホテルや、対応しやすい宿泊客の多いホテルで、より有効だった。著者らは、品質のよさを知らせる働きと整合的であり、保証がサービス提供そのものを改善するという説明には沿わない結果と述べている。

ここで有効とされたのは、顧客の評価に対する効果である。大学が公開する著者稿で確認すると、評価には再訪・推薦の意向や価格に対する価値の質問が使われている。実際の再予約件数ではなく、保証の支出データがないため採算も評価できていない。保証を出せば不具合や費用が減るという結論には進めない。ただし、この結果だけで保証による品質改善が常に起きないと決めることもできない。国内の法人向けサービスにそのまま当てはめることもできない。評価と実行動の読み分けは、NPSと継続利用を扱う記事にも関わる。

導入の狙いが契約前の不安を減らすことなら、何が保証されると顧客は理解するかを見る。品質改善が狙いなら、保証の対象となる不具合自体が減ったかを見る。顧客の好意的な反応だけで、後者を確認したことにはならない。

補償を受ける条件は、サービスごとに違う

AWSのAmazon Compute SLAは、EC2の可用性とサービスクレジットを結びつけている。ただし、ここでの停止の定義は外部への接続がない状態である。EC2へ接続できても、利用者のアプリケーションや業務が完成することまで同じ基準で保証されるわけではない。

SLAのクレジットを受けるには、AWS Support Centerでの申請が必要になる。停止の日時、対象のリソース、ログなどを提出し、事象の後の2回目の請求期間の末までに受理される必要がある。クレジットは原則として将来のEC2利用料に充てられ、条項自体は現金の返金を受ける権利を与えていない。保証があっても、自社の停止損失がそのまま支払われると考えるのは早い。

一方、同じSLAには別の扱いもある。単一インスタンスが、時計で区切られた1時間のうち6分を超えて停止した場合、その時間の料金は自動で課金されず、申請も不要とされる。申請式と自動式を分けて確認する必要がある。

FedEx Canadaの公式案内は、サービスの不履行に対するクレジットまたは返金の請求を説明している。請求書払いの荷物では、元の請求書の日付から15暦日以内に申し出る。現金やカードなどで支払った荷物は、発送日から15暦日以内となる。同じ会社の同じ保証でも、支払い方法によって期限の起点が違う。これはカナダ向けの条件であり、日本の配送やすべての配送サービスの共通条件ではない。

2026年10月7日に確認した同じ案内では、カナダの支払者向けの一部サービスに適用を限定し、その他のFedEx Express・FedEx Groundの保証は停止中とされている。期限が分かっても、利用する便が対象かという確認は残る。

自社で保証を設計するときも、広告の大きな約束から、対象、期限、証拠、補償の形まで一続きに読める必要がある。対象を絞る場合には、顧客の仕事で何を守る基準なのかを説明したい。計測しやすいという提供者の都合だけで選ぶと、約束を達成していても顧客の困り事は残り得る。

請求が増えても、不具合が増えたとは限らない

保証に関する件数は、利用から支払いまでの途中で変わる。対象となる不具合が起きても、顧客が保証を知らない、窓口が見つからない、必要な証拠を用意できない、期限を過ぎるといった理由で、請求に表れない場合がある。請求を受けても、対象外として処理される場合や、確認が済まず支払い待ちになる場合もある。制度の入口で件数が変わる考え方は、内部通報の利用しやすさを扱う記事でも説明している。保証では、そこから補償を受け取る条件と費用まで追う。

理解のため、実測ではない仮定例を置く。1,000件の利用のうち、記録から確認できる保証対象の不具合が40件あったとする。適正な請求が10件で、1件の補償が2,000円なら、補償の支払いは2万円である。

窓口の案内を分かりやすくし、同じ40件に対して適正な請求が30件届くようになれば、支払いは6万円になる。不具合は40件のままでも、補償費は3倍になる。対象不具合に対する請求の割合は25％から75％へ変わる。ここでは不具合数や補償単価を同じと置いており、窓口改善の実際の効果を示した値ではない。

この増加を品質悪化とだけ読むと、請求を受けにくくする方向へ戻りかねない。反対に、支払いが少ないことを低コストの成功と見れば、本来補償される案件が落ちているかもしれない。対象不具合の件数、請求の件数、支払いの件数は、それぞれ別に残す。 対象外にした理由と未処理の時間も分かれば、品質の問題と処理の問題を切り分けやすくなる。

別の仮想条件として、請求が増えると同時に、保証対象の不具合自体も増えているなら、窓口を狭めるのではなく、品質改善と保証範囲・補償費の採算を先に見直す。これも本稿の仮想比較である。

予算は届いた請求だけで考えず、確認できた対象不具合のうち、より多くが請求される場合も見込む。補償額に加え、確認や返答の人手も費用になる。補償を払った案件から改善策を決める際には、申請しやすい顧客の声だけを、利用者全体の問題の順位にしないようにしたい。

不正への懸念を、全員の請求を難しくする理由にしない

手続きを簡単にすると、対象ではない顧客も請求するのではないか。この懸念には確認が必要だが、請求件数が増えたこと自体を不正の証拠にはできない。

WirtzとKumの2004年の研究は、ホテル、旅行、レストランの場面を用いた3つの研究で、保証の不正利用の要因を調べた。著者公開の全文では、シンガポールの回答者が架空の人物の場面について答える質問票だと確認できる。請求しやすさの平均的な主効果は、旅行とレストランの場面で、不正利用に関する回答に有意な差を示さなかった。一方、レストランの研究では、個人特性と補償の大きさ、請求しやすさの組合せによる有意な差も報告されている。平均だけで、すべての条件で差がないとは読めない。

これは実取引の不正請求率ではない。手続きを簡単にしても不正が絶対に増えないとも、日本の法人向けサービスに同じ結果が出るとも言えない。それでも、難しい手続きなら安全という前提を自動的に置く根拠にはならない。必要な証拠は保証対象を判定するために求め、調査が必要な請求はその理由を記録して扱う。正当な請求が途中で止まる負担と、不正を確かめる負担を混ぜない設計が必要になる。

約束を出す前に、支払いまで通せるかを見る

提供者と顧客が同じ不具合を確かめられ、顧客の仕事にも意味のある基準なら、まず具体的な対象を保証する方法を検討できる。たとえば配送の到着時刻と、質問への初回返信では、守れる仕事が違う。返信を保証しても、質問の解決まで保証したことにはならない。

満足全体を保証する方法は、数値では捉えにくい経験も含められる。その分、どの申し出を補償するか、現場にどこまで判断を任せるか、支払いが増えたときに予算が足りるかを決める必要がある。対象が曖昧なまま広い約束を出し、請求の段階で狭めると、顧客が理解した保証とのずれが残る。計時の起点や必要な資料を両者で確かめられず、請求が止まるなら、宣伝を広げる前に定義と処理を整える段階に戻る。

提供者の記録だけで対象と金額が確定するなら、自動補償とする案も比べられる。顧客の利用事情を聞く必要があるなら、判定に必要な資料を絞って申請を受ける案になる。自動化が難しいという理由だけで、毎回一から事情を説明させる必要があるとは限らない。

保証の対象、申請の経路、補償の形を決めても、サービスの復旧や再発防止が終わるわけではない。失敗後の対応は、顧客に残る支障と損失を分ける記事で扱っている。顧客と提供者が同じ事実で保証対象を判定でき、補償まで処理を通せるなら、対象を限定した保証から試す。満足全体を保証する場合は、現場の裁量と費用の負担を決められるまで導入を待つ。 約束の魅力に加え、約束違反を確かめ、顧客が補償を受け取れることまでが導入の条件になる。