チャットもカレンダーも入れたのに、来客が来ると内線が鳴り、予定・会議室・社員名簿(マスタ)は別々に動いている。
ツールの機能より先に、どの情報をどのツールが正として持つかを決めると、最初の一手が見えてきます。

ツールは導入済み。でも来客対応は「分断」されている

チャットで済む連絡の横で、来客だけは別の流れで動いています。

来客が来ると、受付の内線が鳴ります。
近くの席の人が電話を取り、担当者の席を見に行きますが、席にいません。
チャットで呼びかけ、返事を待つあいだ、来客は立ったままです。
インターホンが鳴っても誰宛ての来客か分からず、とりあえず気づいた人が用件を聞きに出ることもあります。

来客が気まずそうに立っているのを見かねて、通りがかった別部署の人が慌てて声をかけることもあります。

担当者が会議中や外出中なら、さらに時間がかかります。
在宅の日は、誰が来客を迎えるのかも決まっていません。

予定と会議室も同じです。
来客の予定はカレンダーにあるのに、会議室の予約は別の仕組みで、社員名簿は入社や異動のたびに手で直しています。
一つひとつは小さな手間ですが、同じ来客のために、あちこちを行き来しています。

内線を使わない受付の考え方は、内線を使わず、チャットで来客の知らせを受ける考え方で書いています。

内線をクラウドPBX(インターネット経由で使う電話交換の仕組み)に切り替えるなら、受付の呼び出しも先に決めておきます。
内線をクラウド化するときの、受付とのつなぎ方は、内線のクラウド化が主題の記事で、受付には最後の節で触れています。

ツール単体ではなく、来客対応の「業務フロー」全体を見る

ツールを「作業の代わり」として見ると、チャットは連絡、カレンダーは予定、と別々の箱に見えます。
しかし、来客が来てから記録が残るまでの流れ全体で見ると、同じ来客が、それぞれのツールを順に通っています。
この記事では、この流れ全体を「業務フロー」と呼びます。

たとえば、来訪が申請され、予定に入り、会議室が押さえられ、当日に知らせが届き、入退館の記録が残る。
この流れのどこかで情報が止まると、次の場面で手間が生まれます。

流れの上に並べると、つなぎ目は6つです。

位置づけ

つなぎ目

社員が触る場面

 

事前

申請承認

来訪や入構を申請する人と、承認する人がいる

事前

予定

来客の予定を登録し、担当者が確認する

事前

会議室

会議室を予約し、来客の案内先にする

当日

知らせ

担当者が来客の知らせを受け取る

当日

入退館

来客や外部スタッフが、受付やゲートを通る

土台

社員名簿

入社・異動・退職で名簿が変わる

社員名簿(マスタ)は、ツールごとに持つ社員の一覧です。社員が直接触らなくても、どのつなぎ目にも影響するので、流れの下に土台として置きます。

  • 左から右へ、来客が来てから記録が残るまでの流れを、矢印でつないで置く。
  • 流れの上に、事前の「申請承認」「予定」「会議室」と、当日の「知らせ」「入退館」を並べる。
  • 流れの下に、全体の土台として「社員名簿」を横長の帯で置く。
  • 主役は流れ。ツールごとの箱は描かない。「紙・FAX」だけで今の運用を表さない。

つなぐ前に決めるのは、機能ではなく「持ち主」

連携を考えるとき、先に機能を比べたくなります。
でも、先に決めるのは「持ち主」です。
持ち主とは、どのツールがどの情報を正として持つか、という考え方です。

たとえば、来客の予定をカレンダーに入れ、同じ内容を申請の仕組みにも入力している場面を考えます。
持ち主が決まっていないと、二重に入力することになり、食い違ったときにどちらが正しいか分かりません。
持ち主を決めれば、もう一方は読むだけにできます。

実際には、二重どころではありません。
来客の予定を、カレンダーに入れ、申請の仕組みに入れ、会議室の予約に入れ、担当者にチャットで伝える。
同じ内容を何度も入力し、日時が変われば全部を直します。
一か所だけ直し忘れると、会議室の予約と来客の予定がずれます。

そのずれに気づくのは、来客を会議室の前まで案内したときです。
先に使っている人と来客のあいだに立って、気まずい思いをすることになります。

持ち主とは、1つのツールに全部を寄せるという意味ではありません。
つなぎ目ごとに、正として持つツールを1つずつ決める、ということです。

  • 左・中・右の3列で置く。
  • 左は「お客様が使っているツール」。チャット、グループウェア、ID基盤、入退室管理、紙・FAXを含む運用を並べる。
  • 中央は「間に噛ませる」。受付・代表電話コネクト、調整アポ・予約ルームズ、受付のID連携、受付のゲート連携、ワークフロービルダーを並べる。
  • 右は「整理されること」。知らせ、予定・会議室、社員名簿・認証、入退館、申請・承認を並べる。
  • 読者が、左に自社のツールを見つけ、中央が間に入ることで右が整理される、と読める構成にする。「遅れている現場」という見え方にしない。

各つなぎ目の持ち主は、次の表の候補から選びます。

つなぎ目

持ち主の候補

つなげると楽になる作業

詳しく読む

 

申請承認

ワークフロー、または来訪元の申請の仕組み

申請内容を、受付で入力し直す手間

入構申請は施設側と来訪元のどちらが持つか、外部スタッフの入館を仕組みにした事例

予定

カレンダー

来客の予定を、二重に入力する手間

—

会議室

カレンダーの会議室枠、または会議室の予約の仕組み

来客の案内先を、確認する手間

—

知らせ

チャット

担当者を探して、取り次ぐ手間

—

入退館

入退室管理の仕組み、またはゲート

来客の記録を、別々に残す手間

入退館システム、セキュリティゲートとの連携

社員名簿

