顧客に渡したアプリの問い合わせは誰が受ける？｜一次窓口と相談先の振り分け表

自分の相談や講座、伴走サービスに加えて、顧客が使い続けられるアプリも渡せるようにしたい。そう考えたとき、手が止まりやすいのが「顧客から問い合わせが来たら、全部自分で答えるのか」という点です。操作の質問も、不具合らしき連絡も、契約の相談も自分に集まるなら、結局また手を動かし続ける働き方に戻ってしまうのでは――という不安です。

先に答えを置きます。顧客が最初に相談する相手は、提供者であるあなたです。 saas biz は、管理画面のパートナー向け窓口で、あなたからのシステム・仕様などの相談を受けます。顧客の契約や講座の中身まで、saas biz が顧客から直接引き受ける形ではありません。

つまり問い合わせの流れは「顧客 → あなた → 必要な時だけ saas biz → あなた → 顧客」です。この記事では、この流れを問い合わせの種類ごとに書き出した振り分け表と、「ログインできない」という架空の一件の追い方、提供を始める前に決めておく項目を置きます。問い合わせが無くなることや、返答を自動にできることを約束するものではありません。

顧客に渡すか、自分の事業で使うかの選び方そのものは「顧客向けの自社サービスを持つとは｜業務SaaSとの違い」で扱っています。本記事は、渡したあとに問い合わせが届いた時の受け方に絞ります。

顧客への窓口は一つにしておく

顧客から見ると、使っているアプリはあなたのサービスの一部です。連絡先を一つ示しておくと、顧客は困った時にどこへ連絡するかを判断しやすくなります。反対に、内容によって連絡先が変わる仕組みにすると、顧客は「この件はどこに聞けばいいのか」から考える必要が出てきます。

そのため、顧客への窓口はあなた一つにして、そのうしろで「自分で答えられるもの」と「saas biz に確かめるもの」を分けます。分ける作業は顧客から見えないところで行い、返事は顧客と約束しているあなたから返します。

ここで大事なのは、すべてに自分で答えを出すことではなく、どれを自分で答え、どれを確かめに回すかを先に決めておくことです。決まっていないと、問い合わせが届いた時に、その場で振り分けを考えることになります。

問い合わせの振り分け表

顧客から届きそうな問い合わせを、種類ごとに一枚の表へ書き出します。列は、最初に受ける人、その場で確かめる最小限のこと、saas biz に相談する条件、顧客へ返事をする人です。

顧客が困ったこと	最初の窓口	あなたが確認する最小限の事実	saas biz へ相談する条件	顧客へ返す人
①商品・講座の内容や、成果についての質問	あなた	何についての質問か(どの教材・どの回か)	相談しない。商品と講座の中身はあなたが決めている	あなた
②あなたとの契約・請求・返金の相談	あなた	顧客とあなたの間で交わした取り決めのどこに関わるか	相談しない。顧客との契約と請求はあなたが管理している	あなた
③ログインできない・動きがおかしい	あなた	いつ・どの画面で・どんな表示が出たか	案内や設定の確認で解決せず、システムの問題が疑われる時	あなた
④この機能で何ができるか・仕様の確認	あなた	顧客が何をしようとしているか	今の機能や対応範囲が自分では確かめられない時	あなた
⑤どれに当たるか分からない相談	あなた	顧客が何に困っていて、何をしたいのか	③④に当たると分かった部分だけ	あなた

表で見てほしいのは、「最初の窓口」と「顧客へ返す人」の列が、どの行もあなたになっていることです。③や④のようにシステムに関わる相談でも、顧客が saas biz へ直接連絡する流れにはしません。あなたが事実を確かめて、必要な部分だけを管理画面の窓口で相談し、その答えを踏まえて顧客に返します。

もう一つは、①と②には saas biz へ相談する条件が無いことです。商品や講座の中身、顧客との契約・請求・返金はあなたと顧客の間の取り決めで、saas biz の対応範囲に入りません。一方で、あなたと saas biz の間の契約や請求は saas biz の対応範囲です。同じ「契約の話」でも、誰と誰の契約かで相談先が変わります。

返金できるかどうかや、契約上どう扱うかといった判断は、この記事では決めません。あなたと顧客の取り決めを確かめ、必要に応じて専門家に相談してください。

⑤のように分類しにくい相談は、まず顧客が何に困っているのかを聞き直します。話を分けると、①〜④のどれかに収まる部分が見つかることがあります。収まらない部分は、あなたが顧客と話して決めるものとして残します。

架空の一件: 「ログインできません」と連絡が来た

