管理者グループ
問題解決は行わないがシステム利用者の追加・削除・修正やプロジェクトの追加・削除・修正等を行う。ただ、システムの全ての制御する権限を持つ。なるべく技術に特化しない作業にとどめておく。
オブザーバグループ
社内の他のプロジェクト担当者等、システム保守自体を実際に行っていない人（コンサルタント等）を選定する。主にコメントのみに留め実際の対応はワーカが行う。
マネージャグループ
保守チームのマネージャが相当する。「解決」した問題をエンドユーザにリリースする。その他リーダが行える操作を全て実行可能。
リーダグループ
主に保守チームリーダが相当する。主に問題対応者をワーカの中から選定し、対応者としてアサインしたり、「修正済み」状態になった問題を「解決」する。その他ワーカが行える操作を全て実行可能。
ワーカグループ
主に保守チームメンバが相当する。問題解決を行う人々が想定される。その為、問題に対するコメント（問題の状況報告・原因報告・解決手段）や問題の状態変更（「修正済み」まで）が可能。また、ワーカが行える操作を全て実行可能。
ユーザグループ
主に消費者やエンドユーザが利用。その為、問題の投稿や問題の状態の閲覧・コメントログのアップロードなどが可能。 もちろんこれらは「役割＞システム利用者」となっても問題ありません。その場合システム使用者は多数の役割を兼任します。最低でもこの位の役割は決めておくべきでしょう。
レベル別役割分類（大規模システム向け）
「グループ別役割分類」の場合、これだけでたいていのシステムで対応可能ですが、この後、ヘルプグループや営業グループ等、ワーカグループ等と同じような権限をもつグループを追加する場合等に作業が少しずつ煩雑化してゆきます。 これらを解決する手段としてあらかじめグループによる定義ではなくレベルで定義するという方式があります。レベル別の定義はよくセキュリティにおいて使われています。
各レベルがどのような役割・権限をもっているかは細かく定義しておく必要があります。また、レベルは追加することがほとんどなのでレベルの範囲は１～１００までのようにあらかじめ大きく設定しておくと後で困らなくなるでしょう。 なお、「グループ別役割分類」における「オブザーバグループ」のように必ずしも下位レベルの権限全てを保持するわけではない、という場合に柔軟性を欠きますので事前に検討しておく必要があります。