日々の業務で判断と担当を明確に
拠点名だけでは、顧客は入口を見つけられず、担当者も正確な案内を維持できません。Tsumiraでは拠点ごとに名称、アクセス情報、公開状態を持つレコードを作ります。
機能ごとの詳しい説明
それぞれの機能でできること、使い方、チームの業務とのつながりを確認できます。
場所を識別できる情報をそろえる
安定したスラッグと日本語名称、任意の英語情報を登録します。住所、最寄り駅、徒歩分数、目印、座標などは、事実を確認したうえで加えます。 拠点には日本語名称、任意の英語情報、住所、最寄り駅、徒歩分数、目印、任意の緯度・経度などを登録します。実際の場所と一致する情報を保ちましょう。入口や集合場所が住所だけでは分からない場合は、具体的な案内を加えます。
- 拠点ごとに名称と公開先を管理します。
拠点を軸に変更を調整する
入口変更などの情報を個人のメッセージに埋もれさせず、拠点のレコードに関連する相談や対応として扱います。現地情報の確認者と公開文の承認者を決めておきます。 拠点は下書き・確認中・公開の状態を経て管理します。公開ページは公開済み情報の限定された表示を使い、内部の相談や対応事項は業務側のレコードで扱います。名称、説明、アクセス情報を変えた後は、公開先と言語ごとの表示を確認してください。
- 拠点を社内の調整の文脈にします。
役に立つ案内を公開する
公開前に拠点の状態と表示内容を確認します。営業時間は現在会社情報から提供します。支店独自の時間がある場合は、構造化された個別予定があると想定せず、適切な説明を加えます。 営業時間は現在、拠点ごとの構造化された週間予定ではなく会社情報として管理します。支店で異なる場合は公開説明などで補い、表示結果を確認する必要があります。拠点別の祝日ルール、現在の混雑状況、予約の空き状況を提供する機能ではありません。
- 実際の場所と合うアクセス情報を公開します。
具体的な業務の流れ
必要な情報をそろえる
実際の住所、入口、目印を確認し、変更を確認する担当者を決めます。
判断内容を確認する
拠点のレコードと言語別の説明を準備します。不確かな案内は担当者が確認してから登録します。
処理結果を確かめる
公開状態と実際のページを確認し、会社の営業時間と支店固有の説明がどう表示されるかを確かめます。
実務を想定した例
業務の進め方の一例
同じ建物の反対側に打ち合わせ用の入口が移ります。担当者がアクセスを更新し、同僚は拠点の情報に関連付けて変更を相談します。公開ページと会社の営業時間表示を確認してから顧客に案内します。文章を直したことが、混雑状況や予約可能時間の更新を意味するわけではありません。
この機能についての質問
複数の拠点を登録できますか？
別々の拠点レコードと公開用の識別情報を管理できます。それぞれ実際の住所と適切なアクセス説明を登録します。
営業時間は支店ごとに保存しますか？
現在は支店ごとの構造化された週間予定ではなく会社情報です。異なる時間は説明を補い、公開結果を慎重に確認します。
座標で追跡やライブ地図を使えますか？
緯度・経度は場所の位置を表す情報です。それだけで追跡、混雑状況、特定の地図連携が提供されるわけではありません。
内部メモは公開されますか？
公開は許可された拠点情報の投影を使い、内部の相談とは区別します。ただし、告知前には実際の表示を確認してください。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
