電気通信請求-クイックガイド

電子メディアを使用して、ある地点から別の地点に音声、データ、画像、ファックスなどを送信することを、電気通信と呼びます。telecom'。例としては、電話、ラジオ、テレビ、インターネットなどがあります。伝送媒体には、ワイヤー（銅）、光ファイバー、エーテル（ワイヤレス）、電波塔、マイクロ波、衛星などが含まれます。

それでは、顧客に満足のいく通信サービスを提供している国際的な通信事業者をいくつか挙げてみましょう。

• Verizon
• Vodafone
• Airtel
• TATA
• Etisalat
• Qtel

また、さまざまな有名な通信事業者によって提供されているいくつかの基本的な通信サービスをリストアップしましょう-

• 音声電話
• ファックスサービス
• SMSとMMS
• インターネット接続
• データのダウンロードとアップロード
• ビデオ会議
• IPベースのサービス、つまりVoice overIPまたはVPN

電気通信事業者はさまざまな方法で顧客に課金していますが、顧客に課金するために主に使用される2つのパラメータがあります-

• Rental Charges−これらは、提供されたサービスに対して毎月顧客から徴収される料金です。たとえば、電話の月額料金は、使用するかどうかに関係なく$ 5.00になります。

• Usage Charges−これらはサービス利用率に基づいて顧客から徴収される料金です。たとえば、電話をかけたすべての通話や、電話を使用してダウンロードしたデータに対して課金されます。

毎月のレンタル料金と使用料金の他に、オペレーターはサービスの開始、インストール、サービスの一時停止、または終了についても料金を請求する場合があります。

電気通信請求は、使用量を収集し、それを集計し、必要な使用量とレンタル料金を適用し、最終的に顧客の請求書を生成するプロセスです。電気通信の請求プロセスには、顧客からの支払いの受け取りと記録も含まれます。

課金システム

非常に複雑な充電シナリオが存在する可能性があり、手動で処理するのは困難です。ソフトウェア市場には、課金タスクを非常に効率的に処理し、さまざまな価格構造でサービスを提供するためにサービスプロバイダーに多くの柔軟性を提供できる最先端の課金システムがあります。

請求システムは顧客からのお金の収集（受け取り）を支援するため、請求システムは売掛金と見なされることがよくあります。顧客はワイヤレスローミング、長距離、他のネットワークを介した通話完了など、他社のサービスを利用することが多いため、請求システムも買掛金の一部です（キャリア間決済の場合）。

課金システムは、さまざまな機能を提供する、ハイエンドで信頼性が高く、高価なソフトウェアです。これが最も重要な機能のリストですが、以下に限定されません。

• Rating & billing −製品またはサービスの使用状況を評価し、毎月の請求書を作成する必要があります。

• Payment processing −顧客の支払いを自分のアカウントに転記する必要があります。

• Credit control and collections −未払いの支払いを追跡し、支払いを回収するための適切な措置を講じることが含まれます。

• Disputes and adjustments −これには、請求に対する顧客の紛争を記録し、紛争を解決するために紛争金額を返金するための調整を作成することが含まれます。

• Pre-pay and post-pay services −プリペイドとポストペイドの両方の顧客ベースをサポートする必要があります。

• Multilingual & multiple currencies −ビジネスが世界中に広がり、多国籍の顧客がいる場合、または政府の規制で要求されている場合は、多言語および複数通貨のサポートが必要です。

• Inter-carrier settlements −お互いの顧客にサービスを提供するキャリア間で収益を共有することを含みます。

• Products & services −これには、さまざまな製品やサービスを維持し、それらを個別にまたはパッケージで販売するための柔軟な方法を提供することが含まれます。

• Discount applications −これには、顧客離れを減らし、顧客ベースを引き付けて増やすために、さまざまな割引スキームを定義することが含まれます。

請求タイプ

請求対象をドリルダウンすると、より複雑になります。このチュートリアルの後半でほとんどの概念をカバーしようとしますが、最初に、広く使用されている請求タイプの概要を見てみましょう。

• Pre-pay Billing−顧客が前払いし、その後サービスの使用を開始する請求メカニズム。通常、プリペイドの顧客は請求書を受け取りません。また、「」と呼ばれる高可用性の課金システムによってリアルタイムで請求されます。IN'（インテリジェントネットワーク）。

• Post-pay Billing−これは、長年にわたって行われている従来の請求です。ここでは、顧客が製品やサービスを購入して1か月を通して使用し、月末までにサービスプロバイダーによって請求書が生成され、それらの請求書が顧客に送信されて支払いが行われます。

• Interconnect Billing:ネットワーク事業者は通常、顧客がサービスの料金を支払うかどうかに関係なく、他のネットワークによって顧客に提供されるサービスに対して金銭的な責任を負います。相互接続の請求は、キャリア間またはいつか呼ばれることに関連していますpartner settlements。

• Roaming Charges−顧客があるネットワーク事業者のカバレッジエリアから別の事業者のカバレッジエリアに移動する場合、最初の事業者は、顧客にサービスを提供するために2番目の事業者にわずかな料金を支払います。このようなタイプの料金は、ローミング請求によって決済されます。この決済は、TAP3プロトコルに従って行われます。これについては、次の章で説明します。

• Convergent Billing−収束請求とは、すべてのサービス料金を単一の顧客請求書に統合することです。コンバージド課金とは、顧客とその顧客に提供されるすべてのサービス（モバイル、固定、IPなど）の統一されたビューを作成することを意味します。

課金システムベンダー

請求システムは、あらゆる通信事業者のバックボーンです。事業者が強力な課金システムを持っていない場合、魅力的なプロモーションや取引で製品やサービスを提供することは不可能であり、最終的には今日の競争が激しくダイナミックな市場に立つことができません。

多くの機能を主張して課金製品を販売している何千ものベンダーを見つけることができますが、市場には本当に優れていて最も一般的に使用されているベンダーがいくつかあります。優れた課金システムのいくつかを以下に示します-

システム	ウェブサイト
Convergys IRB	www.convergys.com
アムドックスアンサンブル	www.amdocs.com
AMSタペストリー	www.amsinc.com/telecom
ケナンアーバー	www.kenan.com
シングルビュー	www.intecbilling.com
ポータルインフラネット	www.intecbilling.com
エリクソンIN	www.ericsson.com

次の図は、課金システムの一般的なアーキテクチャを示しています。

ここでは、2つの可能性があります-

• CRM（顧客関係管理）/ OMOF（注文管理および注文履行）システムは課金システムと連絡を取り、課金システムはプロビジョニングシステムと連絡を取り、サービスとネットワークインベントリシステムをプロビジョニングし、電話番号やIPアドレスなどを割り当てます。

• 2番目の可能性は、CRM / OMOFシステム自体がプロビジョニングシステムと接続して、サービスとネットワークインベントリシステムをプロビジョニングし、電話番号やIPアドレスなどを割り当てることです。

典型的な請求プロセス

上記のシステムアーキテクチャを考慮して：→電話がかけられた後、またはエンドカスタマーによって使用量が生成されたと言えると、メディエーションシステムはネットワークスイッチから使用量データを収集し、 call-detail record（CDR）。このCDRには、「A」パーティ番号と「B」パーティ番号、開始日時と終了日時が含まれている必要があります。

CDRは、評価できるようになるまで保存されます。通話を評価するために、CDRを調べて、通話がたとえば800番号であるか、ローカルエリア通話プランでカバーされている市内通話であるか、国際通話であるか、有料通話であるかを確認します。通話時間や都市コードまたは国コードなどの情報を使用して、通話料金が計算されます。

各通話が評価されると、この情報は請求書が実行されるまで、通常は月に1回保存されます。請求書が実行されると、割引や月額料金などの他の不使用料金が請求書または請求書と呼ばれることもあります。

評価時間の割引または請求時間の割引、顧客によるさまざまな支払い、さまざまな調整が行われる可能性があります。これらの情報はすべて、最終的な請求書の生成に役立ちます。

次に、この情報は、読み取り可能な形式で印刷できる形式に変換されます。最後に、封筒が印刷され、同封物が詰められ、最終顧客に郵送されます。

課金システム要件

課金システムは、一連の独立したアプリケーションで構成する必要があります。これらのアプリケーションを一緒に実行すると、課金システムと呼ばれます。優れた課金システムは、次の主要な機能を柔軟に提供する必要があります-

• Customer-interface Management −課金システムは、顧客が開始した連絡を処理し、顧客からの連絡を監視し、連絡のライフサイクルを管理できる必要があります。

• Order Management−これは基本的な機能であり、通常の課金システムで利用できるはずです。請求システムは、製品とサービスの注文を取得し、注文入力のライフサイクルを管理し、注文完了のライフサイクルを監視するのに十分な機能を備えている必要があります。

• Sales and Marketing −満足のいく請求システムは、顧客の質問に答え、手数料を処理し、販売サポートを提供し、見通しを追跡し、キャンペーンを管理し、製品のパフォーマンスを分析し、複数の住戸を取得する必要があります。

• Rate Plans and Rating −課金システムは、さまざまな製品とサービス、それらの製品とサービスに関連するさまざまな料金プランを管理する必要があり、それらの製品とサービスによって生成された使用量を評価する柔軟な方法を提供する必要があります。

• Discounting −課金システムは、さまざまな使用法やレンタルに対してさまざまな種類の割引を提供できる必要があります。

• Invoicing −システムが請求照会を実行し、請求書を生成し、預金を処理し、口座管理を実行し、税金と手数料の情報を維持し、財務情報を処理することが重要です。

• Credit Control & Collection−課金システムは、さまざまな顧客にさまざまなクレジットクラスを割り当てることにより、使用量と収益を制御する必要があります。システムは、支払いの回収とさまざまな請求書への適用をサポートする必要があります。

• Multilingual Support −多言語サポートには、複数の言語での請求書とカスタマーケアサービスの提供が含まれます。

• Multiple Currencies −異なる国で使用される複数の通貨は、請求およびカスタマーケアシステムが複数の通貨の単位で記録および処理できる必要があるため、請求システムを複雑にする可能性があります。

• Partner revenue management −パートナーの収益管理は、互いの顧客にサービスを提供するキャリア間で収益を共有することです。

• Problem Handling −課金システムは、トラブルチケットの入力を管理し、トラブルチケットの閉鎖を調整し、トラブルチケットの解決の進行状況を追跡できる必要があります。

• Performance Reporting −満足のいくシステムは、パフォーマンスレポートを提供し、サービス品質（QoS）レポートを保証し、管理レポートを作成し、規制レポートを生成します。

• Installation and Maintenance −システムは、従業員のスケジューリングを提供し、顧客宅内で実行されるアクティビティを管理する必要もあります。

• Auditing & Security−課金システムは、データ監査と整合性チェックを実行する必要があります。安全なシステムは、オペレーターにとって常に望ましいものです。

上記の機能とは別に、優れた課金システムは次のようになります。

• 新しいサービスの開始に向けた市場投入までの時間を短縮します。

• 顧客と製品の収束ビューを可能にします。

• 費用対効果の高いアーキテクチャのスケーラビリティをサポートします。

• パートナー関係の管理と決済を可能にします。

• 総所有コストの削減。

次は何ですか？

次の章から、製品とサービスの定義、プランと料金のそれらの製品への関連付け、顧客の獲得（最終顧客への製品の販売）、それらの顧客によって生成された使用量の取得、そして最後に評価までの完全なプロセスについて説明します。そして、それらの顧客に最終的な請求書を送信するためにその使用量を請求します。

Airtelのような通信事業者が独自の課金システムを設定したいとします。次に、Airtelは、請求システムの設定に進む前に、まず販売およびマーケティング部門によって製品とサービスを定義する必要があります。

製品とは何ですか？

製品は論理的または物理的なエンティティであり、オペレーターがエンドカスタマーに売り切ることができます。これには、携帯電話、インターネット接続、音声通話接続、VPN、ビデオオンデマンド、デジタルTV接続などがあります。

製品には月額レンタルがあり、これを定期料金とも呼びます。製品はすることができますusage generating product または non-usage generating product。使用量生成製品はイベント生成製品と呼ばれることもあり、非使用量生成製品は非イベント生成製品と呼ばれます。

たとえば、電話番号に付随する音声通話接続は、エンドカスタマーがこの製品を使用して音声通話を行うたびに使用量を生成するため、使用量生成製品です。接続されていない単純な電話セットは、使用量を生成しない製品であり、月額家賃のみに基づいて顧客に提供することができます。そのため、顧客が使用していない場合でも、月額家賃を支払う必要があります。

サービスとは何ですか？

マーケティングの観点からそれらについて話すとき、ほとんどの場合、両方が異なる請求およびマーケティングの専門家によって交換可能に使用されるため、製品とサービスの間に違いはありません。

簡単に言えば、オペレーターは自社の製品を使用して顧客に音声サービスを提供します。国際電話は、音声通話接続を利用して提供されるサービスと呼ぶことができます。別の例としては、800番の通話が特定のオペレーターを通じて利用できる場合とできない場合があり、キャッチホン、自動転送は、電話機のモデルまたはオペレーターによって提供されるサービスと言えます。

このチュートリアルでは Product and Service用語は同じ意味で。シンプルに保つと、製品は顧客が完全に購入するかリースすることができるアイテムです。製品は-かもしれません

• 実物（携帯電話など）
• サービス（電話システムでのキャッチホンサービスなど）
• より抽象的な概念（たとえば、サービスレベルアグリーメント）

製品ファミリ

関連製品は、製品ファミリにグループ化できます。複数のレベルの製品が可能であるため、製品は同時に親と子の両方になることができます。

さらに、必要に応じて、各製品ファミリに複数の親製品を含めることができます。製品ファミリの例は次のとおりです。

• テレフォニーサービス
• ケーブルテレビ
• Internet
• 専用線

製品グループ（パッケージ）

多くの場合、オペレーターは複数の製品を1つのグループにまとめ、完全なパッケージとして販売します。さまざまな種類の製品をパッケージとしてまとめることをサポートする課金システムがあります。それは割引価格で提供することができます。

パッケージをパッケージの一部として使用すると、製品を割引価格で顧客に提供できます。各パッケージは任意の数の製品で構成でき、これらの製品は複数の製品ファミリから取得できます。

製品のこのパッケージ価格プランは、通常、比較（つまり、非パッケージ）価格プランとは異なります。これは、会社が完全なパッケージを購入するために顧客に割引を提供する方法であるためです。ただし、これは必須ではありません。製品には、パッケージ内で通常の価格プランの1つを割り当てることができるためです。

製品属性

製品には、いくつかの属性を関連付けることができます。製品属性を使用すると、製品のタイプ間で関連情報が異なる場合に、個々の製品インスタンスに関する情報を保持できます。たとえば、有料TV製品には、セットトップボックス番号を記録する属性がある場合があります。

