Excel限界の問い合わせ管理：次手はSaaSか開発か

この記事の要点

Excelで問い合わせ管理を回し切っているのに、重複・漏れでクレームが増える…。それは担当者の頑張りではなく仕組みの限界です。本記事はシステム開発問い合わせ管理をスプレッドシートで限界まで回した後の次手を、業務フロー×要件定義×SaaS比較×フルスクラッチの掛け算で整理します。

導入：Excelで回し切った先に“事故”が増える理由

問い合わせ管理をスプレッドシート（Excel/Googleスプレッドシート）で限界まで回していると、ある日を境に「重複」「漏れ」「担当たらい回し」が増え、クレームにつながります。原因は担当者の頑張り不足ではなく、件数増加と同時に発生する“構造的な破綻”です。

スプレッドシートは「一覧性」と「共有の手軽さ」が強みですが、問い合わせ管理に必要な一意性（重複を防ぐ仕組み）、責任の固定（担当と期限）、履歴の集約（会話の一本化）が、件数増加とともに維持しづらくなります。結果として「見えているのに追えない」「更新したのに伝わらない」「誰かが気づく前提」になりやすいのです。

この記事ではシステム開発問い合わせ管理をスプレッドシートで限界まで回した後の次手として、SaaS導入・業務フロー整備・要件定義・フルスクラッチの判断を横断（掛け算）で整理します。今の運用を否定せず、次の一手を最短で決めるための材料をまとめます。

ポイントは「ツール導入」そのものではなく、業務フロー×ルール×仕組みを同時に整えること。ここを押さえると、SaaS導入でも個別開発でも、移行後に現場が回りやすくなります。

結論：次手は「見える化→標準化→仕組み化」の順で掛け算する

次手は“ツールだけ”で決まりません。問い合わせの入口（フォーム/電話/メール/LINE）と、社内の業務フロー（受付→分類→担当→対応→完了→ナレッジ化）をセットで整える必要があります。結論としては、①現状の業務フローを見える化し、②対応ルールを標準化した上で、③SaaSまたは個別開発で仕組み化するのが最短です。

「Excelが限界」と感じた時点で、まずは“事故が起きる箇所”を特定し、投資先を決めましょう。たとえば、漏れが多いなら「未対応検知と通知」が最優先、重複が多いなら「一意キーと統合」が最優先、引き継ぎが弱いなら「履歴の一本化と検索性」が最優先です。

掛け算（横断）の意図は、システム開発だけで解決しないからです。ツールを入れても運用ルールが曖昧なら事故は続きますし、運用を整えても入口が散らばっていると履歴が割れます。だから「入口・業務フロー・要件」を一緒に整えるのが最短です。

よくある失敗：重複・漏れでクレームが起きるパターン

スプレッドシート運用の典型的な詰まりどころは次の通りです。どれも“人が気をつければ回る”と思われがちですが、件数が増えるほど再現性が落ちます。

同一問い合わせの重複：メール転送、CC、フォーム再送、電話メモの二重登録で、担当が二重に動く。
対応漏れ：担当割り当てが手作業、フィルタや並べ替えで行が見えなくなる、ステータス更新忘れ。
最新情報が分からない：複数シート・複数版が存在し、どれが正か判断できない。
引き継ぎが弱い：履歴が散在し、別担当が過去対応を追えず、同じ質問を繰り返す。
優先度が崩れる：緊急案件も通常案件も同じ一覧に並び、対応順が“声の大きさ”で決まる。

件数が増えると、更新の手間が増えるだけでなく「誰が責任を持つか」が曖昧になり、結果としてクレームが増えます。スプレッドシートは「一覧」には強い一方で、通知・期限・エスカレーションのような“事故を防ぐ仕組み”が弱いからです。

もう一つの落とし穴は、改善が“部分最適”になりやすいことです。たとえば列を増やし、色を付け、フィルタを作っても、入口が増えると履歴は割れます。担当が増えると更新の粒度も揃わず、運用ルールの差がそのまま事故になります。

