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

この記事の要点

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

Excelで問い合わせ管理を続ける条件と限界

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

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

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

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

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

システム化の相談

フォーム、予約、CSV、会員機能などを業務に合わせて整理できます

システム開発は機能を増やすほど複雑になります。今ある業務フローを整理し、最初に作るべき範囲と後回しにする範囲を切り分けることが重要です。

• 手作業やExcel管理を減らしたい
• フォーム、予約、会員、CSV出力をつなげたい
• 小さく始められる開発範囲を決めたい

システム開発を相談する システム開発の詳細を見る

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

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

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

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

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

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

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

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

問い合わせの受付から完了までを業務フローで整理する

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

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

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

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

重複・漏れを防ぐ要件を先に決める

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

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

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

要件定義では外部との接点も明確にします。フォーム送信後の自動返信、担当割当通知、社内チャット、顧客へのテンプレ返信、FAQなどを候補にし、連携が増えるほど権限、障害切り分け、重複通知も増える点を含めて判断します。

問い合わせ管理SaaSを同じ条件で比較する

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

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

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

SaaS導入では移行設計が重要です。新規分から切り替えるか既存履歴も移すかを、検索要件、個人情報、保存期間、監査、旧データの削除で決めます。並行運用する場合は正本を一つにし、終了条件と照合担当を決めます。

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

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

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

一般化せず、既存SaaSの適合度、データ移行、権限、外部連携、保守体制を比較します。SaaSで主要要件を満たせる場合は運用を試し、固有要件だけを部分開発する方法も候補です。掛け算（横断）で「業務フロー×ツール×運用体制」を同時に整えると、移行もスムーズになります。

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

チェックリスト：Excelから移行する判断材料

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

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

よくある質問

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

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

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

使われない原因は、入力項目、運用ルール、責任者、画面、教育、既存業務との二重化など複数あります。必須項目を絞り、ステータスと期限の更新責任を決め、利用率と未対応件数を確認します。最初は“全部を管理する”より“漏れをなくす”に目的を絞るのがコツです。

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

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

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

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

まとめ：ツールより先に責任・期限・権限・保存を決める

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

システム化の相談

フォーム、予約、CSV、会員機能などを業務に合わせて整理できます

システム開発は機能を増やすほど複雑になります。今ある業務フローを整理し、最初に作るべき範囲と後回しにする範囲を切り分けることが重要です。

• 手作業やExcel管理を減らしたい
• フォーム、予約、会員、CSV出力をつなげたい
• 小さく始められる開発範囲を決めたい

システム開発を相談する システム開発の詳細を見る