問い合わせのステータス管理｜3段階で回す設計と誰がいつ変えるかの決め方

「対応中」の問い合わせが何日も動かない。担当者に聞くと、顧客の返事待ちのことも、社内の確認待ちのこともある。同じラベルでも次に動く人が違うので、一覧を見ても判断できません。結局、口頭で「あの件どうなってる？」と聞き合っていないでしょうか。

RenRakuを提供する株式会社TechSyncが編集しています。情報確認日：2026年9月27日

ステータスが増えるほど、一覧は信用されなくなる

段階を増やすほど付け替えが追いつかなくなり、一覧の表示と実態がずれます。ずれた一覧は誰も信用しなくなり、結局また口頭で確認する。形骸化は、たいていこの順番で進みます。

ステータスを付けようと決めたチームが最初につまずくのは、段階の名前を決める話し合いです。「確認中」「保留」「折り返し待ち」「上長確認待ち」「資料待ち」と案を全部採用すると、8個や9個になります。

段階が増える理由は、主に次の3つです。どれも、真面目に運用しようとするほど起きます。

• 業務の内容で段階を切る。「見積作成中」「発送準備中」「稟議中」のように作業名で切ると、案件の種類が増えるたびに段階も増えます。ほとんど使われない段階が、一覧に並び続けます。
• 例外ごとに段階を足す。クレームが来たら「クレーム対応中」、返金が出たら「返金処理中」。これは進み具合ではなく、種類の違いです。段階として持つと、1つの列が2つの意味を背負います。
• 作った段階を消せない。過去の問い合わせにその段階が付いたまま残るので、消すと古い記録の読み方が変わります。増やすのは一瞬で、減らすのは手間がかかります。

もう1つ押さえておきたいのは、段階の数を決めるのは「見る人」ではなく「変える人」の負担だということです。細かい段階は眺める側には便利でも、付け替えるのは返信で手いっぱいの担当者です。付け替えられなかった段階は、正しくない情報として一覧に残ります。

進み具合が特定の人の頭の中にしか無い状態がなぜ生まれるかは、顧客対応が特定の担当者に依存する原因で整理しています。

最初は「受ける・進める・終える」で考える

業務ルールの例として、未着手・対応中・完了の3段階から始めます。どのツールにも同じ名前のボタンがある、という意味ではありません。製品の表示に合わせて、チームの中で何を意味するかを決めるための整理です（RenRakuの画面との対応は後の章で示します）。

段階を分ける基準は「次に動くのは誰か」だけ

迷ったら「次に動く人は誰か」だけを問います。

• 次に動く人がまだ決まっていない：未着手
• こちらが動けば進む：対応中
• 相手が動かないと進まない：対応中のうちの相手待ち
• どちらも動く必要がない：完了

作業名を基準にしないので、案件の種類が増えても段階は増えません。

特に大事なのは、対応中の中身を見分けることです。顧客の返事を待って3日止まっているのは、普通のことです。一方、こちらの社内確認で3日止まっているのは遅れです。2つを同じ「対応中」で済ませると、遅れが普通の待ちに紛れて見えなくなります。冒頭の「対応中が何日も動かない」の正体は、たいていここにあります。

見分け方は2つあります。

• 4段階にする。対応中を「こちらの番」と「相手の番」に分けます。相手待ちが多く、毎日それだけを見返す必要があるなら、こちらです。
• 3段階のまま印を付ける。相手待ちの問い合わせに「先方待ち」のような印を付けます。それ以外のチームは、これで足ります。

最初は印で始め、足りなければ分けるほうが、段階を減らす手間がかかりません。

「保留」は、理由と次の行動に書き換える

「保留」という段階を作ると、何を待っているのかも、次に誰が動くのかも読めません。止まっている理由と次の行動が読める記録に変えます。記録の例です。

• 「倉庫に在庫を確認中。火曜午前に回答予定」
• 「見積の金額を上長に確認中。本日中に回答」

別の人が読んで、自分が次に何をすればよいか分かれば十分です。

段階に入れないもの：理由・種類・優先度・次の仕事

3段階に収まらない呼び名が出てきたら、それは段階ではない可能性が高いと考えます。置き場所を分けておけば、ステータスは大きな進み具合だけを表す単純な列のまま保てます。

たとえば「クレーム」は種類、「至急」は優先度、「Aさんの案件」は担当者、「社内確認待ち」は対応中の理由です。これらを全部ステータスに詰め込むと、段階の数は掛け算で増えます。