総務の名簿、ID基盤、受付のどれか1つ

異動・退職のたびの、更新漏れ

—

不在・異動・退職。何十人・何百人の社員に、機能だけで運用は回るだろうか

個人で使うツールなら、機能で選んで構いません。
使うのは自分だけで、合わなければ変えればよいからです。

しかし、数十人、数百人が使うなら、話が変わります。
全員の席で同じ連携が回り続けるには、機能のほかに、決めておくことがあります。

  • 来客の予定や通知先は、誰がいつ更新するのか。
  • 担当者が不在のとき、来客の知らせは誰に届くのか。
  • 異動や退職があったとき、どのツールの名簿を、いつ直すのか。

たとえば、席替えのあとも、内線が前の席の部署につながる。
異動した翌週も、前の部署の担当者に来客の知らせが届き続ける。
退職した人の名前が、通知先に残っている。
どれも機能の問題ではなく、更新のルールが決まっていない場面です。

権限も同じです。誰が通知先を変えられるのかが決まっていないと、変更の依頼が行き場を失います。

こうした決めごとは、機能の一覧には載りません。
せっかく入れたツールを使い切るために、流れ全体を、更新する人、不在のとき、異動や退職のときまで含めて設計します。
ルールを決めただけで定着するとは限りません。
決めたルールを続けられるかも、運用しながら見直していきます。

名簿の更新と、ログインを一か所にまとめる仕組み(SSO)の持ち方は、社員名簿の持ち方とID基盤の考え方で扱います。

手作業やツールごとの運用で回すのが難しくなった場面で、他社がどう運用しているかは、
3分でわかる!受付システム解説資料の導入事例で見られます。

Microsoft 365の会社/Google Workspaceの会社/Slackで回している会社

主力のツールによって、最初に手を付けるつなぎ目が変わります。

Microsoft 365の会社

毎日開いているのがTeamsとOutlookなら、決めることは二つです。
来客の知らせをどこで受け取るか。来客の予定、会議室、名簿を、どのツールの持ち主にするか。
知らせだけを先に決めるなら、Teamsの側から考えます。
予定・会議室・名簿までそろえるなら、Outlookの側に持ち主を置く話になります。
Teamsで来客の知らせを受け取る場合と、Outlook・会議室・名簿までつなぐ場合に分けて書いています。

Google Workspaceの会社

予定と会議室をGoogleカレンダーで回しているなら、カレンダーを持ち主にして、来客の予定と会議室の空きをどこまで一つの流れにするかから考えます。
知らせの届け先は、そのあとで選べます。
予定から知らせまでの流れは、Google Workspaceで来客・予定・会議室までつなぐ場合で書いています。

Slackで回している会社

普段のやり取りがSlackなら、最初の一手は来客の知らせです。
予定や会議室はこれまでのまま動かし、知らせの届け先だけを先に決める進め方があります。
通知先の決め方や、担当者が不在のときの考え方は、Slackで来客の知らせを受け取る場合で扱います。

全連携は不要。「来客の知らせ」1本から始める業務改善

AppBrewの導入事例では、来客の知らせをSlackで受ける形から始めています。
事例ページによると、導入後2〜3か月で、電話が鳴る環境がなくなりました。

一方で、会議室の管理はGoogleカレンダーのままで、受付とは連携していません。
来客が増えたときに日程調整や会議室管理をそろえていく考えも、事例ページで語られています。

6つのつなぎ目で見ると、動かしたのは「知らせ」です。
予定と会議室は、これまでの運用を残しています。
何を先に切り替え、何を残すかを分けて考える見方ができます。

ニーズウェルの導入事例では、担当者が「『取次する』という業務が一切なくなったんです」と話しています。
内線による取次が減ったことを語る流れの中の発言です。

どちらも、事例ページの記載の範囲です。
知らせの1本から動かし、残りのつなぎ目は必要になった順に決める。
そういう進め方もあります。

社員名簿やSSOの壁。情シスに相談する前に整理しておきたい項目

社員名簿、ログイン、ゲートとの接続は、情シスが持っている領分です。
総務だけで決めようとして、話が止まる場面もあります。

たとえば、来客の知らせの届け先を決めても、その名簿が情シスの管理するIDと別に動いていると、異動のあとに届け先が古いまま残ります。
困っている場面から伝えると、情シスも確認する範囲を絞りやすくなります。

渡すときは、次の4つを聞ける状態にしておくと、話を進めやすくなります。

  • 名簿の更新元は、今どこか。誰が、いつ更新しているか。
  • 異動・退職の反映は、手で直しているか、自動で同期しているか、ファイルで取り込んでいるか。
  • ログインを一か所にまとめる仕組み(SSO)を、すでに使っているか。
  • 入退館のゲートや入退室管理と、来客の記録をつなぐ予定があるか。

確認項目は、情シスに渡す確認項目をまとめた記事にもあります。

まとめ:最初の一手を選ぶ

最初の一手は、次の4点で選びます。

選ぶ軸

決めること

 

主力ツール

Microsoft 365、Google Workspace、Slackのどれが中心か

最初のつなぎ目

知らせ、予定、会議室、社員名簿、入退館、申請承認のどれから始めるか

確認する相手

総務で決められるか、情シスに聞くか

社内ルール

誰がいつ更新し、不在や異動のときどうするか

ツール別の詳細は、Slackで来客の知らせを受け取る場合、Teamsで来客の知らせを受け取る場合、
Outlook・会議室・名簿までつなぐ場合、Google Workspaceで来客・予定・会議室までつなぐ場合に戻って確認できます。

来客の知らせ、予定、会議室、名簿の整理を、受付を軸に進める場合の全体像は、
3分でわかる!受付システム解説資料で見られます。
受付システムの基本機能と導入事例をまとめた資料です。