説明のための架空の例を一つ追います。実在の顧客や問い合わせの記録ではありません。

あなたのアプリを使っている顧客から、「朝からログインできません」と連絡が来たとします。表の③の行です。

1. 必要な事実だけを聞く。 確かめるのは、いつから起きているか、どの画面で止まっているか、画面にどんな文言が出ているか、の三つほどです。ここでパスワードを送ってもらう必要はありません。顧客のアカウントの中身や、関係のないデータも集めません。聞く項目を増やすほど、預かる情報が増え、顧客の手間も増えます。

2. 自分で確かめられることを確かめる。 入力しているメールアドレスが登録したものと同じか、案内しているログインの入口と同じ場所から入っているか、といった点は、顧客とのやりとりの中で確かめられます。ここで解決すれば、顧客に返事をして終わりです。

3. 解決しなければ、saas biz に相談する。 案内や確認では解決せず、システムの問題が疑われる時は、管理画面のパートナー向け窓口で相談します。その時に伝えるのは、1 で聞いた事実です。顧客から聞いていないことを推測で足さないようにします。

4. 顧客へは、あなたが返す。 相談している間も、顧客には「確認しています」と、今の状況をあなたから伝えます。いつ直るかが分からない時に、直る時刻を約束しません。答えが決まっていない時に何と返すかは、次の節で事前に決めておきます。

この一件で見えるのは、あなたの仕事が「直すこと」ではなく、事実を確かめて、どこで解決するかを決め、顧客との約束を保つことだという点です。

提供を始める前に決めておく五つ

顧客にアプリを渡す前に、次の五つを書き出しておきます。問い合わせが届いた時に、この五つに照らして受け方を確かめるためです。

1. 顧客に示す連絡先 — 顧客がどこへ連絡すればよいか。実際に届き、あなたが見ている窓口だけを書く

2. その場で答えられる範囲 — 表の①②のように、あなたが決めていて自分で答えられる問い合わせはどれか

3. saas biz に相談する条件 — 表の③④で、どこまで自分で確かめたら相談に回すか

4. 答えが決まっていない時の返し方 — 確認中であることをどう伝えるか。決まっていない日時や結果を書かない

5. 問い合わせの記録に残すこと — いつ、どんな相談が、どう解決したか。顧客の個人的な情報やパスワードは残さない

同じ種類の問い合わせが記録にあれば、提供前の案内や使い方の説明を見直す材料にできます。共通にしてよい部分と人に残す部分の考え方は「顧客ごとの個別対応を減らす方法｜共通化してよい部分・残す部分」で詳しく扱っています。

問い合わせがゼロになる運用を目指すのではなく、顧客がまた使える状態を保つために、受け方を決めておく。それが、顧客と長く関わり続けるための土台になります。顧客が使い続ける環境と、あなたの方法を組み合わせる全体像は「個人のプラットフォームとは何か｜顧客が使う環境と自分の方法を組み合わせる」で扱っています。

saas biz が受け持つ範囲

saas biz は、提供するアプリの開発・保守と、仕様やシステムに関するパートナー向けの窓口を受け持ちます。顧客への商品設計・販売・契約・一次問い合わせは、提供者であるあなたが担います。顧客への日々の操作の手ほどきや運用の代行、あなたと顧客の間の取り決めについての相談は、saas biz の範囲に入りません。

顧客に渡さず、自分の事業だけで使うこともできます。顧客に渡すかどうかは、その顧客の困りごとと用途を確かめてから決める、別の判断です。

顧客に渡す場合の役割を、saas bizのサービス紹介で確かめる

この記事の下敷き

• saas biz の営業資料 — 顧客への一次サポートは提供者が担い、saas biz は管理画面の窓口で提供者からの二次の問い合わせを受けること。saas biz が対応する範囲(システムの不具合・ログインやアカウントの技術的な問題・機能や仕様の確認・saas biz との契約や請求)と、対応しない範囲(提供者と顧客の間の契約・請求・返金・紛争、商品や講座の中身、顧客への日々の操作の手ほどきや運用の代行)

• サービスページ — 「顧客との契約・請求・一次問い合わせ・提供範囲の説明はあなたが担う」「saas biz は提供アプリの開発・保守や仕様・システムに関するパートナー向け窓口を用意する」の説明

振り分け表、架空の一件の追い方、提供前に決めておく五つは、上の役割分担を実際の問い合わせの受け方に当てはめて本記事で組み直したものです。資料にそのまま載っている手順や表ではなく、効果を確かめたものでもありません。架空の一件は説明のための例です。記事の著者名と更新日は記事ページの冒頭に表示されます。