タグは増えやすいので、最初は5個前後から始めます。「先方待ち」と「顧客待ち」のように同じ意味のタグが2つできたら、どちらかに寄せます。名前は、別の人が見て意味が1つに決まるものにしてください。「要確認」のように誰が何を確認するのか分からない名前は、「保留」と同じ問題を抱えます。

タスクは、その問い合わせの外で発生する仕事（在庫の確認、書類の作成、上長の承認）を、担当者と期限付きで残すものです。画面ごとに、答える問いを1つに絞ります。

• ステータスの一覧：どこで止まっているか
• タスクの一覧：誰がいつまでに何をするか

更新する瞬間を、仕事の区切りとセットにする

運用を壊すのは段階の数より、変えるタイミングの曖昧さです。たとえば「受付返信を送ったら、対応中のままか、相手待ちに変えるか」が決まっていないと、同じ状態の問い合わせに違う段階が付きます。

段階を変える引き金は、次の3つに分けられます。

1. 人が変える。担当者の操作で進みます。確実ですが、忘れた分だけ一覧が実態とずれます。
2. 顧客が変える。顧客の返信で、相手の番だったものがこちらの番に戻ります。
3. 仕組みが変える。返信の送信などの操作に合わせて、自動で切り替わります。何がどう動くかを、チームで理解しておく必要があります。

人が変える遷移はできるだけ減らし、残った遷移は「仕事の区切り」とセットにします。担当を引き受けたとき、社内確認を依頼したとき、顧客へ最終回答したとき。この区切りで記録を変えれば、終業後にまとめて整理する負担も減らせます。

最も揉めるのは「完了の定義」

この表で意見が割れやすいのは、完了の定義です。完了を「返信を送った時点」とするチームもあれば、「社内の作業や入金の確認まで終わった時点」とするチームもあります。両者では、同じ一覧でも数字の意味がまったく違います。

どちらが正しいということはありません。大切なのは1つに決め、1文で書いて共有することです。たとえば、次のように書けば十分です。

短い受付返信（「確認して明日ご連絡します」）を送っただけで完了扱いにしないことも、ここで決めておきます。返信したかどうかと、解決したかどうかは別の軸です。導入直後に「返信した＝完了」になってしまう問題は、問い合わせ管理の導入が失敗する理由でも取り上げています。

担当交代と休みの前日

担当が替わるときは、新しい担当が引き受けたことを確認して初めて交代完了とします。前の担当が「渡しました」と言っただけでは、受け取った側が気づいていないことがあります。

休みの予定がある担当者は、前日の終業前に自分の対応中の問い合わせを見直します。メモには「待っていること」と「次に見る日」を書いておきます。

今のラベルを3段階に整理し直す手順

増えすぎたラベルは、次の5つの手順で3段階に整理し直せます。ツールを替える前、今のメールソフトや表計算シートのままでも進められます。

1. 今使っている呼び名を全部書き出す。画面上の正式な名前だけでなく、会話やチャットでの言い方（「先方待ち」「止まってるやつ」「上に投げたやつ」）まで集めます。この時点では整理しません。
2. 3段階のどれに当たるかを割り振る。未着手・対応中・完了のどれにも入らないものは、段階ではありません。
3. 入らなかったものの置き場所を決める。前の章の表に沿って、理由・種類・優先度・次の仕事・申し送りのどれかに振り分けます。
4. 遷移ごとの引き金と完了の定義を書く。特に「誰が引き受けを示すか」と「完了の定義」は1文で書きます。
5. 見直しの日を先に決める。2週間後に15分、使われた段階と使われなかった段階を数える予定を入れてから始めます。

説明用の例として、書き出した結果を1枚のルール表にまとめたものを置きます。自社の言葉と担当者の名前に置き換えれば、そのまま使えます。

1枚に収まらないルールは、忙しい日に読み返されません。細かい判断は、実際に迷った場面が出てから1行ずつ足します。

RenRakuで「読んだ後の仕事」を残す

RenRakuは、LINE公式アカウントとメールの問い合わせを1つの受信箱にまとめ、チームで同じ履歴を見ながら対応するためのクラウドです。この記事のルールは、組み込みの3つの状態に、手で付ける印を足して組み立てます。

3つの状態は、メッセージのやり取りに合わせて動く

対応ステータスは未読・未返信・返信済の3つです。一覧では、それぞれオレンジ・赤・緑のチップで表示されます。動き方は次のとおりです。