さらに、携帯電話製品には、International Mobile Subscriber Identity（IMSI）およびMobile Station International ISDN Number（MSISDN）を記録するための属性が必要な場合があります。

製品イベントタイプ

製品には、いくつかのイベントタイプを関連付けることができます。これらのイベントタイプは、製品によって生成できるイベントを管理します。

たとえば、携帯電話製品には、音声通話やメッセージングサービスなどのイベントタイプがあります。単一の電話デバイスに関連付けられたイベントタイプはさらに多くなる可能性があり、オペレーターは、顧客によって生成されたイベントごとにエンドカスタマーに請求できます。

課金システムの展望

マーケティング部門がすべての製品、サービス、パッケージ、および関連する価格を確定すると、それらは課金システムで構成されます。

さまざまな課金システムにより、親、子、および孫の製品に関して、製品とその階層を定義するさまざまなレベルの柔軟性が提供されます。

一部のシステムは、パッケージとバンドルをサポートするのに十分な柔軟性があり、一部のシステムは、パッケージと割引価格に関連する限定された機能を提供します。

一部のシステムは、製品カタログを価格カタログとは別に保持して、より優れたモジュラーアプローチを提供します。また、一部の課金システムは、製品の説明、機能、および関連する価格をすべて組み合わせます。

すべての製品、サービス、パッケージ、およびそれらのイベントが課金システムで構成されたら、次のステップはそれらのレンタルと使用価格を定義することです。これについては次の章で説明します。

次は何ですか？

製品またはサービスとパッケージとは何かを理解している場合は、次の章に進んで、任意のオペレーターが利用できるマーケティング部門によって価格がどのように定義されているかを理解できます。

電気通信事業会社のマーケティング部門は、さまざまな製品やサービスのレンタル料金と使用料金を定義するために懸命に取り組んでいます。これらの料金は、他の競合他社や規制を念頭に置いて定義されています。大まかに言えば、異なる課金システムで使用される用語に応じて、料金プランまたは価格プランとも呼ばれる2種類の料金があります。

製品および関連サービスに適用されるさまざまなタイプの料金が存在する可能性があります。特定の製品について、オペレーターは次の料金の1つ以上を定義できますが、これらの料金だけに限定されるものではなく、国、場所、およびビジネス状況に応じて他の種類の料金が発生する可能性があります。

• Product Initiation Charges −これらは1回限りの料金であり、インストール、アクティベーション、サービス、または接続の開始の一部としてお客様から受け取ることができます。

• Product Periodic Charges −これらは、提供される製品およびサービスのレンタルとして、月次、隔月、または年次ベースで適用できる料金です。

• Product Termination Charges −これらは、製品およびサービスの終了時に適用される可能性のある料金です。

• Product Suspension Charges−これらは、何らかの理由で製品が停止された場合に適用される可能性のある料金です。たとえば、不払い。

• Product Suspension Periodic Charges −何らかの理由で顧客が停止された場合でも、定期的に顧客に請求する必要がある場合があります。

• Product Re-activation Charges −何らかの理由で製品が一時停止され、アクティベーションが必要になった場合、オペレーターはこのサービスに再アクティベーション料金を適用できます。

• Product Usage Charges−これは最も重要なタイプの料金であり、サービスの使用状況に基づいて適用されます。たとえば、1分あたりまたは1秒あたりの通話、MBあたりのデータダウンロードなどです。

上記のすべての料金は、規制に応じて、適用される税金を含むまたは含まないさまざまな料金表で定義（つまり構成）されています。これらのカタログは、課金システムごとに異なります。一部の課金システムでは、すべての価格が1つのカタログに保持され、一部の課金システムでは、使用料金が他の料金とは別に保持されます。

これらのカタログは課金システムで管理されますが、フロントエンドシステムでも利用できるため、顧客アカウントの作成時にさまざまな料金を顧客に適用できます。

すべての価格は、製品とそのパッケージにも基づいて定義されています。さまざまなパッケージでさまざまな価格を提供する製品のさまざまな組み合わせが存在する可能性があります。

次のセクションでは、料金の定義に密接に関連するさまざまな概念についてのアイデアを提供します。

事前および延滞料金

オペレーターが一部のサービスについては事前に顧客に請求し、その他のサービスについては月末に請求したい場合があります。

サービス提供前に事前にかかる料金を in-advance charging サービス提供後にかかる料金は in-arrear charges。

延滞請求の場合、製品料金は、少なくとも現在の名目請求日の前日（または非定期請求の場合は請求要求日）までの期間適用されます。

したがって、さまざまな料金を設定する際、課金システムは事前に料金を設定するためのプロビジョニングを提供する必要があり、特定の価格を前払いまたは後払いで設定する場合は、オペレーターにとって常にオプションです。

NOTE−顧客が来月にどれだけの使用量を生成するかわからないため、使用料は一括払いになるまで事前に請求することはできません。一括払いの場合は、事前にその金額を取り、お客様のご要望に応じて無制限のサービスをご利用いただくことができます。

按分可能および按分不可能な料金

顧客が月の半ばに電話に接続し、毎月1日に請求書を生成する必要がある状況を考えてみます。価格が按分できない場合、課金システムは顧客に1か月全体を請求しますが、これは顧客にとって公平ではありません。終了時にも同じことが当てはまります。顧客が月の半ばにサービスを終了した場合、オペレーターはその月の残りの時間について顧客に請求する意思がない場合があります。

比例配分された価格設定とは、顧客がサービスを使用する日数にのみ適用されることを意味します。たとえば、月額の製品レンタルが30ドルで、顧客がこの製品を10日間だけ使用した場合、課金システムはその10日間で顧客に10ドルだけを請求する必要があります。

したがって、課金システムは、特定の価格を比例配分可能および比例配分不可能に構成するオプションを提供し、オペレーターが最適なスイートを選択できるようにする必要があります。

返金可能および返金不可の料金

ここで、オペレーターが1か月間前払いで顧客に請求しているが、顧客が10日間サービスを使用した後、月の半ばに退去する状況を考えてみましょう。

価格が返金不可として構成されている場合、それらは顧客に返金されませんが、返金可能として構成されている場合、それらは顧客に返金されます。2番目のルールは、価格が比例配分可能として構成されている場合、比例配分に基づいて返金されます。それ以外の場合は、全体として返金されます。

チャージオーバーライドオプション

優れた課金システムは、顧客に提供された時点で基本価格を上書きするオプションを提供します。

たとえば、カタログ内の特定の製品の基本価格は月額30ドルと定義されていますが、顧客は支払う準備ができていません。 $30 per month, and based on some bargaining, he is ready to pay $月額25。このような状況では、顧客サービス担当者（CSR）が定義された基本価格を上書きできる必要があります$30 and add them as $システムでの顧客作成時に25。

課金システムは、特定の価格を上書きできるかどうかをオペレーターにオプションで提供し、販売時に一部の料金を上書きするか、すべての状況で固定するかをオペレーターに決定させる必要があります。

収益コードによる収益の分離

すべてのオペレーターは、特定の製品、そのレンタル、一時停止、または使用法などを使用して獲得した金額を知りたいと考えています。

カタログでさまざまな価格を定義する一方で、課金システムは、ある種の収益コードまたはキーワードをさまざまな種類の料金に関連付けるための規定を提供する必要があります。これは、収益に関連付けられたコードに基づいてさまざまなレポートを生成するのに役立ちます。

関税分類

オペレーターは、異なるクレジットクラスを持つ異なる人々に提供できる異なる料金を定義することができます。たとえば、5mbpsのデータラインのコストは$100 per month can be offered to a customer having monthly income more than $1000 /月と1mbpsのデータラインは、最低月収が$ 500 /月の顧客に提供できます。

すべての課金システムには、さまざまなクレジットクラスを定義するオプションがあります。これらのクラスは、顧客の信用履歴と収入に基づいて割り当てることができ、オペレーターが定義した他のパラメーターに基づく場合があります。

すべての製品とサービスは、一般クラスからVIPクラスまでのさまざまなクラスの人々に提供できるさまざまな料金プランを持つことができます。

使用料のパラメータ

使用料を定義する際に使用できるパラメータは多数あります。例-

• 通常はピーク時間と呼ばれる日中の通話は、より高い料金で課金され、夜間、つまり、オフピーク時間の料金は比較的低くなります。

• 通話が同じネットワーク内で終了する場合、通常はオンネット通話と呼ばれ、比較的低価格で課金されます。

• 週末、つまり土曜日と日曜日の通話は低料金で課金されます。

• 特定の宛先への通話は高額で請求されます。

• 一部のフェスティバル中の通話は特別価格で課金されます。

• 特定のサイトからのデータのダウンロードは無料です。

• 特定のコードにSMSを送信すると、高額の料金が発生します。

• 通常はクローズドユーザーグループ（CUG）と呼ばれる特定の番号グループ内の通話は、ゼロ価格で課金されます。

• 国際または国内のMMSの送信には、同じ価格が請求されます。

課金システムは、顧客が生成した音声、データ、SMS、またはMMSの使用量を請求するためのさまざまなルールを定義するための多くの柔軟性を提供します。

次は何ですか？

これで、すべての製品、サービス、および関連する料金が課金システムで利用できるようになりました。次の章では、これらの製品をエンドユーザーに販売し、システムでレコードを作成する方法を説明します。

顧客とは、サービスプロバイダーが提供する製品やサービスを受け取り、請求書の支払いを担当する「法人」（個人または企業のいずれか）です。住宅請求のシナリオでは、顧客は単一の世帯主である可能性があります。ビジネス請求のシナリオでは、顧客は企業である可能性があります。

• Individual customer−個々の顧客は、1つ以上の製品を購入し、請求書を支払う1人の個人（または世帯）です。顧客またはアカウントを維持するために必要な階層はありません。

• Company customers−会社の顧客は、単一の会社または会社の支店です。会社のさまざまな支店または部門を表す、典型的な親子タイプの顧客階層が存在する可能性があります。

顧客獲得プロセス

顧客獲得は、潜在的に収益性の高い顧客を特定し、引き付け、維持するプロセスです。これは、と呼ばれるシステムを使用して処理されますCustomer Relationship Management （CRM）、これは重要なビジネスサポートシステム（BSS）の1つです。

CRMシステムは、課金システムを含むさまざまなシステムと常に接続されており、顧客の個人データと製品およびサービスの情報を課金システムに提供します。

製品とサービスを購入している顧客は、システムでアクティブ化する必要があり、そのためには、顧客に関するさまざまな詳細が必要です-

• 顧客は、個人情報を提供する申請書に記入しなければならない場合があります。

• 詐欺を防ぐために、顧客の身元を確認します。

• サービスプロバイダーは、顧客の信用調査を実行し、信用履歴や月収などに基づいて適切な信用クラスを割り当てる必要があります。

• サービスを提供するためにネットワークでプロビジョニングされる適切な製品を提供します。

顧客を獲得したら、顧客を管理および維持する必要があります。

• 販売および収集活動のための顧客との対話およびコミュニケーション。

• これらのインタラクションは、メモ、音声録音などのさまざまな形式で記録できます。このデータは、顧客の行動を分析するために使用でき、サービスプロバイダーが顧客を維持するためにより良いサービスを提供するのに役立ちます。

• ネットワークや請求書などで直面する問題に対して顧客が提起したトラブルチケットを処理します。このデータは、顧客の行動を分析するためにも使用でき、顧客を維持するためにサービスプロバイダーがサービスを改善するのに役立ちます。 。

• 顧客とサービスプロバイダーの間で提起された請求書の紛争および調整の処理。

お客様のライフサイクル

以下の図に、一般的な顧客のライフサイクルを示します。

ここでは、顧客のライフサイクルを構成するすべてのフェーズについて簡単に説明します。

• Customer Engagement − 顧客はCSR（顧客サービス担当者）に連絡し、CSRは顧客に販売することで提供されるさまざまな製品やサービスを顧客に提供します。

• Order Creation and Fulfilment −顧客が製品とサービスを受け取り、CSRが注文を作成してシステムに入力します。注文は、必要な製品とサービスを顧客に提供することで実行されます。

• Service Provisioning −製品とサービスは、と呼ばれるシステムを使用してネットワークでプロビジョニングされます。 Provisioning System。プロビジョニングシステムは、顧客の情報と顧客が使用を許可されているサービスについてネットワークに通知します。実際、これによりネットワーク上の顧客がアクティブになります。

• Products Utilization −顧客がネットワーク上でアクティブ化されると、顧客は電話をかける、データのダウンロードなどを含む製品とサービスの使用を開始します。

• Products and services usage is Rated & Billed −顧客の使用状況はネットワークから収集され、定義された料金プランに基づいて評価され、製品のレンタルや必要な割引、調整などを適用するために請求されます。

• Bill Delivery −請求書が生成されると、提供されたサービスに対する収益を要求するエンドカスタマーに配信されます。

• Bill Payments −顧客は受け取った請求書に対して支払いを行います。

• Dunning & Collection−時間通りに請求書を支払わない顧客がたくさんいる可能性があります。このようなタイプの顧客の場合、支払いについて思い出させるためにさまざまな督促状が送信されます。顧客が時間通りに支払いをしない場合、顧客サービスを1つずつ停止することから始めてさまざまな収集が行われます。

• Customer Termination−システムで顧客を解約する必要がある場合、さまざまな理由が考えられます。たとえば、顧客が別の場所に移行している場合や、提供されているサービスに満足していない場合などです。

特定の日付で、システム内のアクティブな顧客の総数は、 customer base。システムに顧客を追加し、システムから顧客を終了することは、次のように知られています。customer churn。

顧客タイプ

通常、今日の通信市場には次のタイプの顧客がいます-

• Mobile Pre-Paid Customers−これらは、前払いでモバイルサービスを利用するお客様です。たとえば、GSM、GPRS電話ユーザー。これらの顧客は、要件に基づいて電話を再充電します。

• Mobile Post-Paid Customers−これらは、請求書を受け取るたびに料金を支払うことでモバイルサービスを利用する顧客です。たとえば、GSM、GPRS電話ユーザー。これらの顧客は、毎月または隔月ベースで請求書を支払います。

• Fixed Pre-Paid Customers−固定電話、すなわち固定電話サービスを前払いでご利用のお客様です。たとえば、PSTN、WiMax電話ユーザー。これらの顧客は、要件に基づいて電話を再充電します。

• Fixed Post-Paid Customers−これらは、固定電話、つまり固定電話サービスを使用して、請求書を受け取るたびに料金を支払う顧客です。たとえば、PSTN、WiMax電話ユーザー。これらの顧客は、毎月または隔月ベースで請求書を支払います。

次は何ですか？

現在、当社の課金システムには、製品やサービスとともに顧客がいます。顧客は購入したすべての製品とサービスの利用を開始し、国内および国際的なデータと音声通話の生成を開始します。これらは課金システムによって評価および請求されます。これらのプロセスについては、次の章で説明します。