業務フロー問い合わせ管理をスプレッドシートで限界まで回した後の次手

掛け算（横断）の最初の一手は、ツール選定より先に業務フローの棚卸しです。問い合わせ管理は“受付表”ではなく“処理工程”なので、工程ごとに詰まりを見ます。

入口の整理：フォーム/メール/電話/LINEをどこに集約するか。入口ごとに担当が違うなら、一次受付だけでも一本化できないかを検討します。
分類ルール：種別（見積/不具合/相談/採用など）と優先度（緊急/重要）を定義。分類が曖昧だと、担当割当も期限設定も崩れます。
担当割当：自動割当か、当番制か、一次受付→二次対応の分業か。責任が固定されないと漏れが増えます。
SLA（返信目安）：初回返信の目標時間、営業時間外の扱い。顧客の期待値を揃えるだけでもクレームは減ります。
完了条件：何をもってクローズか。未完了が残らない仕組み（保留の扱い、再オープン条件）まで決めます。

この5点が決まると、SaaSでも個別開発でも“必要な機能”が明確になります。逆に、ここが曖昧なままツールを入れると「入力項目が多い」「手間が増えた」「結局Excelに戻る」が起きやすいです。

補足として、業務フローの棚卸しは“きれいな図”を作ることが目的ではありません。目的は、漏れが起きる瞬間（責任の空白）と、二重登録が起きる瞬間（入口の分散）を特定することです。ここが分かれば、投資の優先順位がはっきりします。

要件定義問い問い合わせ管理をスプレッドシートで限界まで回した後の次手

次に必要なのが要件定義です。ここで大事なのは「機能の希望」ではなく、事故（重複・漏れ）を防ぐための要件を先に固定することです。

一意キー：問い合わせIDを自動発行し、入口が違っても同一案件を統合できる。メール件名頼みは危険なので、ID運用を標準にします。
ステータス管理：未対応/対応中/保留/完了の遷移ルールを定義。「保留」を放置しない仕掛けが重要です。
担当・期限：担当者、期限、リマインド、エスカレーションを必須化。期限がない案件は放置されやすいので、原則“期限必須”が安全です。
履歴：やり取り、内部メモ、ファイル添付の保管先を一本化。顧客への返信履歴と社内メモは区別できると運用が楽です。
権限：閲覧範囲（部門/顧客情報）と監査ログ。個人情報が絡む場合は“誰が見た/変えた”が残る設計が必要です。

この要件が曖昧だと、SaaSを入れても運用が混乱し、フルスクラッチでも“Excelの再現”になってしまいます。よくあるのが「一覧と入力画面だけ作ったが、通知も期限もなく、結局漏れる」という状態です。

要件定義では、さらに「外部との接点」も明確にします。例として、フォーム送信後の自動返信、担当割当通知、Slack/Teams通知、顧客へのテンプレ返信、FAQ/ナレッジ化の導線など。問い合わせ管理は単体で完結せず、周辺とつながるほど事故が減ります。

SaaS 比較問い合わせ管理をスプレッドシートで限界まで回した後の次手

多くの現場では、まずSaaS（問い合わせ管理/ヘルプデスク/CRM）での立ち上げが現実的です。比較の観点は「機能の多さ」より、現場の事故を減らせるかです。

入口の集約：メール/フォーム/チャット/LINEなどを取り込めるか。入口が減るだけで重複と漏れは減ります。
重複検知：同一顧客・同一件名の統合や関連付けができるか。IDの扱いも確認します。
自動化：自動割当、テンプレ返信、タグ付け、期限リマインド、エスカレーション。
検索性：履歴とナレッジが探せるか（新人が迷わないか）。検索が弱いと引き継ぎコストが下がりません。
外部連携：Slack/Teams、会計、基幹、Google Workspace等と連携できるか。
権限・監査：閲覧制御とログが残るか。スプレッドシートの共有より安全に運用できるか。

スプレッドシートの限界を超えるには、通知・期限・履歴の三点セットが強いSaaSを優先すると失敗しにくいです。逆に、画面がきれいでも通知が弱いと、結局“人が見に行く運用”に戻ってしまいます。

