チームメイトを部門にグループ化し、プロジェクトの可視性と共有メールボックスへのアクセスを、実際にその人が働いているグループに絞り込みます。 サポート、営業、マーケティングは、既定でお互いのキャンペーンや顧客とのやり取りを読まなくなり、部門リーダーは毎回アカウントオーナーを介さずに自分のグループ内で招待でき、個別メールボックスは、オーナーが理由を要する記録付きのオーバーライドで開かない限り非公開のままです。
少人数を超えて成長したMailInAppアカウントには、かつて視認性モデルが1つしかありませんでした: アクティブなエディターやビューアーは全員、アカウントが所有するすべてのプロジェクトとすべての共有メールボックスを見ていました。誰もがどのみちすべてを見ている小規模なチームであれば、それで問題ありません。それが問題になり始めるのは、「チーム」が別々の機能グループを意味するようになった瞬間です — 顧客とのやり取りに対応するサポート、独自のキャンペーンを運営する営業、独自のキャンペーンを運営するマーケティング — あるグループが別のグループのものを閲覧する本当の業務上の理由がないままに。
部門は既存のロールの上に重なる
部門はオーナー/エディター/ビューアーのロールを置き換えるものではありません — その中でエディターやビューアーが見られるものを絞り込みます。アカウントオーナーは設定から部門を作成し、チームメイトを1つ以上の部門に割り当てます。それ以降、部門でタグ付けされたプロジェクトや共有メールボックスは、その部門のメンバーとオーナーにだけ表示されます。部門が設定されていないプロジェクトやメールボックスは、以前とまったく同じように振る舞います: アカウント全体に表示されます。
部門リーダーが招待の負担をオーナーから引き受ける
チームメイトを自分の部門のリーダーに昇格させると、新しい人を直接その部門へ招待できるようになります — 単なる肩書きではなく、実際の権限委譲です。リーダーの権限は自分の部門の境界で止まります: 自分が運営していないグループには招待できず、請求や認証情報には触れられず、他のリーダーを任命することもできません。すでにオーナー専用となっているもの — SMTP設定、Stripe Connect、APIキー、Webhookシークレット、チーム管理そのもの — はリーダーにとってもオーナー専用のままです。
個別メールボックスは非公開であり、開けなくなっているわけではない
support@のような取得済みの受信アドレスは、部門全体で共有することも、個別に設定して特定の1人に割り当てることもできます。個別メールボックスは通常の業務連絡のために会社所有のアドレスを使うため、技術的に完全に閉じてしまうと、退職した従業員のメールボックスが永久に復元不能な会社のデータになってしまうという、実際の事業継続性を犠牲にすることになります — 会社ドメイン上の業務連絡について、法律が実際には要求していないプライバシー保証と引き換えに。代わりに、オーナーが他人の個別メールボックスに入る唯一の方法はオーナーアクセスです: メールボックスを選び、理由を伝え、それから読む — 割り当てられた人に代わって返信することは決してありません。このアクセスは記録され、その記録は後でメールボックスの担当者本人にも見え、隠されることはありません。
招待を承諾する全員が、まずその意味を目にする
部門はチームメイトが見られるものを変え、また個別メールボックスへのオーナーアクセスが可能であるため、招待承諾ページは、誰かが参加する前に、短く平易な言葉での通知を表示します: 自分の部門が何を可視化するのか、そしてオーナーアクセスは常に理由が必要で常に記録される、という点です。別途設定すべき同意フローはありません — 招待を承諾することは、その通知を確認したことを意味します。
変わらないこと
部門内のエディターとビューアーの権限は、これまでとまったく同じままです — 部門にスコープされたエディターは、自分が見られる範囲について引き続き構築・送信・回答の閲覧ができ、部門にスコープされたビューアーは引き続き読み取り専用です。ボリューム上限、プラン階層、認証情報のローテーションルールは、これによって一切変わりません — 部門は可視性の層であり、新しい料金軸でも新しい書き込み権限でもありません。
はじめに
設定→チームから、自社の実際の組織構造に合わせて部門を作成し、チームメイトをそこに割り当て、作成ピッカーから新しいプロジェクトに部門をタグ付けします。完全なリファレンスは部門を、その下でロールと招待がどう機能するかはチーム協働を、部門が絞り込む共有・個別アドレスの設定方法は受信メールボックスを参照してください。