顧客は、オペレーターが販売する製品やサービスを使い始めるとすぐに、ネットワークで使用量を生成し始めます。ネットワーク要素は、ソフトウェアとハ​​ードウェアの組み合わせであり、あらゆるタイプのサービスの全体的なサービス制御とメータリングイベントを担当します。

イベントとは何ですか？

イベントは、製品使用の単一の請求可能な発生であり、通常はネットワークによって電子的にキャプチャされます。たとえば、携帯電話のユーザーが電話をかけると、イベントが生成されます。このイベントには、通話時間、通話が行われた時刻、呼び出された番号など、その通話に関する情報が含まれます。

CDRとは何ですか？

イベントとそのすべての属性が呼び出されます Call Detail Record（CDR）。ネットワークスイッチのデータコレクターは、通話詳細レコード（CDR）/使用状況詳細レコード（UDR）の形式で使用状況をキャプチャします。これらの未加工のCDR / UDRは、メディエーションシステムによって、課金システムが理解できる形式に変換されます。

サービスを制御し、さまざまなタイプのCDRを生成するさまざまなネットワーク要素が存在する可能性があります。たとえば、GSMテレフォニーの場合-

• 音声通話はMSC（モバイルスイッチングセンター）によってキャプチャされます。
• SMSトラフィックはSMSCによってキャプチャされます。
• データトラフィックはGGSNによってキャプチャされます。
• MMSトラフィックはMMSCによってキャプチャされます。
• ローミングCDRは、ローミングパートナーのスイッチング要素によってキャプチャされます。

GSM、MSC、SMS、SMSC、GGSN、MMS、MMSCの詳細については、GSMチュートリアルを参照してください。

次の図は、使用状況データをキャプチャし、未加工のUDRをメディエーションシステムに送信し、最後に課金システムに送信して評価と請求を行うネットワーク要素を示しています。

CDR属性

上記のように、CDRは、他のさまざまな有用な情報とともに使用状況の詳細を保持します。以下はCDRの最も重要な属性です-

• 発呼者（番号）。

• 着信側（B番号）。

• 通話開始（日付と時刻）。

• 通話時間（期間）。

• 通話の種類（音声、SMS、データなど）。

• レコードを識別する一意のシーケンス番号。

さらに、CDRは、次のような他の情報も記録する場合があります。

• 電話交換の識別子。

• 通話の結果（応答されたか、ビジーかなど）。

• 通話の接続に使用されるトランクまたはルート。

• 障害状態が発生しました。

• 着信転送、三者通話などの機能の使用を示すインジケーター。

• キャッチホンや転送転送など、通話中に使用される機能。

• 要件に応じて他のさまざまな属性。

UDRに必要なすべての情報を正確に記録するには、スイッチベンダーのロジックとスイッチ固有のテーブルエントリが必要です。これらのいずれかがデータを正確に記録できない場合、仲介システムは完了した通話を認識して課金システムに渡すことができません。

CDR処理

メディエーションシステムは、さまざまなネットワーク要素からさまざまな形式でCDRを収集します。さまざまなネットワーク要素がASN.1形式でCDRを生成し、一部のネットワーク要素には独自の形式のCDRがあります。

仲介システムはすべてのCDRを処理し、それらをダウンストリームシステム（通常は課金システム）と互換性のある形式に変換します。調停システムは、CDRにさまざまなルールを適用してそれらを処理します。たとえば、調停システムは、ダイヤル番号（B番号）に基づいて国際電話にマークを付けます。同様に、調停システムは、A番号とB番号に基づいてオンネット通話にマークを付けます。

通話時間が5秒未満のすべての通話を除外する必要がある場合があります。このような種類の通話を除外するのに最適な場所は、メディエーションシステムレベルです。同様に、請求に重要な追加情報がCDRで必要な場合、メディエーションシステムは、CDR内で利用可能な他の属性に基づいてそのような情報を提供するのに役立ちます。

収集されたCDRが処理されると、通常、メディエーションシステムと課金システムは異なるマシンで実行されるため、メディエーションシステムはFTPを使用してすべてのCDRを課金システムにプッシュします。

次は何ですか？

これで、顧客が生成した使用状況をキャプチャできました。次の章では、このキャプチャされた使用量を評価して、エンドユーザーから適切な収益を収集する方法について説明します。

料金は、イベントの発生に対する料金/価格です。料金の例には、通話中の料金が含まれます。例：「1分あたり0.40インドルピー」または特定の金額。例：1MBのダウンロードで10.00 INR、またはサービス品質に対して課金される場合があります。

イベントは製品/サービスの使用の1回の発生であることはすでに説明しました。イベントは、CDRS / UDRの形式でネットワーク要素によってキャプチャされ、評価と請求のために請求システムに渡されます。

評価は、個々のイベントの料金/価格を決定するプロセスです。たとえば、2分間の通話料金は0.80インドルピーで、料金は1分あたり0.40インドルピーです。

請求システムの一部である評価エンジンは、この評価機能を実行します。

評価プロセス

Rating Engineは、製品/サービスの使用を説明するCall Detail Records（CDR）またはUsage Detail Records（UDR）と呼ばれるデータレコードの形式でイベントを受信します。CDRは、イベントの評価に使用される、コールの日時、コールの長さ、発呼側、着呼側などのコール情報を含むデータの文字列です。

評価/評価エンジンの基本機能のリストがあります-

• ローミングを使用する場合は、メディエーションシステムまたは他のサービスプロバイダーまたはローミングパートナーからのCDRを受け入れます。

• CDRを検証し、重複するレコードを削除します。これらの重複イベントは、後で検証するためにデータベーステーブルに保存されます。

• イベントに対して請求する必要のある顧客アカウントを決定するため。ここで、レートプロセスは、イベントソース（携帯電話番号やIPアドレスなど）を取得し、データベースをチェックして、このイベントソースがアカウントに関連付けられているかどうかを確認します。このステップはイベントガイドと呼ばれます。

• イベントをガイドできない場合、このイベントは拒否され、サスペンスカテゴリに分類できます。これらの拒否されたイベントは、後で検証するためにデータベーステーブルに保存されます。

• レーティング料金（レートプランとも呼ばれます）に従ってイベントのコスト/価格を計算します。

• 該当する評価時間割引を適用します。これは最初の5分間は無料で、その後は通常の料金で通話料金が請求されます。このようなタイプの割引は、評価時間割引と呼ばれます。

• 課金目的で評価されたイベントをデータベースに保存するか、課金のために外部システムに送信します。

次の画像は、評価エンジンとそれに関連する機能の概要を示しています-

顧客の情報により、料金/価格の計算に使用する料金プラン（料金表）が決まります。評価エンジンは、評価テーブルとCDRからのイベント情報（距離、時刻、通話の場所、イベントの期間または量など）を使用して、各通話の実際の料金を計算します。

重複するイベント

重複イベントは、次のすべての方法で別の未請求イベントに関連する未請求イベントとして定義されます。

• 口座番号は同じです。
• イベントソースは同じです。
• イベントタイプIDは同じです。
• イベントの日時は同じです。

重複するイベントを識別するために、課金システムで他の基準を定義できます。重複するイベントが課金システムに送信される原因となる可能性のある状況がいくつかあります-

• メディエーションシステムのフィルタリングメカニズムの障害。
• メディエーションシステムソフトウェアのコーディングエラー。
• 評価エンジンに渡されるイベントファイルの全部または一部の繰り返し。

拒否されたイベント

請求システムが特定のイベントで問題を検出すると、問題のあるイベントは拒否されます。拒否は、次のいずれかの問題が原因である可能性があります-

• イベント自体。
• 料金プラン。
• 顧客とアカウントのデータ。
• 設定データ。

イベントを拒否する主な理由は3つあります-

• 解析エラーにより、課金システムはイベント詳細レコードの情報を読み取ることができません。イベントレコードのデータが破損しているか、形式が間違っているため、解析エラーが発生する可能性があります。

• ガイドできないエラーにより、ジュネーブはイベントに関連付けられたイベントソースまたはアカウントを識別できません。イベントソースが請求システムデータベースにまだ存在しないため、ガイドできないエラーが発生する可能性があります。

• 評価できないエラーにより、請求システムはイベントのコストを計算できません。料金プランに問題があるため、評価できないエラーが発生する場合があります。

拒否されたすべてのイベントは、と呼ばれる特別なアカウントに投稿されます internal account または suspense account これらの拒否されたイベントは suspense events。財務部門は、拒否されたすべてのイベントを追跡し、収益損失の一部としてカウントします。IT部門は、拒否されたイベントを解決し、収益を節約するために適切に評価するために、常に多くの注意を払っています。

拒否されたイベントを修正できず、オペレーターがそれを内部アカウントに投稿したくない場合は、イベントを破棄できます。イベントが破棄されると、そのイベントは評価エンジンに送信されず、それ以上評価を試みることはありません。

リアルタイム評価

リアルタイム評価は、イベントが発生したときにそれを取得し、イベントの生成とコスト計算の間の遅延をできるだけ少なくして、すぐに評価するプロセスです。リアルタイムの評価は、ファイル全体が最終的に評価される前に、イベントの詳細がファイルバッファーに数時間、数日、または数週間保存されるファイルベースの評価とは対照的です。

リアルタイムシステムプロセスには、eコマーストランザクションとデータのダウンロードが含まれます。イベントを評価して顧客のアカウントにすばやく適用する必要があるアプリケーションは、リアルタイム評価の適切な候補です。

イベントの再評価

イベントを再評価する必要がある状況がいくつかあります。たとえば、-

• 使用した料金プランに誤りがあると、イベントの価格が正しくなくなりました。

• イベントが間違ったアカウントに対してロードされました（イベントソースの登録が正しくないため）。

• 既存の料金プランは、最終請求日と次の請求日の間のある時点で置き換えられました。

• 製品の料金プラン、価格プラン、またはイベントソースが遡及的に変更されました。

イベントを再評価するプロセスは非常に単純で、次のとおりです。

• 提供されているユーティリティを使用して、データベースからすべてのイベントをアンロード/アンレートします。ほとんどの課金システムには、評価されたすべてのイベントをアンロードまたは評価解除するユーティリティが用意されています。

• 問題がどこにあっても修正します。

• 評価エンジンによる評価のためにイベントを再送信します。

部分的なイベント

部分的なイベントにより、イベントの進行中に顧客のバランスを維持できます。

たとえば、データのダウンロードが長い場合、メディエーションシステムは部分的なイベントを課金システムに送信し続けるため、課金システムはイベントの完了を待たずにそれらを評価し続け、顧客の与信限度額に違反するとすぐにアカウントが禁止され、ネットワーク要素は、通話を終了するように通知されます。

しきい値とアクション

評価エンジンは、評価時間割引のしきい値を含む、評価時間のしきい値に達しているかどうかを自動的に確認できます。

評価時間のしきい値は、多くの収益損失からオペレーターを保護するのに役立ちます。たとえば、顧客が自分の与信限度額を超えて支払うことをいとわない場合、そのような場合、与信限度額のしきい値に達したらすぐに顧客の通話を終了する必要があります。

評価時間アクションを実行する必要がある場合は、できるだけリアルタイムの評価を行うことが重要です。

次は何ですか？

これまで、顧客が使用量を生成する方法、仲介システムがその使用量（CDR）を請求システムにプッシュする方法、および請求システムがそれらのCDRを評価する方法を見てきました。

次の章では、月全体のすべての評価済みCDRを収集し、最終的な請求書/請求書を生成する方法について説明します。これは、提供されたサービスの収益を収集するためにエンドカスタマーに送信されます。

請求は、アカウントごとに、すべての非定期的、定期的、および課金対象のイベントの集計です。また、すべての未払い料金と利用可能な割引およびボーナスの計算でもあります。

請求プロセスからの出力は、紙、ディスク、またはその他のメディアに請求書を作成するために使用できるタグ付き請求書データのストリームです。請求システムの一部である請求エンジンは、請求書を作成します。

請求プロセス

次の図は、課金エンジンと関連機能の基本図を示しています。

請求エンジンは、請求書を生成するためのアカウントと、請求書データを生成するための次の関連情報を取得します-

• 請求書の月内の顧客のすべての評価済みCDR。

• お客様の製品およびサービスに適用されるすべての種類の料金（開始、インストール、定期的、一時停止、終了など）。

• 返金またはその他の料金が適用される場合。

• 以前の請求書からの未払いの合計。

• 特定の月に顧客が行った支払いの合計。

• 顧客に有利に、または顧客に反対して、合計調整が渡されました。

• 顧客に与えられる合計割引。

• お客様の使用料およびレンタル料に適用される税金の合計。

• 請求エンジンの実行に必要な請求構成パラメーター。たとえば、支払い期日など。

上記の情報は単なる目安であり、課金システムごと、およびオペレーターごとに異なる場合があります。

Billing Engineは、最終的な請求書を生成するために必要なすべての情報を含む生データを生成します。この生データを使用して、最終顧客に送信される最終的な請求書を生成できます。

ビルサイクル

顧客が請求システムに追加されると、システムは顧客に事前定義された請求サイクルを割り当てます。請求サイクルは、Billing Engineが実行され、一連の顧客の請求書を作成する日付です。

多くの顧客がいる場合、それらは異なる請求サイクルに分割されます。たとえば、顧客のグループは、毎月1日として請求データを持つことができます。別の人は毎月15日に請求日を持つことができます。

顧客がその月の1日に請求を実行するように割り当てられている場合、これは顧客の nominal bill date。しかし、さまざまな理由により、請求書の実行が遅れ、実際の請求書が後日生成されることがよくあります。これは、actual bill date。

請求書の種類

ユーザーが利用できる請求書にはさまざまな種類があります。一部の課金システムでサポートされていないものはほとんどありません。

シニア番号	請求書の種類と説明
1	Initiation bill 通常、アカウントの最初の請求としてのみ要求されます。製品の料金と調整が含まれますが、イベントは含まれません。
2	Periodic bill 定期的に生産されます。すべての定期的な料金、イベント、および調整が含まれます。
3	Interim bill 前回の請求以降にアカウントに対して処理されたイベントによる料金を含む追加の請求。すべてのイベントと調整が含まれますが、定期的な料金は含まれません。
4	Suspension bill アカウントが停止されたときに送信されます。すべての定期的な料金、イベント、および調整が含まれます。
5	Final bill アカウントが終了したときに送信され、未払いの料金をすべて請求します。すべての定期的な料金、イベント、調整、および払い戻しが含まれます。たとえば、預金の返還。
6	Post-final bill 最終請求書の作成後に、終了したアカウントに未払いの売掛金がある場合に送信されます。終了後のイベントと調整が含まれますが、定期的な料金は含まれません。
7	Credit note 前回の請求以降に生成された、顧客に有利なすべての調整を含む追加の請求。
8	Summary Statements 要約ステートメントは、顧客主導の請求階層に対して作成できます。それぞれの顧客に関連付けられたすべてのアカウントによって生成されたすべての請求書を要約できます。オプションで、すべての請求書を1つのステートメントに連結することもできます。