また、SaaS導入では「移行」の設計が重要です。いきなり全件移すのではなく、まずは新規問い合わせだけSaaSに集約し、並行期間を置くと現場が混乱しにくいです。ナレッジ化も、最初から完璧を目指さず「よくある10件」から積むのが現実的です。

フルスクラッチ：いつ選ぶべきか、選ばないべきか

フルスクラッチ（個別開発）は万能ではありません。選ぶべき条件は、SaaSでは埋められない“業務の固有性”が明確なときです。

選ぶべき：基幹システム連携が必須、独自の審査/承認フローがある、データ要件が厳しい、権限が複雑、オンプレ/特定クラウド要件がある。
避けたい：要件が固まっていない、まず事故を減らしたいだけ、運用ルールが未整備、担当者が不足している。

基本はSaaSで運用を固める→足りない部分だけ開発の順が安全です。掛け算（横断）で「業務フロー×ツール×運用体制」を同時に整えると、移行もスムーズになります。

どうしてもフルスクラッチを選ぶ場合でも、いきなり全部作るより、問い合わせID・ステータス・期限・通知・履歴の“事故防止コア”から先に作り、周辺機能は後で足す方が手戻りを減らせます。

チェックリスト：Excel卒業の判断を10分で固める

次の項目に当てはまるほど、スプレッドシート運用は“事故前提”になります。該当が多い場合は、SaaS導入か開発の検討を急ぐ価値があります。

問い合わせが月○件を超え、一覧の追跡が困難になっている
未対応の検知が人依存（フィルタ/目視/口頭）になっている
担当割当が手作業で、期限やリマインドがない
入口が複数（メール/電話/フォーム/LINE）で履歴が分散している
重複登録が起き、二重対応や行き違いが発生している
引き継ぎに時間がかかり、同じ質問を繰り返している
対応状況のレポート（件数/カテゴリ/対応時間）が出せない
個人情報や権限管理が不安で、監査ログも残らない
担当者が増え、入力ルールが揃わなくなっている
「誰が最後に触ったか」が分からず、最新が不明になる

よくある質問

まず何から着手すれば最短ですか？

ツール選定より先に、入口の種類と業務フロー（受付→分類→担当→期限→完了）を1枚で整理するのが最短です。ここが固まると、SaaS比較も要件定義も一気に進みます。合わせて、漏れが起きる工程に「期限・通知」を入れる設計を先に決めると事故が減ります。

SaaSを入れても現場が使わないのが不安です

原因の多くは「入力項目が多い」「運用ルールが曖昧」「責任者がいない」です。必須項目を最小にし、ステータスと期限だけは必ず更新するルールにすると定着しやすくなります。最初は“全部を管理する”より“漏れをなくす”に目的を絞るのがコツです。

スプレッドシートのまま改善する余地はありますか？

短期的にはあります。問い合わせIDの採番、入力フォームの統一、ステータスのプルダウン化、期限列、条件付き書式、更新担当の固定などで事故は減らせます。ただし件数が増えると限界が来るため、並行して移行計画を立てるのがおすすめです。

フルスクラッチの見積が高いのはなぜ？

画面や一覧だけでなく、権限・監査ログ・通知・検索・データ移行・運用保守まで含めると工数が増えるためです。要件定義が甘いと手戻りも増えるので、先に業務フローと必須要件を固めるのがコスト削減になります。

まとめ＋CTA：次手は“ツール導入”ではなく“仕組み化”

Excelが限界になった問い合わせ管理は、業務フロー×要件定義×ツール選定を掛け算で進めると失敗しにくいです。まずは重複・漏れが起きる工程を見える化し、SaaSで早く事故を減らすか、固有要件が強いなら段階的に開発へ進めましょう。
エリアドライブでは、現状整理だけのスポット相談から、要件定義・SaaS比較・移行設計まで伴走できます。まずは「今のExcelでどこが危ないか」だけでも一緒に切り分け可能です。