• 顧客からメッセージが届くと、未読に戻ります。いったん返信済にした問い合わせに追加の質問が来た場合も、未読として一覧に戻ります。
• 担当者が開くと、未読から未返信に進みます。すでに未返信・返信済のものは、開いても巻き戻りません。中身を見ただけでは、未返信の印は消えません。移動中にスマートフォンで内容だけ確認した問い合わせも、返すまで赤いまま残ります。
• 返信を送ると、返信済になります。送信できたかを確かめてから変えるので、送れなかった返信では返信済になりません。送信に失敗したときは、そのメッセージに送信失敗の印が付き、要対応の印が立ちます。

前の章の分類でいえば、「顧客が変える」遷移と「仕組みが変える」遷移が最初から組み込まれています。一覧の各行のメニューから、状態を手で「未読に戻す」「未返信」「返信済み」に変えることもできます。変更は、その場で全員の画面に反映されます。

一方で、状態の名前を変えたり、4つ目を足したりする機能はありません。「対応完了」という状態も無いので、完了の定義はチームで決めます。完了したかどうかは、次に述べる要対応の印と組み合わせて表します。

要対応の印で「返信済だが、まだこちらの仕事がある」を表す

ステータスとは別の軸として、問い合わせに要対応の印（ピンクのチップ）を手で付け外しできます。受付返信を送った時点で状態は返信済になりますが、社内確認が残っているなら要対応を付けておきます。

要対応は、返信しても自動では外れません。「外すのは完了の定義を満たしたとき」と決めておけば、ルール表の完了とそのまま対応します。人が操作しなくても要対応が立つのは、次の2つです。

• 返信の送信に失敗したとき
• 送ったメールが届かず、不着の通知が戻ってきたとき

一覧に出る名前は操作の記録。引き受けは「担当」で示す

一覧には、最後に返信した人（返信前は最後に開いた人）の名前が自動で表示されます。同じ問い合わせを今開いている人も、画面に出ます。誰が触ったかの手がかりにはなりますが、あくまで操作の自動記録です。

引き受けは、やりとりの見出しの右の「担当」で担当者を1人決めて示します（スタンダード以上）。担当になった人には画面上部のベルで通知が届き、一覧の行に担当者名が出ます。「自分の担当」で、自分が引き受けた分だけに絞れます。

• 「未読に戻す」を選ぶと、最後に開いた人の記録も消えます。誰も見ていない状態に戻るので、開いたものの自分では引き受けないと決めた問い合わせを、受付係に戻すときに使えます。
• 状態と要対応の変更は、操作の記録（監査ログ）には残りません。変えた理由を後から確かめたい場合は、メモに一言残す運用にします。

理由・次の仕事・案件の段階は、RenRakuのどこに残すか

止まっている理由と種類はカラータグ、経緯はメモ、次の仕事はタスクに残します。案件そのものの段階で分けたいときは、ルームグループを使います。

理由と種類は、カラータグで表す

タグは、名前（32文字まで）と文字色・背景色を決めて作り、問い合わせに付け外しします。自動で付く仕組みは無いので、付け外しは手で行います。新しいタグを作れるのは、管理者以上か、タグ作成の権限を与えられた人だけです。

契約直後には「新規問い合わせ」「要返信」「対応中」「対応済」「お見積り中」「クレーム」の6つのタグが入っています。このうち「要返信」「対応中」「対応済」は、ステータスや要対応と意味が重なりやすいものです。使うか外すかを最初に決めておくと、二重管理を避けられます。

経緯はメモ、次の仕事はタスク

経緯や申し送りは、問い合わせごとのメモに書きます（投稿はスタンダード以上）。

• メモは顧客には見えません。知らせる人を選んで保存すると、その人に通知が届きます。
• ピン留めして先頭に固定でき、一覧には「メモあり」の印が出ます。
• 投稿したメモは編集できません。書き直すときは、削除して投稿し直します。

メモと従業員チャットの使い分けは、社内のやり取りを問い合わせにつなぐ方法で詳しく書いています。

次の仕事は、タスク（スタンダード以上）に担当者と期限を設定して依頼します。タスクは、顧客や問い合わせに紐づかない独立した一覧です。タスク名に顧客名と用件を入れておくと、探しやすくなります。

期限の通知は48時間前と24時間前の2回で、アプリを開いているブラウザの画面に出ます（メールやスマートフォンへのプッシュ通知はありません）。

案件の段階は、ルームグループで分ける

「入金前」「書類作成待ち」「送付待ち」のような案件そのものの段階で分けたい場合は、ルームグループ（スタンダード以上）を使います。返信の進み具合とは別の軸です。段階ごとの入れ物を作って問い合わせを移していく仕組みで、各グループの横には未読と未返信の合計件数が出ます。