請求書は、自動的に、または顧客からの要求に応じて作成されます。

請求モード

請求システムは、次の2つのモードで請求書を生成できます。

• Test (what if?) billing mode−このモードは、データベースを変更せずにフォーマットされたテスト請求書を作成するために使用される場合。これらの請求書は、システムが正常に機能していることを確認し、請求書のテンプレートまたは料金を変更した後にテストするのに役立ちます。

• Billing Engineをテストモードで実行すると、データベースへのコミットは行われません。そのため、テスト課金を何度も実行した後でも、顧客のプロファイルに影響はありません。

• テスト請求書は通常、顧客のサンプルセットに対して実行されます。テスト請求書に満足している場合は、製造請求書に進むことができます。

• Production (live) billing mode−このモードは、通常の製造請求書を作成するために使用されます。ほとんどの場合、これは課金エンジンのデフォルトモードです。

• 生産請求書が生成されると、Billing Engineはデータベース内の顧客のプロファイルを更新して、顧客が支払う未払いの合計残高や次の請求日などを表示します。

Billing Engineは、すべての製造請求書に異なる請求書番号を割り当てます。これは、請求書に対して行われたさまざまな支払いを追跡するのに役立ちます。

ビル抑制

請求書を作成する価値がなく、請求書を抑制する方がよい場合があります。以下はそのようなタイプの状況です-

• ゼロ（ゼロアクティビティ請求書）または非常に少ない値（小さな請求書）のアカウントの請求書を抑制します。

• 複数の請求タイプが同時に要求/スケジュールされている場合、特定のタイプの請求を抑制して、不要な請求が顧客に送信されるのを防ぐこともできます。

小額請求書は、最小の正の請求額と最大の負の請求額によって定義される範囲内にある請求書であり、例外的な請求条件です。少額の請求書が作成され、請求プロセスから削除されるため、顧客に送信されません。

例外的な請求書

考えられる例外的な請求書の例は、異常に高い請求書または請求書であり、設定された乗数によってアカウントの与信限度額を超えます。請求エンジンは、生成する請求データに対していくつかの基本的なチェックを実行します。これらには、請求される合計をテストして、次の条件が満たされていることを確認することが含まれます。

• 請求額の合計が、マイナスの請求額の最小額を上回っています。

• 請求額の合計が正の請求額の最大額を下回っています。

• 請求額の合計は、アカウントの与信限度額に与信限度額の乗数を掛けたものよりも少なくなっています。

上記の条件はすべて、課金システムごと、およびオペレーターごとに異なり、例外的な請求条件と呼ばれます。

請求書の明細化

デフォルトでは、すべての請求書には、使用料とともに製品およびサービスの料金の詳細な要約が記載されています。ただし、お客様が行ったすべての通話の詳細は提供されていません。

明細請求書とは、顧客が行ったすべての通話の完全な詳細を提供することを意味します。これには、より多くの用紙を印刷する必要があります。最近の傾向は、電子メールで明細請求書を送信することであり、要約ステートメントは請求書の物理的なコピーを使用して送信されます。

請求書のフォーマット

最終的にフォーマットされた請求書を生成するために使用できる請求フォーマットユーティリティを提供する請求システムがあります。

請求書フォーマッターは、請求エンジンによって生成された出力データを取得し、通常、請求書印刷会社が使用できるPostScriptファイルまたはPDFファイルのいずれかを生成します。

請求システムがフォーマットされた請求書を生成するのに十分な能力がない場合、システムは請求情報とともにタグ付きファイルのセットを生成し、外部の請求書フォーマッターはそのタグ付き情報を使用して適切にフォーマットされた請求書を生成できます。

請求システムがフォーマットされた請求書を生成する場合、または外部ツールを使用して請求エンジンによって生成された生データを使用してこれらのフォーマットされた請求書を生成する場合、最終的にこれらの請求書は請求書印刷会社に送信され、請求書の生成の最終コピーの生成を担当します。これについては、次の章「請求書の生成」で詳しく説明します。

次は何ですか？

次の章では、実際には評価と請求のプロセスの一部である割引プロセスについて説明しますが、さまざまな項目についてさらに説明が必要なため、別のセクションとして保持しました。

さまざまなタイプの割引階層について説明します。これらは、評価および請求時に指定できます。

すべての割引は、一連のイベントおよび/または製品に支払われる価格を変更します（最も一般的には削減します）。割引は、顧客にお金を渡す方法です。割引は、特定の基準を満たす製品または使用法に適用される一定の金額（パーセンテージまたは金額）を定義します。たとえば、特定の日に行われたすべての市内通話は、2010年1月1日が0.20ドルで請求されます。

割引は、評価プロセス中または請求プロセス中に計算できます-

• Rating Time Discount−評価プロセス時に与えられたすべての割引。これらの割引は、使用時にのみ提供できます。評価時間割引の例は、「すべての国際電話の最初の1時間から5％オフ」です。

• Billing Time Discount−請求プロセス時に提供されるすべての割引。これらの割引は、定格使用量および製品とサービスの料金に適用できます。請求時間割引の例としては、「1か月以内に15ドル以上使うと5％オフ」があります。

事前明細化割引は、再評価された価格を決定するために適用される各イベントの価格を変更する割引です。この割引は請求時間割引のカテゴリにも含まれますが、これは通話の評価に関連しています。その他の請求時間割引では、イベントの価格は変更されません。アイテム化前の割引には、製品料金を組み込むことはできず、イベント料金のみを組み込むことができます。

割引の手順としきい値

割引のサイズは、一連の割引手順としきい値を使用して決定されます。割引ステップでは、特定のしきい値に達したときに割引のサイズを変更できます。

たとえば、テレフォニーイベントの割引は、通話に費やした分数に依存し、100分後に10％オフ、200分後に20％オフになります。

各割引には、少なくとも1つのステップが必要です。割引が多かれ少なかれ有利になり、ボリュームが増える必要がある場合は、さらに手順を追加できます。各割引ステップでは、割引を金額またはパーセンテージのいずれかで表すことができます（両方ではありません）。

シンプルな割引タイプ

エンドカスタマーに提供される割引には無限の種類がありますが、それは請求が何をサポートしているかによって異なります。以下は、提供できるシンプルですが非常に優れたタイプの割引です-

クロス積割引

これらは、一連の製品とイベントが別の一連の製品とイベントの割引を決定する割引です。

たとえば、「モバイル通話に30ドル以上が費やされた場合、10SMSは無料です」。ここでは、携帯電話が割引を決定し、SMS製品が割引を取得します。このようなタイプの割引は、cross product discounts。

段階的割引

これらは、割り当てられた割引しきい値の間にある一連のイベントまたは費やされたお金の部分にのみ適用されます。たとえば、次の図では、$0-$100のしきい値または0〜100のイベントのしきい値、5％オフ $100-$200しきい値または100〜200イベントしきい値など。

ボリュームディスカウント

これらは、特定の製品が生成するイベントまたは製品料金の数に基づく割引です。たとえば、次の図では、100ドルまたは100イベントなどの費用で5％オフです。ご覧のとおり、費用が大きいほど割引が大きくなります。

税の割引

税の割引は、いくつかの免税に対処するための代替方法を提供します。これらは、アカウントへの請求時に計算および適用されます。

割引期間と按分

ほとんどの割引には割引期間が関連付けられており、日数、週数、または月数を指定できます。この期間は3つの方法で使用できます-

• しきい値に到達するまでの時間を指定します。

• 絶対割引が適用される頻度を指定します。

• 使用率が最も高いフィルターが添付された割引について、使用量が最も多いと判断される頻度を指定します。

割引は、要件に基づいて比例配分される場合と比例配分されない場合があります。割引が按分される場合、割引はサービスが使用されている日数に基づいて計算され、非按分割引の場合、割引が構成されている期間全体に対して計算されます。

ボーナススキーム

ボーナススキームは、顧客に無料イベントを提供する方法であり、無料イベントの数は、一定期間（たとえば、前年）における1つ以上の製品の以前の使用または料金によって決定されます。

たとえば、「スーパーディールテレフォニーパッケージを利用すると、前四半期に行われた国際電話の3時間ごとに10ドルの無料通話が受けられます。」

顧客にお金を渡す方法は他にもあります。たとえば、パッケージを介してより有利な価格プランを提供し、数量が増えるにつれて製品の単価を下げるなどです。

コーリングサークルグループ（CUG）

呼び出しサークルグループは、メンバーとしてモデル化されたユーザーと（デフォルトでは）非メンバー間の関係を定義します。

このモデル内では、サークルのメンバーからサークルの別のメンバーへの通話の料金は、同じ通話を行う非メンバー（またはアソシエート）に適用される料金とは異なります。

発呼者間の関係は、発呼者IDの組み合わせによって決定されます。ネットワークが同じオペレーターに属している場合、コーリングサークルはネットワークにまたがることができ、単一のコーリングサークルにはモバイルユーザーと固定回線ユーザーの両方を含めることができます。

次は何ですか？

前の章で請求プロセスについてはすでに説明しました。次の章では、生の請求書データから構造化された請求書の作成まで、請求書生成の最後の部分について説明します。

ほとんどの課金システムは、請求書の情報コンテンツを含む構造化されたASCIIテキストを生成します。各請求書の請求書データは、最初にデータベースまたはフラットテキストファイルのいずれかに書き込まれます。この段階でのデータの形式は、データの処理方法に関係なく同じです。

次に、この請求書データを多数のフォーマットエンジンのいずれかで処理して、目的の形式で出力を生成できます。たとえば、紙、CD-ROMなど。

内部の請求書フォーマットツールを提供する請求システムが利用可能です。請求システムがフォーマットされた請求書を生成するための有能なツールを提供しない場合、最も一般的に使用されるツールの1つであるDOC1のようなサードパーティのツールが利用可能です。

これは、請求書のフォーマットの流れを示す典型的な図です-

以下は、ConvergyのInfinys請求システムから取得した請求データのスナップショットです-

DOCSTART_85
DOCTYPE BILL
GENEVAVERSION 5.0
BILLSTYLE 1
BILLTYPE 1
BILLTEMPLATE 85
BILLSEQ 1
BILLVERSION 1
ACCCURRENCYCODE BEF
BILLLANGID 2
BILLLANGNAME English (US)
BILLLANGLOCALE us
PAYMETHODID 1
FORMATREQ A30001001/0001
COPYBILLNUM 0
BILLPURPOSE 1
ADDRESSNAME Dr D Jackson
POSITION Project Manager
DEPARTMENT Recruitment
ADDRESS1 12 South Street
ADDRESS2 Detroit
ADDRESS3 Michigan
ZIPCODE 12345
COUNTRY United States
BSTARTACCFADDR
ACCFADDR_1 United States
ACCFADDR_2 Michigan
ACCFADDR_3 12345
ACCFADDR_4 12 South Street
ACCFADDR_5 Detroit
ACCFADDR_6 Dr D Jackson
BENDACCFADDR
CUSTOMERREF C30001
CUSTOMERTYPE Standard
ACCTAXSTATUS Exclusive
INVOICINGCONAME Invoicing company for English (US)
INVOICINGCOADDRESS1 Company House
INVOICINGCOADDRESS2 Atlanta
INVOICINGCOVATREG taxref000576
ACCOUNTNO A30001001
BENDBFPAYSUMMARY
BALOUT 0.00
CHARGES 142.00
NEWBAL 142.00
BSTARTBFPAYDETAILS
ACCDEPPREVTOT 0.00
ACCDEPCHANGE 0.00
ACCDEPCURRTOT 0.00
BENDBFPAYDETAILS
BENDBFSTATEMENT
BILLREF A30001001@0001
BILLDATE 02/20/99
NEXTBILLDATE 03/20/99
BSTARTPAYMENTDUEINFO
PAYMENTDUEDATE 03/04/99
DEBTSTARTDATE 02/25/99
PAYMENTTERMDESC Payment due 7 days after the bill date
PAYMENTDUEDAYS 7
BENDPAYMENTDUEINFO
GIROREF 34
GIROACCOUNT 404 7800
OCRREF 1300010019
OCRSORTCODE V6344047800
GIROAMOUNT 142.00
OCRAMOUNT 000142000
INVOICEACTUALDATE 02/25/99
INVOICETAXDATE 02/25/99
INVOICESTART 01/03/99
INVOICEEND 02/19/99
TAXTYPE 1,2.00,
TENDTAXTYPE
INVTOTALTAX 2.00
BENDTAXDETAILS
INVTOTAL 142.00
INVTOTALROUNDED 142.00
TOTALSAVE -11.00
PERIODEND 02/25/99
POINTSBALANCE 0
POINTSEARNED 0
POINTSREDEEMED 0
POINTSADJUST 0
NEWPOINTSBALANCE 0
DOCEND

請求書データは、一連のASCIIテキスト行で構成されます。各行は次の形式を取ります-

TAGNAME tagvalue

TAGNAMEとタグ値は、スペースのタグ区切り文字（tagsep）で区切られます。tagvalueは、単一の値または区切り文字（sep）で区切られた値のリストのいずれかです。使用される区切り文字は、指定されていない限りコンマです。

ビルポストプロセッサー

請求エンジンは、請求書に必要なすべての情報を生成できない場合や、請求書に記載されているデータに対して特別な計算を実行する必要がある場合があります。これはBillPost Processingと呼ばれ、通常はBill Post Processor（BPP）。

BPPは、希望するプログラミング言語で記述できます。この言語は、生の請求書ファイルを読み取り、最終的なフォーマットに渡す前に、このファイルに必要な変更を加えます。

要件はオペレーターごとに異なり、このプロセスを標準化できないため、すぐに使用できるBPP機能を提供する利用可能な課金システムはありません。せいぜい、課金システムは、課金エンジンと一緒にカスタムBPPをプラグインするためのプラグインポイントを提供できます。

DOC1ビルフォーマッター

DOC1は、PitneyBowesCompanyから入手できる非常に有名なBillFormatterツールであり、PDFまたはPostScriptファイルへの請求書のフォーマットに役立ちます。

上記のように、請求エンジンの出力は、請求書の情報コンテンツを含む構造化されたASCIIテキストです。課金システムによって生成されたソース請求書ファイルタグとDOC1に必要なタグの間でマッピングが確立されます。DOC1には、以下に示すように固定長のタグが必要です。

以下は、提供された請求書ファイルからの架空のサンプルです-

