システムの主な機能要件：
- 割引の計算、価格シェアの適用
- チェックの処理（発生/ポイントの控除）
- ポイントカード管理プロセスの自動化
- 顧客ベースの維持
- マーケティングキャンペーンの実施
そして、要件の1つであるロイヤルティカードを管理するためのビジネスプロセスの自動化に焦点を当てます。
ロイヤルティカードの使用に関するカスタマーサポートは、会社のサービスセンターが処理します。 従業員によって実行されるカード上のすべてのアクションは、CRMシステムに記録する必要があります。
カードを使用するビジネスプロセスは、次のタイプに分類されます。
- 顧客検索
- 顧客データを変更する
- カード発行
- カードの交換
- カード所有者の変更
- カードロック
会社のロイヤルティプログラムでは複数の種類のカード（標準、ゴールドなど）を使用しているため、システムごとに個別のプロセスを作成する必要がありました。 カード発行手順もいくつかのタイプに分けられます。たとえば、カードはさまざまな株式に対して発行でき、それぞれの場合、ビジネスプロセスは異なります。
説明されているプロセスを自動化するために、Siebel Task UIを使用することが決定されました。
Oracle Siebel CRMの標準インタフェースとは異なり、タスク（タスク）は一連の画面であり、ビジネスプロセスのロジックに従って順番に配置されます。 このため、ユーザーは追加の資格を必要としません。また、チェックとデータクリーニングシステムにより、入力時のエラーの可能性が減り、データベースに保存されたデータの品質が保証されます。
タスクの使用中に、オペレーターは画面を前後にナビゲートしたり、プロセスを一時停止したりできます。 一時停止したタスクは受信トレイフォルダーに配置され、後で実行に戻ったり、システムの別のユーザーに再割り当てしたりできます。
Siebel Task UIの主な強みはトランザクションです。 ユーザーがタスクセッション中に入力するデータは、一時テーブルに保存されます。 データベースへの書き込みは、タスクが完了するか、プロセスの特定の段階を通過するときに発生します。 この時点まで、他のユーザーはすべての変更を利用できません。 キャンセルの場合、データは削除されます。
Siebel Task UIのもう1つの利点は、「視覚的な」開発プロセスです。ほとんどの場合、スクリプトを使用する必要はありません。 ロジックが少し改善された場合、変更をコンパイルする必要はありません。その結果、サーバーを再起動します。
これらの機能により、既存の機能のサポートが大幅に簡素化されました。
すべてのプロセスのエントリポイントとして、「クライアント検索」タスクが使用されます。 検索は、カード番号、名前、電話番号などのさまざまなパラメーターによって実行されます。 クライアントが見つかると、残りのタスクを使用できるようになります。
顧客の要件に応じて、選択したカードタイプで利用可能なタスクのみをオペレーターに表示する必要があります。 この目的のために、個別の画面が開発されており、それぞれの画面で対応するタスクグループを使用できます。
さらに、いわゆる「一般」グループはすべての画面で利用でき、いつでもクライアントを再検索したり、以前に見つかったクライアントの個人データを変更したりできます。
所有者を変更したり、カードをロック/ロック解除すると、これらの操作は監査機能を使用して記録され、その結果、変更がいつ誰によって行われたか、およびフィールドの初期値が表示されます。
クライアントの個人データの品質（データ品質）を確保するために、別のソフトウェア製品が使用されました。 データベースにデータを保存すると、リモートシステムに要求が行われます。その結果は、クライアントの「クリアされた」名前、電子メール、および電話番号です。 データがディレクトリで利用できない場合、変更は行われず、アンケートには適切な品質コードがマークされます（「検証が必要」）。 アドレスを入力するとき、KLADRディレクトリが使用されます。これにより、存在しないアドレスを入力する可能性もなくなります。
ビジネスプロセスの機能の1つは、カードからカードへのポイントの転送です。 たとえば、カードを交換した場合、ポイントを古いカードから新しいカードに移行する必要があります。 カードがブロックされた場合、このカードに直接蓄積されたポイントを表示するには、残高を調整する必要があります。
Siebel Loyaltyモジュールの基本概念に従って、カード残高はポイントの発生/控除のセットであるため、残高を変更するすべてのアクションは、ポイントのタイプごとに別々の複数のトランザクションで実行されます。
2番目の機能は、誕生日のボーナスの再計算です。これらは、クライアントが特定の期間（誕生日の前後）に使用できるポイントであり、リセットされます。 カード名義人の変更または名義人の生年月日の変更が発生した場合、利用可能なボーナスの額は新しい日付に基づいて再計算する必要があります。 この場合、ポイントの「蓄積」期間中にクライアントが新しいカードを受け取ったという状況が発生する可能性があります。 この場合、再計算時に古いカードの残高も考慮する必要があります。
将来的には、システムの開発として、CRMシステムに基づいたコンタクトセンターの実装が計画されています。 ユーザーのリクエストは、サービスリクエストの形式でオペレーターによって記録され、サービスセンターの従業員に割り当てられます。 上記のタスクを使用すると、サービスリクエストも作成されるため、最も便利な形式でカスタマーサービスに関する完全な統計情報を受け取ります。