グループの作成と名前の変更は管理者以上、問い合わせを移す操作は役職に関係なく誰でもできます。自動で振り分ける仕組みは無いので、どの区切りで移すかも遷移の表に書き加えておきます。

プランの条件

別の製品が向いているケース

次のような要件があるなら、その機能を標準で持つヘルプデスク製品のほうが向いています。RenRakuには、状態を追加する機能も、集計・分析のレポートもありません。

• 状態の名前を、自社の業務語で定義したい
• 状態ごとの件数や、解決までの時間を集計して追いたい
• 条件を指定して、状態を自動で動かすルールを作りたい

選ぶときの判断軸は、問い合わせ管理システムの選び方にまとめています。

2週間後は、分類より止まった理由を見直す

2週間後の見直しでは、段階やタグを増やす話から始めず、止まった問い合わせの理由を先に見ます。2週間使うと、どこで手が止まるかが見えてくるからです。15分で終わる確認項目の例です。

1. 引き受けた人が分からないまま、半日以上残った問い合わせはないか。
2. 「対応中」の理由を、別の人が読んで理解できるか。次に見る日が書かれているか。
3. 受付返信だけで完了扱いにしたものはないか。
4. 相手待ちのまま、次に見る日を過ぎたものはないか。
5. 同じ意味のタグが増えていないか。一度も使われなかったタグはないか。
6. 口頭で「あの件どうなってる？」と聞いた場面は何回あったか。そのとき画面に足りなかった情報は何か。

段階を足す・減らすの判断

引っかかった項目は次の表に当てはめ、直すのは一度に1つにします。

段階を足してよいのは、同じ種類の判断で迷った場面が繰り返し（目安として2週間に3回以上）出たときだけです。一度も使われなかった段階やタグは外します。増やすのは、減らす手順を持ってからにしてください。

最初の目標は、細かい分類ではありません。誰が何をすれば進むかを、短い記録でチーム全員にそろえることです。

気になる疑問

問い合わせのステータスは何段階にするのがよいですか？

少人数のチームなら、未着手・対応中・完了の3段階から始めるのがおすすめです。段階は作業の名前ではなく「次に動くのは誰か」で切ります。返事待ちと社内の作業中を見分けたい場合は、まず「先方待ち」などの印を付け、足りなければ対応中を2つに分けます。

「保留」や「確認中」はステータスとして作るべきですか？

段階としては作らず、対応中の理由として残すほうが運用は続きます。「保留」だけでは、何を待っていて次に誰が動くのかが読めないためです。止まっている理由と次の行動をタグやメモに書きます。

未返信と要対応は同じものですか？

同じではありません。RenRakuの未返信は、届いた問い合わせを開いたものの、まだ返信していない状態です。返信を送ると、自動で返信済に変わります。要対応はステータスとは別の軸の印で、手で付け外しします（返信の送信に失敗したときと、メールが不着になったときは自動で付きます）。返信後も社内の作業が残るなら要対応を付けたままにし、作業が終わったら外すと区別しやすくなります。

RenRakuでステータスの種類を増やせますか？

増やせません。RenRakuの対応ステータスは、未読・未返信・返信済の3つで固定です。それ以上の区別は、カラータグと要対応の印（どちらも全プラン）、案件の段階ごとに問い合わせを分けるルームグループ（スタンダード以上）で表します。状態を自社の言葉で定義したい、状態ごとの件数を集計したい場合は、その機能を標準で持つヘルプデスク製品のほうが適しています。

顧客の返事待ちが長引いた問い合わせは、どう追いかければよいですか？

返事待ちにした時点で「次に見る日」を決め、メモやタスクに残します。RenRakuでは、顧客から返事が来ると問い合わせが未読に戻るので、届いたことには気づけます。一方、返事が来ないまま日が過ぎても、状態は返信済のまま変わりません。決めた日に見返さないと埋もれます。催促が必要な案件は、タスクに催促の期限を設定すると、48時間前と24時間前に画面上で通知されます（タスクはスタンダード以上の機能です）。

確認した公式情報

情報確認日：2026年9月27日。料金・機能・利用条件の最新情報は各公式ページでご確認ください。本文のルール表・遷移表・運用の対応づけは説明用の例です。

• RenRaku公式：機能・料金・FAQ
• LINEヤフー for Business「LINE公式アカウント マニュアル：チャット」（要対応・対応済みの振り分け）

次に読みたい記事

• LINEとメールを一元管理する方法｜問い合わせの返信漏れ・二重対応を防ぐ運用
• 問い合わせ管理ツールの乗り換え手順｜履歴・権限・窓口を移行前に確認