ACCOUNTNO ACC0010000
ACCUMBONUSPOINTS_1 BON0050100
ACCUMBONUSPOINTS_2 BON0050100
ACCUMBONUSPOINTS_3 BON0050100
ACCUMBONUSPOINTS_4 BON0050100
ACCUMBONUSPOINTS_5 BON0050100
ADDRESS1 ACC0030000
ADDRESS2 ACC0040000
ADDRESS3 ACC0050000
ADDRESS4 ACC0060000
ADDRESS5 ACC0070000
ADDRESSNAME ACC0020000
BUSINESSNAME ACC0120000
TSTARTADJ ADJ0000000
..........

上記の翻訳を使用すると、DOC1の最終ファイルが生成され、DOC1が提供された情報を使用して最終請求書の生成を処理します。

一部の変更はDOC1レベルでも実行できますが、請求書を変更するための柔軟性はあまりありません。最新バージョンを試すことができます。これは、より多くの期待に役立ちます。

最終的な請求書の生成

すべてのアカウントに請求が行われ、内部または外部の請求書フォーマッターを使用して請求書がフォーマットされると、これらの請求書は最終的な印刷のためにBill PrintCompanyに送信されます。

オペレーターが電子電子メール機能を使用して顧客に請求書を送信している場合は、同じ請求書のコピーを電子メールシステムに送信して、エンドカスタマーに送信できます。

Tier 1オペレーター（2,000万から3,000万以上の顧客ベースを持つ）は通常、請求書の配布を含むこのタスクを外部委託します。

次は何ですか？

請求書を生成した後、それらは最終顧客に送信されます。さて、顧客から収益を集める時が来ました。1つの章の後で、収益の回収プロセスについて説明します。

先に進む前に、クレジット管理の部分について説明します。これは非常に重要であり、収益を集める前に説明する必要があります。

すべての事業者はサービスを提供し、ビジネスで生き残るためにエンドカスタマーから収益を集めます。エンドカスタマーに請求する方法は2つあります-

• In-Advance−オペレーターは、サービスを提供する前に事前に顧客に請求します。これは顧客満足度の低下につながりますが、オペレーターは収益の観点からより安全です。

• In-Arrears−オペレーターは、必要なサービスを提供した後、リスクを冒し、月末に顧客に請求します。これはより多くの顧客満足につながりますが、オペレーターはより少ない収入を集めるリスクがあります。

オペレーターが特定の顧客に関連する収益の損失を許容できる範囲まで、常にしきい値があります。同時に、オペレーターが特定の顧客に対して取ることができるリスクのしきい値があります。

たとえば、顧客の収入が $10,000/month, then operator can provide him their services very easily up to $1000- $2000 but for the same operator it would be difficult to provide him a service, which would cost almost $このような状況では、顧客が毎月の支払いを行うのが難しいため、10,000 /月。

同じ概念を維持しながら、オペレーターはさまざまなクレジットクラスを定義します。これを使用して、顧客を分類し、さまざまなクレジットおよび回収アクションを関連付けます。

クレジットクラス

クレジットクラスは顧客のカテゴリを定義し、関連する収益のリスクはその顧客にかかる可能性があります。クレジットクラスは、所有者が支払期日（誰もが認める）支払いを怠った場合に、どの収集スケジュールを顧客に適用するかを定義します。

すべての請求システムには、さまざまなクレジットクラスを定義する機能があり、システムに追加するときにさまざまな顧客に割り当てることができます。クレジットクラスのいくつかの例は次のとおりです-

• VIP Credit Class −これはVIP顧客に割り当てることができ、非常に高い与信限度額があります。

• General Public Class −これは最も一般的なクレジットクラスであり、 $100 or $200クレジット制限。

• Segment Specific Class −これらのクラスは、警察、軍隊、銀行の役員などのさまざまなセグメントに基づいて定義できます。オペレーターは、快適さに基づいて与信限度額を定義できます。

顧客の要件とカテゴリに基づいて定義されたクレジットクラスは無数に存在する可能性があります。

信用管理

特定のタイプの顧客カテゴリに対してクレジットを制御できる主に2つの段階があります-

未請求の使用量ベース

これは、評価プロセスによって実行される評価時間制御です。ここでは、お客様の使用量と合計料金が割り当てられた与信限度額と照合され、お客様が割り当てられた与信限度額に近づき始めた場合、お客様にその旨が通知され、与信限度額に違反した後、適切な措置を講じることができます。

顧客が与信限度額に違反している場合にサービスを禁止（つまり一時的に停止）したいオペレーターがいて、支払いが完了すると禁止が解除されます。たとえば、与信限度額が200ドルの顧客には、SMSを使用して使用量の80％が通知され、90％のしきい値に達すると、リマインダーコールなどを使用して通知され、100％のクレジットが通知されます。制限に達した場合、発信が禁止される可能性があります。

クレジットを管理するために、オペレーターは音声とSMSを使用する場合は発信通話のみを禁止することを好みますが、データのダウンロードの場合、顧客はデータのダウンロードを実行できません。

請求された使用量ベース

これは通常、請求書を送信した後に行われ、次の章で説明する収益回収プロセスに関連しています。

格付け時にクレジットを管理するには、可能な限りリアルタイムで格付けを維持することが重要です。使用量がリアルタイムで取得されておらず、長いギャップの後に評価されている場合、顧客がクレジット制限を超えた可能性があり、法的に顧客は割り当てられたクレジット制限を超えた金額を支払うことができない可能性がありますが、これは国やオペレーターによって異なります。

預金

アカウントに対して保持される預金をサポートする課金システムがあります。預金は口座残高と一緒に保持され、現金は2つの間で転送できます。

アカウントに対して維持できるさまざまな種類のサービスを提供するために、さまざまなレベルの預金が存在する可能性があります。

預金は、顧客が支払いを行うことができない場合に、オペレーターが収益を賄うのに役立ちます。

次は何ですか？

さまざまなクラスの顧客に与えられるクレジットを制御する方法について、いくつかのアイデアがあることを願っています。それでも、彼らの能力の範囲内で彼らにクレジットを与えた後でも時間通りに支払わないであろう様々な顧客がいるでしょう。利用後は全くお金を払わないお客様もいらっしゃいます。

次の章では、提供されるサービスの収益を収集するために、さまざまな収益収集プロセスとスケジュールを定義する方法について説明します。

請求書が生成されて顧客に発送された後、理想的には、すべての顧客が請求書を受け取り、迅速に支払います。ただし、一部の顧客が請求書を支払わず、請求書の支払いが許容できないほど遅れる可能性があるため、サービスプロバイダーは状況を改善し、未払いの残高を回収するために必要な措置を講じる必要があります（売掛金と呼ばれます。 A / Rと略されます）。

回収は、顧客アカウントで延滞債権を追跡するプロセスです。これには通常、顧客に通知を送信し、期日後に支払期日がない場合に適切な措置を講じることが含まれます。

請求システムは、請求書ごとに売掛金が追跡される請求書レベルと、複数の請求書にわたる勘定のすべての延滞額を単一の督促処理で処理できる勘定レベルの両方で、督促（売掛金追跡）をサポートします。

勘定に使用される督促モデルは、その与信クラスに基づいて割り当てられます。コア収集プロセスには、次の2つの項目が含まれます-

• Collections Aging Tracking−これは、指定された支払い期間の期日内に支払われなかった顧客の請求書を追跡するプロセスです。「売掛金の年齢」を扱っています。たとえば、0〜30日遅れ、30〜60日遅れの請求書などです。

• Collections Actions−回収アクションは、売掛金が特定の年齢に達したときに実行されるアクションです。たとえば、郵送または録音する音声メッセージを顧客に送信するリマインダーメッセージを再生する必要があります。

収集アクションスケジュール

通常、コレクションアクションは次の手順で実行されます-

• リマインダーメールの送信および/または電話：カスタマーサービス部門は、支払いをリマインダーする顧客に連絡します。それでも支払いがない場合は、次のアクションに進みます。

• 赤い手紙を送る-たとえば、「7日で支払う」という手紙が発行されます。それでも支払いが受け取られない場合は、次のアクションに進みます。

• サービスを切断する-ネットワーク管理部門はサービスを一時停止します。

回収スケジュールは、回収アクションを定義します。これは、実行する必要があり、顧客が支払わないときに実行する必要がある時間です。

収集スケジュールは、収集プロセスを構成する一連の段階を指定します。各段階について、それはカバーします-

• アクションが発生するために売掛金が必要な有効年齢。実効債権年齢は、実際の債権年齢をとって算出しています。

• 取るべき行動。これは、請求システムが実行するアクションである可能性があります。たとえば、特定の日付に督促通知を送信します。

• アクションが必須かどうか。アクションが必須の場合、これが実行されるまで、後続のアクションは実行できません。

• それを下回るとアクションが実行されない最小売掛金額。

ソフトコレクションアクション-督促状

回収プロセスの初期段階では、ソフト回収アクションは通常、単純なリマインダーレターと支払いの要求である多数の督促状を送信することです。

さまざまな段階で多数の督促通知が送信された後、通常、他のアクションがスケジュールされます。たとえば、顧客サービス担当者（CSR）が顧客に電話して、支払いをしていない理由を尋ねる必要があることを指定できます。

ハードコレクションアクション-ブラックリスト

最初の試行が失敗した場合は、サービスを禁止したり、サービスを切断したりするなど、より積極的なアクションを実行できます。 hot-lining （ホットライニングは、滞納した顧客のすべての呼び出しを回収オペレーターにリダイレクトするプロセスです）。

会費を徴収するすべての試みが失敗した場合、サービスプロバイダーはアカウントを償却し、その金額を貸倒れとしてマークするか、アカウントを徴収機関に引き渡す（売却する）ことができます。回収業者は、回収された収入の一定の割合に取り組んでいます。ただし、未回収のアカウントの請求書が回収代理店に売却されると、サービスプロバイダーは支払いに関して顧客と協力することはできなくなります。

ここで、償却とは、サービスプロバイダー（オペレーター）が顧客に代わって会費を清算し、アカウントを永久に閉鎖することを意味します。これは会計目的で行われます。そうでない場合、オペレーターにとっては損失になります。

サービスプロバイダーは、ブラックリスト顧客とも呼ばれる償却アカウントの履歴を維持して、再度アクティブ化されないようにし、そのようなアカウントについて信用調査/報告機関に通知します。

次は何ですか？

ほとんどのお客様は、期日までにお支払いいただきます。支払いを行うために使用されるさまざまなチャネルが存在する可能性があります。

次の章では、さまざまな種類の支払いと、請求書を決済するためのエンドツーエンドの処理について説明します。

請求書が顧客に送信されると、顧客は請求書の支払いを開始します。請求システムへの請求書支払いの処理は、支払い処理と呼ばれます。

顧客による支払いは、顧客のアカウントに転記されます。未払いの請求書がある場合、どの請求書が支払われるかは、アカウントの会計方法によって異なります。会計方法には2つのタイプがあります-

• Balance forward accounting −この方法を使用すると、未払いの請求書が多数ある場合、受け取った支払いは売掛金の年齢に応じて請求書に割り当てられ、最も古い請求書が最初に作成されます。

• Open item accounting−この方法では、支払いを特定の請求書に割り当てることができます。オープンアイテムアカウンティングは、ビジネス顧客からの支払いを処理するときに特に役立ちます。

お支払い方法

顧客は、サービスプロバイダーがサポートするさまざまな支払い方法を使用して支払いを行うことができます。たとえば、顧客は、小切手、クレジットカード、デビットカード、電信送金、または直接現金預金などの支払い方法を使用して支払いを行うことができます。

オペレーターは、銀行口座を通じて直接支払いを受け取る複数の銀行口座を持っている場合があります。これらの銀行口座は保有口座と呼ばれ、支払いの詳細をテキストファイルで請求システムに送信します。

支払いが請求システムの外部で手動または電子的に受け取られた場合、それらの支払いは自動化されたプロセスを使用してシステムにアップロードされ、請求書が決済されます。

自動支払い

請求システムは、クレジットカードまたはデビットカードの情報と自動支払い方法を毎月取得する機能を提供します。

クレジットカードまたはデビットカードのいずれかを使用して支払い方法が自動に設定されている場合、支払い要求はすべての請求書の後または特定の日付に自動的に生成され、これらの要求は支払い承認のために支払いゲートウェイ（または銀行）に送信されます。

すべての支払いが承認されると、それらは請求システムにアップロードされ、期日が到来した請求書を決済します。

手動支払い

現金または小切手を使用して支払いを行う場合は、顧客に事前にシステムに入力するか、一部の代理店がこれを収集する場合は、そのようなすべての支払いが収集され、請求によって提供される自動化された方法を使用して請求システムに転記されます。システム。

受け取ったすべての支払いについて、支払いファイルは事前定義された形式で準備され、請求システムがそれらを取得して請求データベースにアップロードする事前定義された場所に自動的にプッシュされます。

クレジットカードや小切手でのお支払いができない場合がございます。この支払いがすでにシステムに転記されている場合は、金額を調整するためにキャンセルする必要があります。請求システムは、失敗またはキャンセルされた支払いを処理するためのユーティリティを提供します。

支払いインターフェース

インターフェースは、支払いを受け取るための課金システムと他の外部システムとの間の境界です。インターフェースにより、2つのシステムが事前定義されたルールに基づいて他のシステムと通信できるようになります。

たとえば、単純なテキストファイルは、銀行と請求システムの間の支払いインターフェイスになります。インターフェイスがファイルベースの場合、銀行は事前定義された形式の支払いファイルを使用して支払いの詳細を送信し続けます。

銀行と課金システムの間にオンラインAPIベースのインターフェースが存在する可能性があります。オンラインインターフェースが設置されている場合、銀行は提供されたAPIを呼び出して、支払いを請求システムに直接転記します。

同様に、支払いの回収に関与するサードパーティ向けにファイルベースまたはオンラインのインターフェースが提供される可能性があります。

次は何ですか？

これまでのところ、私たちは通信顧客のライフサイクル全体をほぼ通過しました。次の章は、オペレーターと顧客の間で発生する紛争状況を理解するために重要です。

紛争とは何ですか？

紛争は、アカウントの金額に関するクエリの記録です。通常、顧客が請求書のある側面を照会すると、紛争が記録されます。紛争が発生する可能性があります-

• アカウントの請求書に対して。

• アカウントの特定の評価されたイベントに対して。たとえば、顧客が停電のために特定のペイパービューTVイベントに異議を唱えた場合です。

紛争の処理

紛争が記録された後、それは調査され、検証されます。

• Accept −提起された紛争が顧客側から有効である場合、紛争は受け入れられ、顧客に返金されます。

• Reject −紛争が受け入れられないことが判明した場合、紛争は拒否されます。

• Cancel −紛争が誤って入力された場合、紛争は取り消されます。

紛争については以下の点に注意し、課金システムはこれらの点をサポートする必要があります-

• 金額の異議申し立てステータスが保留中の間、コレクションアクションはエスカレーションされませんが、コレクションはこの期間中にエージングされます。

