共有メールアドレスの運用が限界。問い合わせ管理ツールを2製品に絞る

1つの共有メールアドレスに、社外からのメールの大半が集まる。それを Gmail のフィルターで各チームに振り分けて、みんなで返す。人が少ないうちは、これで十分回る。

ある会社（約70〜100名がこの共有アドレスに関わる）で、この運用が限界に来ていた。問い合わせ管理ツールを入れるか、今の Google Workspace の中で工夫して乗り切るか。この1か月ほど、その検討を手伝っている。4製品と「ツールを入れない案」を比べ、2製品に絞り、今週からトライアルに入った。この記事は、まだ製品を決める前の、検討の途中の記録だ。そもそもなぜツールを検討しているのか、何で絞ったのか、トライアルを始めて気づいたことを書く。

▼そもそも、なぜツールを検討しているのか

相談の発端は「今のメール運用を見直したい」だった。ツールを入れたい、ではない。困りごとを並べると、こうなった。

困りごと	何が起きているか
転送が止まる	Gmail の転送の上限に当たって、チームにメールが届かず業務が止まったことがある
ログインできない	共有アドレスは1つの Google アカウント。複数人がログインすると本人確認で止まる。過去には不正利用を疑われて一時停止されたこともある
誰が対応するか見えない	誰が担当で、誰が返したかがわからない。二重対応は運用の工夫でなんとか避けている
振り分けの保守が重い	チームへの振り分けのフィルターが100件近い。取引先や組織が変わるたびに誰かが直している
返信の速さを測れない	指標にしたいが、今は GAS で無理に集計している

未返信の検知は、先に GAS で仕組みを作って急場をしのいだ。だが上の表のうち、GAS で直せるのは最後の1つの一部だけだ。転送の上限と同時ログインは、共有アドレスを1つの Google アカウントで回している限り、構造的に残る。

▼「ツールを入れない案」は、同じ物差しで比べてからやめた

ツールを入れるかどうかを決めるとき、比較表には必ず「入れない案」を入れる。今回は「Google Workspace の設定と GAS の改善で乗り切る案」だ。費用はかからないし、現場の運用も変わらない。

調べてみると、Google Workspace には共有の受信トレイの機能があるが、この会社のエディションでは使えなかった。そうなると、入れない案で解決するのは「見えにくさ」の一部だけで、転送の上限・同時ログイン・フィルターの保守は残る。社内の会議でこの比較を見せ、「Google Workspace の中で工夫する路線は採らない」と決まった。

最初から「ツールありき」で比べていたら、この判断に説得力はなかったと思う。入れない案と並べて、入れることで何が消えて、何が残るかを見せたから、決裁する人が納得できた。

▼4製品から2製品に絞った物差し

候補は、楽楽自動応対・yaritori・Zendesk・メールワイズの4製品。2週間で順に商談した。商談の前に要件の一覧を作り、全部を同じ物差しで見た（作り方は別の記事に書いた）。そのうえで、この会社の要件ではこう絞った。

製品	判断	理由（この会社の要件で）
楽楽自動応対	残す	必須の要件をほぼ満たす。共有アドレスのメールを製品の中で受けて、製品の中で返す。運用の変わり方は大きい（Gmail 側に送信の履歴が残らない）
yaritori	残す	必須の要件をほぼ満たす。Gmail 側にも送受信の履歴が残り、見た目も Gmail に近い。今の運用からの変わり方が小さい
Zendesk	外す	問い合わせを「チケット」で管理する本格的な製品。メールの窓口だけに使うには機能が多く、返信する人数が多いと費用がかさむ
メールワイズ	外す	費用は最も安い。ただ、チーム単位の自動振り分け・API・SSO の確認が取れず、必須の要件を満たしきれなかった

残した2製品は、費用の水準がほぼ同じだった。違いは運用の変わり方と、導入後の支援の手厚さだ。どちらも「止まらない」「物量に耐える」という、事業部がいちばん重視していた点はクリアできる見込み。画面の見栄えは「二の次」と事業部の責任者が言い切ってくれたのも、絞り込みを早くした。

▼トライアルを始めた日に気づいたこと

2製品のうち、yaritori のトライアルを先に始めた。申し込みの手続きはなく、打ち合わせのその場で URL をもらい、環境を作り、共有アドレスの Gmail をつなぎ、メンバーを招待するところまで進んだ。もう1つの製品は、トライアルでも法務の確認を通す必要があり、開始は来週になる。同じ「トライアル」でも、始めるまでの重さがまるで違う。

進めながら、このトライアルは本番と同じ環境だとわかった。営業担当の説明では、そのまま本番に切り替えられ、招待した席の数だけ料金がかかる。裏返すと、次のことを先に決めておくべきだった。

• ▶ 最初のアカウントを誰の名義で作るか。最初の1人がそのまま持ち主になる。今回はその場の流れで、外部の立場の自分のアドレスで作ってしまった。本導入の前に、会社側の管理者に持ち主を移す
• ▶ 採用しないときに、いつ・どう止めるか
• ▶ Gmail をつなぐと、過去のメールが全部入る。つないだ瞬間に「未対応」が約80件並んだ。連携でどこまでの権限を渡したか、もう1製品と並行して同じアドレスをつなぐときの影響は、まだ確かめていない

トライアルの期間は短い。最初の1週間は事業部の2名が触り、その感触で広げる範囲を決める。SSO のような管理の機能は「できる」とわかれば足りるとして、現場の振り分けの運用（今の Gmail のラベルを、タグと自動振り分けで再現できるか）の確認に時間を使う。

▼このあと

10月中に製品を決め、年明けに一部のチームで本導入、4月以降に事業部全体へ広げる予定だ。製品が決まったら、決め手と、トライアルで何が起きたかを続きとして書く。

▼まとめ

• ▶ 共有アドレスを1つの Google アカウントで回す限り、転送の上限と同時ログインの問題は構造的に残る
• ▶ 「入れない案」と同じ物差しで比べてから、入れると決める
• ▶ 候補が同じ水準なら、違いは運用の変わり方。最後は現場が触って決める
• ▶ トライアルが本番と同じ環境なら、名義と止め方を先に決める