• 異議のあったイベントは、請求されるまでコレクションの計算に含まれません。この後、コレクションは通常どおりエージングされます。

調整とは何ですか？

調整は、任意の金額でアカウントに貸方記入または借方記入する方法です。調整は、アカウント全体に対して、またはそのアカウントの特定の評価されたイベントに対して行うことができます。

請求システムでは、さまざまなタイプの調整を作成できます。これはさまざまな状況で使用でき、各調整はさまざまな承認段階を通過します。

異議申し立てが受け入れられた場合、異議のあった金額をアカウントに入金するための調整が作成されます。調整は、承認されるまでアカウントの残高に影響を与えないようにする必要があります。承認待ちのステータスの調整は、請求や回収には影響しません。

税金込みのアカウントに対して行われる紛争および調整は、税金を含むものと見なされます。総額が入力され、請求書に出力できるようになります。

次は何ですか？

次の章では、管理に必要なさまざまなタイプのレポートについて説明します。すぐに使用できるレポートのリストがあり、カスタム開発が必要なレポートがいくつかある場合があります。

システムの財務、販売、パフォーマンスに関する貴重な情報を経営陣に提供するために、さまざまなレポートが生成されます。財務レポート、管理レポート、調整レポート、ネットワークアクティビティレポートなど、さまざまな種類のレポートを生成できます。

レポートには、ビジネスの成功を促進し、ビジネスの状態を監視し、問題のある領域を特定して適切な修正措置を講じることができるようにするための情報が含まれています。

レポートは、どの請求システムもすぐに100％の要件を満たすことができない領域の1つです。間違いなく、マーケティング部門または財務部門は、多くのカスタム開発を必要とするようなレポート要件を考え出します。

請求システムがデータウェアハウス（DWH）にデータをプッシュしている場合は、レポートアクティビティをDWHシステムに転送できますが、それでも多くの部門は、請求システムであるソースシステムから重要なレポートを取得したいと考えています。

レポートは2つのカテゴリに分類できます-

• Core/Canned Reports−これらのレポートは、システムのコア機能として課金システムによって提供されます。缶詰または標準レポートと呼ばれることもあります。

• Custom Reports −これらのレポートはシステムから直接利用できず、PL / SQL、PERL、またはシェルスクリプトなどを使用した開発が必要になります。

さまざまな課金システムが、さまざまな領域でさまざまなタイプのレポートを提供します。相互接続課金システムは、卸売課金を処理するため、レポートに関連するより多くの機能を提供する必要があります。

報告要件

以下は、さまざまな部門が必要とするレポートのリストです-

財務報告

支払いレポートは、一定期間中の顧客のアカウント支払いに関する情報を提供します。売掛金のエージングレポートは、売掛金、未払いの会費などに関する情報を提供します。

紛争および調整レポートは、紛争および調整の理由のパターンを特定するのに役立ち、そのような紛争および調整の理由を理解し、適切な是正措置を講じるのに役立ちます。

管理レポート

管理レポートは、顧客、その製品とサービスの使用状況、通話パターン、顧客フィードバックなどに関する情報を提供します。これらのレポートは、新しいサービスを導入するための顧客離れを減らすための適切な手順を実行するのに役立ちます。

チャーンは、顧客が1つのサービスプロバイダーから切断して別のサービスプロバイダーに移動するプロセスです。これは、不十分なカスタマーサービス、競争力のある製品の欠如、競争力のある料金の欠如などの多くの理由が原因である可能性があります。顧客の移転。

調整レポート

これらのレポートは、収入と支出のすべてのソースが監視されており、いかなる種類の収入の漏洩もないことを保証する収入保証（RA）情報を提供します。たとえば、ネットワークシステムの漏えいや調停や請求の間違い、新しいサービスの迅速な導入の要求など、さまざまな理由で収益が失われる可能性があります。

収益保証レポートは、適切なアクションを実行できるように、リークがどこにあるかを特定するのに役立ちます。

ネットワークアクティビティレポート

これらのレポートは、ネットワーク輻輳の領域を特定するための情報を提供し、これらの問題を克服するための修正措置（リソースの再ルーティングまたは追加）を実行できるようにします。

その他のレポート

以下はさらに、請求システムから要求される可能性のある他のいくつかのレポートの架空のリストです。

シニア番号	レポートの説明
1	クレジットクラス、顧客の詳細、価格プラン、料金タイプなどによって特定の日付範囲の収益情報を要約する収益分類レポート。
2	主にコレクションの追跡を支援するために提供される顧客の詳細、経年売掛金、および未決済アイテムのレポート。
3	日記レポートは、その日の活動を要約し、総勘定元帳情報を提示します。
4	データベース内の製品と特定の請求/評価カタログで利用可能なパッケージの詳細を提供する製品およびパッケージレポート。
5	アウトバウンド相互接続CDRの調整を容易にする相互接続契約アカウンティング（IAA）レポート。
6	毎日のアクティブ化、終了、ポートイン、またはポートアウトの総数。
7	毎日の与信限度額に違反しているアカウントの総数と、クレジット違反で発生している収益。
8	正常に評価され、内部に投稿され、特定の期間に無料で投稿されたイベントの数に関するレポート。
9	特定のサービスまたはすべてのサービス（音声、SMS、MMSなど）の重複イベントレポート
10	特定のサービスまたはすべてのサービス（音声、SMS、MMSなど）の拒否されたイベントレポート

自動vs手動

月次、週次、または日次ベースで必要なレポートのリストが存在する可能性があります。そのため、このようなタイプのレポートは、システム内で利用およびスケジュールされていない場合に作成されるため、手動による介入なしでエンドユーザーの電子メールボックスに送信できます。

いくつかの要件に基づいて時々異なるレポートの要求があり、そのようなタイプのレポートは事前に想像して開発することはできません。したがって、これらのレポートは、さまざまなユーザーからの要求に基づいて作成および送信されます。

次は何ですか？

次の章から、さまざまな種類の請求について説明します。たとえば、小売、卸売、MVNO、ローミングなど。

ほとんどのオペレーターは、顧客に2つのオプションを提供しています。 postpaid または prepaid接続。ポストペイド接続とプリペイド接続には、それぞれ長所と短所があります。

通常、オペレーターは前払いの顧客で構成される70％〜80％の顧客ベースを持ち、残りの顧客ベースは後払いの側から来ます。オペレーターにとって、後払いの顧客を増やすことは常に良いことです。

2種類の顧客、サービスとシステムの違いについて知りたいと思うかもしれません。2つの間のいくつかの主な違いをリストアップしましょう-

• Service Payments−これは、2つの顧客ベースを区別する最も重要な要素です。プリペイドのお客様はサービスを利用する前に前払いしますが、ポストペイドのお客様は月中提供されているサービスを利用し、月末に所定の時間枠内に料金をお支払いいただきます。

• Charging & Billing −プリペイドのお客様は、すべての使用量をリアルタイムで請求する必要がありますが、ポストペイドのお客様は月末に請求することができます。

• Service Offerings−後払い課金システムは、リアルタイム課金システムと比較してより柔軟性があります。たとえば、リアルタイム課金システムは、複雑なビジネス顧客の階層を維持するための柔軟性がありませんが、後払いの課金システムは、Nレベルまでの顧客階層を処理できます。

• Support & Maintenance−オペレーターは、両方の事業に同じ注意を払う必要があります。プリペイドビジネスの場合、オペレーターが操作を制御するための熟練した人材を必要とする場合、同時にオペレーターは、課金、請求、および操作上の問題の修正に関連するポストペイド顧客のクエリを処理するための優秀なスタッフを必要とします。

• Supported Network−昔、プリペイド接続とポストペイド接続のネットワークは異なっていました。これは、プリペイド接続がポストペイドよりも優れた接続を提供する、またはその逆であるという苦情を呼び起こすために使用されていました。これは収束課金の時代であり、通信事業者は通信品質を損なうことなく同じネットワークでビジネスを運営しています。

後払いシナリオ

ネットワーク要素（スイッチ、SMSCなど）は、Usage Detail Records（UDR）またはCall Detail Records（CDR）と呼ばれる生の使用量を生成します。これには、課金システムに必要な情報が含まれています。

• 発番号（A番号）

• 着信番号（着信番号）（B番号）

• 通話開始日時（日時）

• 通話時間

• コールタイプ（MOC、MTCなど。MOCはモバイル発信コールを表し、MTCはモバイル終端コールを表します）

ネットワーク要素および他のサービスプロバイダーからの上記の生のUDRは、課金システムによって受信され、課金システムはこれらをシステムが理解できる形式に変換します。次に、上記のフォーマット済み/変換済みUDRがガイドされ、通話料金を請求する顧客/アカウントを見つけて、それに応じてイベントを評価します。

次に、上記の評価済みUDRが請求データストアに保存され、請求サイクル日に、請求プロセスがこれらの評価済みUDRを取得して処理し、支払い、税金、割引などを考慮して請求書/請求書をレンダリングします。

次に、顧客が請求書を支払い、請求システムが支払いの詳細で更新されます。以下は、上記の標準的な請求プロセスを示す図です。

プリペイドシナリオ

簡単に言うと、プリペイド請求の手順は次のとおりです。

• 顧客が電話をかけると、プリペイドスイッチングゲートウェイが発信番号を取得し、アカウント情報をリアルタイム課金システムに送信します。

• 上記の情報を使用したリアルタイム課金システムは、ユーザーの身元を認証し、料金表と通話の最大許容期間を使用して顧客アカウントの残りの残高を計算し、この情報をプリペイドゲートウェイに送信します。

• ゲートウェイが通話を確立します。

• 通話中、ゲートウェイは通話を監視して、ユーザーが最大許容通話時間を超えないようにします。

• 通話が終了すると、ゲートウェイは実際の通話時間をプリペイド課金システムに送信します。プリペイド課金システムは、実際の通話料金を計算してアカウントの残高を更新し、残りの残高を減らします。

次の図は、一般的なプリペイド請求のシナリオを示しています-

プリペイド請求プロセスには、通話完了後のアカウント情報の収集と更新に加えて、次の重要な手順が含まれます-

• Authenticating−認証は、ユーザーが本人であると主張していることを確認するプロセスです。ユーザーは、ユーザーIDと、パスワードなどの認証資格情報を提供します。システムはこれらを入力として受け入れ、ユーザーが有効であり、システムにアクセスできることを確認します。

• Authorizing−承認は、認証されたユーザーに許可されていることを確認するプロセスです。一般に、リモートアクセスダイヤルインユーザーサーバー（RADIUS）プロトコルは、システムへのアクセスを登録および承認された顧客に制限するために使用されます。

• Providing advice of charge (AOC)−これにより、イベントの前または後の通話の実際のコストに関する情報が得られます。AOCは、イベントの発生前または発生後のいずれかに、イベントの実際のコストをアドバイスする通信システムの機能を提供します。

電気通信の請求について話すとき、デフォルトでは小売りの請求についてです。前に説明したように、電気通信小売請求は次のように定義されます-

「電気通信請求は、使用量を収集し、それを集計し、必要な使用料とレンタル料金を適用し、最終的に顧客の請求書を生成するプロセスです。電気通信請求プロセスには、顧客からの支払いの受け取りと記録も含まれます。」

小売請求はエンドカスタマーと直接取引し、エンドカスタマーの期待と規制上の義務を満たすために多くの課題が伴います。次の基準を満たしている限り、請求は成功したと見なされます。

• Timely Billing−エンドカスタマーの請求書は、予定どおり、つまり名目上の日付で生成されています。ロジスティクス上の問題により、エンドカスタマーが時間どおりに請求書を受け取れない場合もありますが、期日にすべての期日請求書を作成するのはITの責任です。

• Billing Accuracy−これは、顧客満足度および規制上の義務の観点から最も重要な要素です。請求システムが正確な請求書を生成していない場合、合法性の観点から深刻なビジネス上の問題が発生するだけでなく、顧客を不幸な状態にする可能性があります。

小売請求と卸売請求

小売請求は最終顧客と個々の顧客への請求を扱いますが、卸売請求はビジネスの状況と性質に応じて次のエンティティへの請求を扱います-

• 電気通信事業者に関連する請求再販業者。

• 別のオペレーターの顧客に電話をかけるための相互接続を提供するための相互接続パートナーへの請求。

• 顧客がオペレーターのカバレッジエリアをローミングしたときにサービスを提供するための請求ローミングパートナー。

卸売請求は小売請求と比較して簡単であり、許容範囲の大きなレベルのしきい値を許可しますが、小売請求は常に100％正確である必要があります。2つの事業者のシステムで設定された価格の違いや、一部の通話がネットワーク要素で見落とされる可能性があるために評価された通話数の違いなど、さまざまな理由により、卸売請求が100％正確になることはありません。

ConvergysやAmdocsのような小売請求を処理するために使用されている特殊な請求システムがあります。請求システムは小売請求で有名ですが、ASCADEおよびINTEC請求システムは卸売請求で有名です。

卸売り請求は、割引やプロモーションの種類が多すぎないため、簡単なレポートを使用して小売り請求システムを使用して決済することもできますが、小売り請求はこれらすべての複雑さを必要とし、卸売り請求システムを使用して処理することはできません。

このチュートリアルでこれまでに説明したすべての概念は小売請求に関連しており、後続の章では、相互接続請求、ローミング請求、およびその他の請求タイプについて説明します。

相互接続は、他のサービスプロバイダーの呼び出しを処理するプロセスです。これにより、あるサービスプロバイダーの顧客が別のサービスプロバイダーの顧客と通信できるようになります。

2人のオペレーターAとBが相互接続パートナーでない場合、オペレーターAの顧客がオペレーターBの顧客と通信することはできません。

通常、オペレーターは、顧客が互いに通信できるように、互いに合意を維持します。これは、相互接続に従事するすべてのオペレーターに良いビジネスチャンスを与えます。当事者がそれぞれのネットワークを接続することに同意する相互接続ポイントは、「Interconnection Point"。

相互接続の例には、次のものがあります。

• 隣接する2つの競合しない電話ネットワークが相互接続されるため、一方のネットワークの加入者はもう一方のネットワークの加入者に電話をかけることができます。

• 長距離電話会社は、地元のサービスプロバイダーの施設へのアクセスを取得し、共通の顧客ベースに長距離サービスを提供する際にそのプロバイダーと競合します。

• 従来の有線電話と新しい無線携帯電話会社は相互接続しているため、従来の電話サービスの加入者は無線加入者に電話をかけることができ、その逆も可能です。

• 新しい競争力のあるローカル電話キャリアは、既存のキャリアと相互接続するため、共通のサービス領域で加入者を引き付け、それらの加入者が既存のネットワーク上の加入者に電話をかけることができます。

• 現在の電話会社の顧客は、ダイヤルアップインターネットサービスプロバイダーに電話をかけます。このプロバイダーは、競合するローカルキャリアの顧客です。

相互接続請求

これは、着信インターコネクトコール詳細レコード（CDR）に関連してインターコネクトパートナーに送信する請求書の作成プロセスです。

相互接続請求は、通話の発信と終了を成功させるために、インフラストラクチャが接続する各ネットワーク事業者との間で支払われる金額と受け取る金額の計算に関係します。コールを相互接続するためのCDRは、コールルーティング情報を有効な値のグループとして保持し、キャリアと国の詳細を識別します。

相互接続CDRのセットには、次の詳細が含まれていることに注意してください。

• CDRは、小売および卸売の顧客に請求可能なものです。これは、通信プロバイダーの収益です。ローカル請求とも呼ばれます。

• 相互接続プロバイダーに対してのみ請求可能なCDR。例：発信通話、発信トランジット通話、着信通話など。発信通話は費用であり、着信通​​話は電気通信プロバイダーの収益です。

相互接続課金システムは、すべての着信および発信相互接続CDRの価格設定を行います。通常、相互接続価格は、コールを伝送する着信または発信トランク相互接続ルートに基づいて、着信および発信相互接続CDRの両方に対して決定されます。最も一般的には、トランクIDは、相互接続課金システム内の一意の相互接続パートナーを表します。

決済プロセス

決済プロセスは、相互接続所有者から他のネットワークオペレーターの宛先へ、またはその逆に通話を伝送することに関与するネットワークオペレーター/キャリアを決済するために使用されます。

このプロセスにより、決済のために送信（相互接続所有者への費用）および受信（相互接続所有者への収益）トラフィックが発生します。

決済は、手動または自動化されたプロセスを使用して、毎月または隔週で行うことができます。パートナーの決済をどのようにサポートするかは、課金システムごとに異なります。

ネッティングプロセス

合意されたプロバイダー/キャリアの決済が完了した後に実行するために使用されるネッティング。ネッティングは、複数のサービスの複数の決済期間によって行われ、オペレーターレベルで同じ通貨をサポートします。

ネッティング方法には2つのタイプがあります-

• AFTER −オペレーターとプロバイダー/キャリア間の金額を差し引いた後のオペレーターの相互接続コストのネッティング後

• BEFORE −オペレーターとプロバイダー/キャリア間の金額を差し引くことなく、オペレーターの相互接続コストを相殺する前。

調整プロセス

これは、発信CDRに関連する相互接続パートナーからの請求書を照合するプロセスです。

相互接続パートナーは毎月、調整の目的でCDRを交換します。2つのパートナーによって提供されるCDRに不一致があることは非常に一般的です。

Billing Systemsは、着信および発信相互接続CDRの調整を容易にするレポートを提供します。これらのレポートは、コールタイプ、宛先、コストバンド、期間などのパラメータを保持するため、両方のオペレータがこれらのCDRを使用して、これらのパラメータを照合し、欠落しているCDRを特定できます。

いずれかのオペレーター側で一部のCDRが欠落していることが判明した場合があります。問題が解決しない場合は必要な調整を行った後、パートナー間でさまざまな交渉が行われ、最後に、影響を受ける相互接続パートナーにわずかな金額を支払うことで問題が解決されます。

相互接続コールシナリオ

異なる事業者間の合意のタイプに応じて、さまざまな相互接続呼び出しシナリオが存在する可能性があります。最も一般的に使用されるいくつかをカバーしてみましょう-

• オペレーターAの顧客は、オペレーターBの顧客に全国電話をかけます。この場合、オペレーターAはオペレーターBにいくらかの金額を支払います。

• オペレーターAは国際オペレーターと直接契約を結んでいないため、オペレーターAの顧客はオペレーターBを介して国際電話をかけます。この場合、オペレーターAはオペレーターBにいくらかの金額を支払い、オペレーターBは国際オペレーターの決済を担当します。

• オペレーターAの顧客は、国際オペレーターを使用して直接国際電話をかけます。この場合、オペレーターAは国際オペレーターに直接いくらかの金額を支払います。

上記のすべての通話は、音声、SMS、MMS、データなどです。

相互接続契約

相互接続を成功させるには、相互接続契約で、または規制当局からの規則または命令によって、次の問題に対処する必要があります。

• Prices and adjustments −これには、相互接続料金の初期レベル、相互接続料金が支払われる通貨の定義、および為替レートの変化とインフレを考慮して契約期間中に価格がどのように調整されるかが含まれます。

• Points of interconnection −相互接続が行われる物理的な場所と、相互接続で採用される技術基準が定義されています。

• Transport and traffic routing −コールがどのようにルーティングされ、コールを配信するために何が転送されるかについて、何らかの定義を行う必要があります。

• Quality of service −品質基準は、特に回線をプロビジョニングする時間とコールブロッキングレベルについて定義されており、これらの基準が満たされていない場合の救済策が定義されています。

• Billing and collection −交通データを収集する時期と方法、請求書を交換する時期と方法、および支払いを行う時期と方法を指定する必要があります。

• Reconciliation−交通データを照合し、相手方に問い合わせ、クレームを処理するためのプロセスも組み込む必要があります。不一致を解決するための手順は、仲裁、規制当局、または裁判所に頼ることを伴うことが多いので便利です。

• Numbering Plan −国の番号計画と番号リソースへの各オペレーターのアクセスを定義する必要があります。

• Traffic Load −相互接続ネットワーク間を流れるトラフィックを送受信する能力について話し合い、文書化する必要があります。

契約タイプ

オペレーターは、トラフィックを交換するためにさまざまなタイプの契約を結ぶことができます。最も一般的に使用される契約を以下に示します-

• Bi-Lateral Agreement−本契約に基づき、各当事者は、相互接続ポイントおよび/または1つ以上の直接相互接続において、ネットワークを介して他の当事者とデジタル通信トラフィックを交換することに同意します。異なるパートナー間の支払い決済は、契約に従って毎月または隔月ベースで行われます。この契約に従って、両方のオペレーターは、互いのネット​​ワークで通話を開始および終了できます。

• Uni-Lateral Agreement−この契約では、一方の当事者が相互接続で他方の当事者のネットワークにトラフィックを送信し、他方の当事者からトラフィックを取り戻すことはありません。異なるパートナー間の支払い決済は、契約に従って毎月または隔月ベースで行われます。

ローミングとは、モバイル通信の顧客が、別の事業者のネットワークを使用して、ホームネットワークの地理的範囲外を移動しているときに、自動的に電話をかけたり受けたり、データを送受信したり、他のサービスにアクセスしたりする機能です。

ローミングは、国内ローミングまたは国際ローミングのいずれかです。国内ローミングとは、モバイル加入者が、自分の事業者がカバレッジを持たない地理的領域で別のネットワークを利用することを意味します。これは、たとえば、ある国で完全にカバーされていないオペレーターによって使用されます。国際ローミングは、モバイル加入者が海外に旅行し、外国の事業者のネットワークを利用する場合に使用されます。

それは実際にどのように行われますか？サービスプロバイダーが特定の都市または国にネットワークカバレッジを持っていない場合、このサービスプロバイダーは、その都市または国にネットワークを持っている別のサービスプロバイダーとローミング契約を結びます。この契約に従って、別のサービスプロバイダーが、最初のサービスプロバイダーのローミング顧客に利用可能なすべてのサービスを提供します。

1つのローミングパートナーのエリアで生成されたCDRは、そのローミングパートナーによって収集および評価され、最終的にローミング顧客の実際のサービスプロバイダーに送信されます。実際のサービスプロバイダーは、事前定義されたサービス料金に基づいて、提供されるすべてのローミングサービスに対してエンドカスタマーに請求します。

2つのローミングパートナーは、実際のローミングCDRとそれらのCDRに基づくレポートを交換することにより、月次ベースで財務を決済します。

HPMNおよびVPMN

ザ・ Home Public Mobile Networkモバイル加入者がサブスクリプションを持っているオペレーターからのネットワークです。この用語は、ではなく使用されますVisited Public Mobile Network （VPMN）。

Visited Public Mobile Networkは、ローミング中にモバイル加入者が使用するネットワークです。この用語は、Home Public Mobile Network（HPMN）とは対照的に使用されます。

クリアリングハウス

MACHのように、さまざまなローミングパートナー間でインターフェイスを取り、CDRの交換、ローミング契約の設定、および紛争の解決を支援する有名な団体があります。

クリアリングハウスは、あるローミングパートナーからインバウンドローマーの請求記録を受け取り、このローマーがアウトバウンドローマーと呼ばれる別のローミングパートナーに請求記録を送信します。

TAP3とは何ですか？

Transferred Account Procedure version 3（TAP3）は、訪問先ネットワーク事業者（VPMN）がローミング加入者の請求記録をそれぞれのホームネットワーク事業者（HPMN）に送信できるようにするプロセスです。TAP3は標準の最新バージョンであり、ネットワークが顧客に提供する予定の多数の新しいサービスの請求を可能にします。

クリアリングハウスは、TAP3プロトコルを使用して、異なるローミングパートナー間ですべてのCDRを交換します。TAP3は、ローミングされた使用法に関する情報をネットワークオペレータ間で渡す方法と情報を定義します。これらのファイルは、単純なFTP接続を使用して交換されます。

TAPにはさまざまなバージョンがあります。TAPは、TAP1からTAP2、TAP2 +からTAP3に進化しました。最新のリリースであるTAP3には、衛星ネットワーク、WLAN、UMTS、およびその他の3Gテクノロジーでの標準間ローミングのサポートが含まれています。

• GSM TAP Standard TD.57− GSM Transferred Account Procedure（TAP）は、さまざまな国の携帯電話事業者間でローミング使用情報を転送するための形式と検証ルールを定義します。TAP3は、標準の3番目の仕様バージョンです。転送されるファイルはTAPファイルと呼ばれます。

• GSM RAP Standard TD.32− GSM Returned Accounts Procedure（RAP）は、転送されたTAPファイル/イベント内で見つかったエラーに関する情報を返し、それによってそれらのファイル/イベントの金銭的責任を拒否するための形式を定義します。転送されるファイルはRAPファイルと呼ばれます。

ローミング請求

モバイル加入者は別の国に旅行し、外国のネットワークで使用法を作成します。加入者に請求するには、この情報を加入者のホームネットワークに戻す必要があります。外部ネットワークは、スイッチなどから使用状況に関する情報を収集し、規格に定められた情報を含むTAPファイルを作成します。

次に、ファイルはホームオペレーターに（定期的に、通常は1日に少なくとも1つのファイル）エクスポートされます。ホームオペレーターはファイルをインポートし、その情報を使用してサブスクライバーに請求します。外国の事業者は通話を評価し、ファイル内のすべての通話について加入者のホームネットワークに課金します。ホームオペレーターは、収益を上げるために通話をマークアップまたは再評価できます。

MVNOとは何ですか？

MVNOは Mobile Virtual Network Operator。モバイル仮想ネットワーク事業者（MVNO）は、携帯電話サービスを提供する会社ですが、無線スペクトルの独自のライセンス周波数割り当てを持っておらず、携帯電話サービスを提供するために必要なすべてのインフラストラクチャを必ずしも持っていません。

MVNEは Mobile Virtual Network Enablerは、モバイルネットワークサービスの提供を可能にするために、課金、ネットワーク要素のプロビジョニング、管理、運用、基地局サブシステムと運用サポートシステムのサポート、バックエンドネットワーク要素の提供などのサービスをモバイル仮想ネットワーク事業者に提供する会社です。携帯電話の接続のように。

実際のMVNOは、実際の事業者からのモバイル製品およびサービスの再販業者ですが、ブランドは異なります。

たとえば、ネットワーク、スイッチ、課金システム、プロビジョニングシステム、カスタマーケアシステムなどを含むすべてのインフラストラクチャを備えたオペレーターAがいます。ここで、誰かが最小限の投資でテレコムビジネスを開始したい場合は、MVNOがオプションです。続行します。

MVNOは、定評のある事業者からサービスを一括購入し、都合に合わせてブランド名を変更し、事業者として販売します。実際のオペレーターはエンドカスタマーからの透明性を維持し、カスタマーはMVNOのエンドカスタマーになりたいと感じるでしょう。

状況に応じて、MVNOはオペレーターから1つ以上のインフラストラクチャコンポーネントを購入し、それに応じて支払うことができます。たとえば、MVNOはオペレーターからのネットワークのみを使用したい場合や、MVNOはオペレーターからのネットワークと充電システムを使用でき、カスタマーケアやプロビジョニングなどの残りのコンポーネントはMVNOによってセットアップできます。

MVNOは、SIMカード、ブランディング、マーケティング、請求、およびカスタマーケアの操作を完全に制御できます。

英国で最初に商業的に成功したMVNOはVirginMobile UKであり[3]、1999年に英国で発売され、現在英国には400万を超える顧客がいます。

MVNOサービス

通常、MVNOには独自のインフラストラクチャがありませんが、一部の主要なMVNOは、付加価値サービスを提供する手段を促進するために、独自のモバイルINインフラストラクチャを展開しています。MNVOは、無線機器などの既存のインフラストラクチャを商品として扱うことができますが、MVNOは、独自のインテリジェントネットワークインフラストラクチャの活用に基づいて、独自の高度で差別化されたサービスを提供します。

このようにして、各MVNOとネットワーク事業者は、独自のニッチ市場に焦点を合わせ、顧客のリーチとブランドを拡大するカスタマイズされた詳細なサービスを形成することができます。

ほとんどのMVNOは、プリペイド顧客のみを対象とし、音声、SMS、MMS、データ、ブロードバンドなどのプリペイドサービスのみを提供し、いくつかの優れた付加価値サービスを提供するために市場に出回っています。

MVNO請求

現職の事業者がインフラストラクチャをMVNOに販売すると仮定すると、現職とMVNOの間には異なるビジネスモデルと合意が存在する可能性があります。以下は最も一般的に使用されるものです-

• MVNOはサービスをブランド化し、市場で販売することができ、MVNEはそれらのサービスをエンドカスタマーに提供するのに役立ちます。ここでは、コミッションの固定パーセントがMVNEに送られます。

• MVNOは、製品やサービスを特別割引価格でまとめて購入し、その名前でブランド化して市場で販売することができます。

• MVNOは製品とサービスを販売し、エンドカスタマーによって生成された使用量に基づいて、MVNOはMVNEに金額を支払います。

いずれの場合も、MVNOはMVNEにいくらかの保証金を支払う必要があり、その後、MVNEによって生成された簡単なレポートを使用して毎月の決済が行われます。

MVNEは、MVNOが後払いサービスを提供し、MVNOに提供されるすべての製品とサービスを追加できる限り、法人顧客として課金システムにMVNOを追加できます。毎月の終わりまでに、または通常2週間ごとに、請求書を生成し、収集をフォローアップすることができます。

ただし、通常、ほとんどのMVNOはプリペイドサービスを提供し、プリペイドシステムで処理されます。このような場合、MVNO機能は、プリペイドシステムに組み込まれている機能を使用するか、個別のサービスクラスを定義するだけで実現されます。すべての使用状況CDRおよびその他の情報は、データウェアハウスにダンプされ、そこからレポートを生成して請求書を作成できます。

コンバージェントビリングとは何ですか？

オペレーターがモバイル音声、固定音声、データ、IPTV、ブロードバンド、プリペイド、ポストペイドなどのさまざまなサービスを提供していると仮定します。顧客は、同じオペレーターからこれらのサービスを1つ以上受けることができます。一般的な顧客は、自分のアカウントの単一の請求書と単一のビューを確実に望んでいます。

一括請求とは、すべてのサービス料金を単一の顧客請求書に統合し、顧客のビューを統一することです。お客様はコールセンターに電話し、選択したすべてのサービスの完全なアカウント情報を入手する必要があります。顧客は単一の請求書を受け取り、すべてのサービスに対して単一の支払いを行います。

真に収束的な請求システムは、製品と市場セグメントのタイプ、つまりプリペイドサービスとポストペイドサービスに関係なく、製品とサービスの任意の数と組み合わせを1つの請求書に統合できる必要があります。

コンバージド課金に寄与するもう1つの重要なパラメータは、プリペイドおよびポストペイドの顧客向けの単一の製品および価格カタログです。

コンバージェント請求のメリット

収束請求は、オペレーターが次の主要な利点を達成するのに役立ちます-

• 単一の製品およびサービスカタログにより、市場投入までの時間が短縮され、実装コストが削減されます。

• 統一された請求書により、サービス間の割引が可能になるため、複数のサービスを注文した顧客は優遇価格を受け取ることができます。

• コンバージェント課金により、マルチサービスのパッケージ化と価格設定が可能になります。これにより、既存の顧客は新しいサービスを追加するように誘惑され、新しい顧客は革新的なサービスバンドルに引き付けられます。

• 両方のタイプの顧客（プリペイドおよびポストペイド）に対する一元化されたカスタマーケアとサポート。

主なボトルネック

これまでのところ、真のコンバージェンスを達成することは、すべての大手通信事業者の夢でした。明日には、すべての製品とサービスの真のコンバージェンスをサポートする課金システムが登場する可能性がありますが、今日では、実際のコンバージェンスを達成するために次の障害があります。

• EricssonINやNokiaSiemens Charging Systemなどのリアルタイム充電システムは、プリペイド製品やサービスのソリューションを提供する非常に人気のあるシステムです。これらのシステムは、後払いの顧客に必要なさまざまな機能を処理するのに十分な柔軟性がありません。たとえば、複雑な顧客階層、CDRの再評価、ボリュームディスカウント、柔軟なレポート、ローミング課金、相互接続課金などです。

• ConvergysInfinysやAmdocsBilling Systemsのような後払いの請求システムは、後払いの製品やサービスに最適です。これらのシステムは、プリペイドトラフィックを処理し、リアルタイムで通話を課金することはできません。重要なことに、これらのシステムは、基本アーキテクチャーのために高可用性を実現できません。

上記の2つの制約を一緒に保ちながら、プリペイドシステムとポストペイドシステムの間で一種のインターフェイスを実行して両方のシステムをマージすると、真の収束を実現できる可能性があります。ConvergysやEricssonのような企業は、2つのシステムを統合し、両方のタイプのシステムから必要な機能を使用して、それらを単一の収束課金システムにするために同じ方向に取り組んでいます。

サポートとメンテナンスは、テレコム運用の不可欠で最も重要な部分です。顧客満足度は、どれだけ効率的で、どれだけ優れたサポートが提供されているかに直接依存します。顧客がループに陥っていて、提起された問題/問題に対して適切な応答が得られない場合、顧客は単に別の利用可能なオペレーターに切り替えるでしょう。

サポートとメンテナンスは、次の主要な領域をカバーしています-

• System support and maintenance−これには、BSS（ビジネスサポートシステム）とOSS（運用サポートシステム）を正常に実行し続けることが含まれます。いずれかのシステム（請求、プロビジョニング、ネットワーク、調停、カスタマーケアなど）に問題がある場合は、スペシャリストが調査し、最小限の時間枠内で修正します。

• Customer Support−これには、顧客に関連するすべての問題の修正が含まれます。顧客はカスタマーケアまたはコールセンターを通じて苦情を申し立て、さまざまな段階でフローを発行します。この問題は、信号、通話の切断、音声またはデータのダウンロード品質、間違った請求、一部の紛争、サービスのアクティブ化、または終了などに関連している可能性があります。

• System upgrades−これには、既存のシステムを最新バージョンにアップグレードして、ビジネスの安定性と柔軟性を高めることが含まれます。システムの新しいバージョンには、新しいビジネス要件に対応するための新機能が付属しています。これには、システムパフォーマンスを維持し、ストレージを増やすためのハードウェアのアップグレードも含まれます。

サポートレベル

サービスプロバイダーは常にさまざまなレベルのサポートを提供しています。これらのレベルは、その性質と重大度に応じて、さまざまなタイプの問題を処理します。最も一般的に使用されるサポートレベルは次のとおりです-

• Level 1−顧客は、コールセンターである可能性のあるカスタマーサポートに連絡し、カスタマーサポートスペシャリストが顧客の問題に耳を傾け、その場で解決策を提案します。たとえば、電話を再起動するだけで解決できる問題が発生する可能性があります。したがって、効率的なカスタマーケアスペシャリストはそのようなタイプの問題を知っており、問題（通常はトラブルチケットと呼ばれます）を次のレベルにエスカレートすることなく解決策を提案できます。

• Level 2−カスタマーケアスペシャリストが問題を解決できない場合、問題はテクニカルスペシャリストのグループである第2レベルのサポートにエスカレーションされます。これらのスペシャリストは情報技術（IT）部門に属しており、問題を理解できる場合は、解決策を提案してレベル1に戻すことができます。それ以外の場合は、問題の性質をチェックして、問題が関連しているかどうかを理解します。ネットワークまたは課金システムまたはプロビジョニングシステムまたはハードウェアなどであり、問​​題の性質に基づいて、問題は次のレベル、つまり部門に割り当てられます。

• Level 3−これらは、コアエンジニアリング、無線計画、請求、プロビジョニング、注文管理などの分野に特化したさまざまな部門です。問題がエスカレートされた場合、問題を分析し、問題の根本原因を突き止めようとします。ほとんどの場合、問題は、その分野に特化した高度なスキルを持つエンジニアであるため、第3レベルのサポートによって診断および修正されます。システムのコア機能に関連している可能性があるため、第3レベルのサポートでは問題を修正できない場合がありますが、これは第3レベルのサポートでは変更できません。このような場合、問題はさらに第4レベルのサポートにエスカレートされます。

• Level 4 −これらは、課金システム、ネットワークスイッチ、プロビジョニングシステムなど、ビジネスをサポートするシステムの実際のベンダーです。したがって、問題が課金システムのコア機能に関連していることが判明した場合、たとえば、課金システムはできません。正しい割引を適用するには、課金システムベンダーにエスカレーションし、問題がプロビジョニングシステムのコア機能に関連している場合は、プロビジョニングシステムベンダーにエスカレーションします。

サービスレベルアグリーメント（SLA）

サポート部門は常に、SLAと呼ばれる事前定義されたサービスレベル契約を使用して作業します。これらのSLAは、さまざまなパラメータを念頭に置いて定義され、適切に維持されます。例-

• 問題または運用タスクの重大度。

• 問題または運用タスクのビジネスへの影響。

• 問題または運用タスクが単一の顧客または複数の顧客に影響を与えているかどうか。

• 問題または運用タスクが収益の損失または顧客満足度に直接関連しているかどうか。

このようなタイプのパラメーターに基づいて、さまざまな優先順位が定義され、さまざまな問題または運用タスクに割り当てられます。運用タスクには、レポートの生成、請求書の生成、データベースのクリーンアップアクティビティ、またはバックアップアクティビティがあります。

最後に、各問題と運用タスクには優先度が割り当てられており、各優先度にはSLAが関連付けられています。たとえば、顧客注文の作成に問題がある場合、それはビジネスに直接影響を与えるため、優先度の高い問題と見なされます。このようなタイプの問題は、割り当てられた部門ができるだけ早く解決する必要があります。そのため、優先度の高い問題に対して非常に厳しいSLAが定義されています。

SLAは、ビジネスニーズを最優先に保ちながら、相互に合意して議論および最終決定されます。通常、SLAは次の情報を保持します-

• 優先度1の問題、2番目の優先度の問題、または3番目または4番目の優先度の問題であるかどうかに関係なく、問題の性質を修飾するパラメーター。優先度の数値が低いほど、問題の重要度は高くなります。

• 特定の種類の優先度と重大度について、問題の解決にかかる時間。

• SLAに失敗した場合、どのようなペナルティが適用されますか。

• サポートの各レベルのエスカレーションの連絡先。

• 問題解決中のプロセスフローと通信媒体。

• 問題の解決に影響を与えるインフラストラクチャの可用性およびその他の制約。

SLAは、相互接続の場合にも、異なる部門間、ベンダーとオペレーター間、および異なるオペレーター間で定義できます。

次の図は、課金システムの一般的なアーキテクチャを示しています。この章では、すべてのインターフェースシステムを上から下に簡単に紹介します。

CRM / OMOFシステム

これは、顧客の注文が取得され、顧客がシステムに作成される最初のシステムです。CRMの略Customer Relationship Management OMOFはの略です Order Management and Order Fulfilment。

CRMとOMOFのモジュールを提供するSiebelのようなシステムがあります。CRMシステムは、製品やサービスとともに顧客関連の情報を保持します。OMOFモジュールは、作成から完了までの順序を追跡する責任があります。

ここでは、2つの可能性があります-

• CRM（顧客関係管理）/ OMOF（注文管理および注文履行）システムは課金システムと連絡を取り、課金システムはプロビジョニングシステムと連絡を取り、サービスとネットワークインベントリシステムをプロビジョニングし、電話番号やIPアドレスなどを割り当てます。

• 2番目の可能性は、CRM / OMOFシステム自体がプロビジョニングシステムと接続して、サービスとネットワークインベントリシステムをプロビジョニングし、電話番号やIPアドレスなどを割り当てることです。

プロビジョニングシステム

このシステムは、課金システムまたはCRM / OMOFシステムのいずれかからコマンドを受け取り、サービスをアクティブ化、非アクティブ化、および一時停止します。どちらのアーキテクチャも有効であり、アーキテクトがセットアップ全体をどのように設計するかによって異なります。

プロビジョニングコマンドを実行した後、このシステムはコアネットワークシステムと接続して、サービスをアクティブ化、非アクティブ化、または一時停止します。プロビジョニングが成功すると、このシステムは、最後のコマンドを送信したユーザーに応じて、課金システムまたはCRMシステムのいずれかに応答を送り返します。

ネットワークインベントリシステム（NIS）

このシステムは、電話番号、MSISDN、IPアドレス、電子メールアドレスなどのすべてのネットワーク識別子を維持し、技術的にはネットワークインベントリシステムと呼ばれます。

システムアーキテクチャに応じて、CRM / OMOFまたはBillingSystemのいずれかがNISに連絡して、必要なネットワークIDを取得し、注文作成時にそれを顧客に割り当てます。

このシステムは、ネットワーク識別子のライフサイクルを維持する責任があります。ライフサイクルは、使用可能から始まり、アクティブ化、一時停止、終了、隔離、そして再び使用可能などのさまざまな段階を経て流れます。

ネットワークスイッチ

通常、課金システムはネットワークスイッチと相互作用しません。ネットワークスイッチは、顧客にプロビジョニングされたサービスに基づいて、エンドカスタマーにすべてのサービスを提供する責任があります。これらのシステムは、通話、データのダウンロード、SMS転送などを制御し、最終的に通話詳細レコードを生成する役割を果たします。

ネットワークスイッチには、MSC、SMSC、GGSN、およびMMSCが含まれます。GSM、MSC、SMS、SMSC、GGSN、MMS、MMSCの詳細については、GSMチュートリアルを参照してください。

調停システム

メディエーションシステムは、さまざまなネットワーク要素からさまざまな形式でCDRを収集します。さまざまなネットワーク要素がASN.1形式でCDRを生成し、一部のネットワーク要素には独自の形式のCDRがあります。

仲介システムはすべてのCDRを処理し、それらをダウンストリームシステム（通常は課金システム）と互換性のある形式に変換します。調停システムは、CDRにさまざまなルールを適用してそれらを処理します。たとえば、調停システムは、ダイヤル番号（B番号）に基づいて国際電話にマークを付けます。同様に、調停システムは、A番号とB番号に基づいてオンネット通話にマークを付けます。

通話時間が5秒未満のすべての通話を除外する必要がある場合があります。このような種類の通話を除外するのに最適な場所は、メディエーションシステムレベルです。同様に、請求に重要な追加情報がCDRで必要な場合、メディエーションシステムは、CDR内で利用可能な他の属性に基づいてそのような情報を提供するのに役立ちます。

収集されたCDRが処理されると、通常、メディエーションシステムと課金システムは異なるマシンで実行されるため、メディエーションシステムはFTPを使用してすべてのCDRを課金システムにプッシュします。

データウェアハウス（DWH）システム

これは請求システムのダウンストリームシステムであり、通常、顧客に関連する大量の履歴データを保持します。Billing Systemは、さまざまな顧客情報をDWHシステムにダンプします。この情報には、サービスの使用状況、請求書、支払い、割引、調整などが含まれます。

このすべての情報は、さまざまなタイプの管理レポートの生成、およびビジネスインテリジェンスと予測に使用されます。

DWHシステムは常に大量の巨大なデータを処理することを目的としており、小さなレポートが必要な場合は、小さなタスクでDWHを悪用するのではなく、課金システムから直接生成する価値があります。

エンタープライズリソースプランニング（ERP）

エンタープライズリソースプランニング（ERP）システムは、財務、人事、サプライチェーン管理などを処理するモジュールを提供します。

このシステムとの請求システムインターフェースは、請求書、支払い、調整などのすべての金融取引を転記するために使用されます。

このシステムは、財務部門の総勘定元帳のように機能し、必要なときにいつでも完全な収益情報を提供します。

ペイメントゲートウェイ

そのため、これは必ずしも完全なシステムではありませんが、請求システムと銀行、クレジットカードゲートウェイ、ショップ、小売店などのさまざまな支払いチャネルの間に位置する一種のカスタムコンポーネントである可能性があります。

すべての支払いチャネルは、支払いゲートウェイを使用して支払いを請求システムに転記し、顧客の請求書を決済します。

通常、Payment Gatewayは、一種のAPI（Application Programming Interface）を外部に公開して、支払いを請求システムに送信します。APIは、支払いを転記するために任意の外部リソースで使用できます。