Customer & Subscriber Management

• cust > accesslog > adv
• cust > accesslog > all
• cust > acct > list
• cust > acct > vacct > 1001286 > 1287 > findetdv
• cust > actsess > all
• cust > autorenew > all
• cust > bulkrenew > all
• cust > cpo > banner mgmt
• cust > cpo > pfv
• cust > cpo > ppv
• cust > lead > all
• cust > lealineacct > list > all
• cust > lealineacct > postpaid > create > 0
• cust > set
• Customer & Subscriber Management – Overview
• Customer Creation & Classification
• Account Creation & Billing Relationship
• Service Association & Ownership
• Subscriber Creation & Identity Mapping
• Customer Search, Verification & Duplicate Prevention
• Customer Updates & Controlled Changes
• Service Lifecycle Actions – Suspend / Resume
• Service Termination / Disconnection & Data Retention
• Common Operational Scenarios & Troubleshooting

cust > accesslog > adv

cust > accesslog > adv

Route: cust/accesslog/adv

URL: https://admin.myslbb.com/#/cust/accesslog/adv

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Actions detected: Auto, Close, Customer, Access Request, Refresh

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

default

Captured URL: https://admin.myslbb.com/#/cust/accesslog/adv

---

drilldown_one_item

Captured URL: https://admin.myslbb.com/#/cust/accesslog/adv

cust > accesslog > all

cust > accesslog > all

Route: cust/accesslog/all

URL: https://admin.myslbb.com/#/cust/accesslog/all

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Actions detected: Auto, Close, Customer, Access Request, Refresh

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

default

Captured URL: https://admin.myslbb.com/#/cust/accesslog/all

---

default

Captured URL: https://admin.myslbb.com/#/cust/accesslog/all

---

drilldown_one_item

Captured URL: https://admin.myslbb.com/#/cust/accesslog/all

---

drilldown_one_item

Captured URL: https://admin.myslbb.com/#/cust/accesslog/all

cust > acct > list

cust > acct > list

Route: cust/acct/list

URL: https://admin.myslbb.com/#/cust/acct/list

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Headings detected: Search Customers
• Fields detected: Search Field, Search Type
• Actions detected: Auto, Close, Customer, Advanced Search, New Customer, Bulk Operations on Selected Accounts, Clear, Bulk Operations, s_vijay, vijay panchal, khan420, Khan, DSC_laxmipatil, Laxmi Patil, s_proficientsm, Proficientsm, DSC_rajeshchauhan, Rajesh Chavhan, 14b602, Prashant Sahu

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

default

Captured URL: https://admin.myslbb.com/#/cust/acct/list

---

ui_tab_1

Captured URL: https://admin.myslbb.com/#/cust/acct/list

---

ui_tab_2

Captured URL: https://admin.myslbb.com/#/cust/acct/list

---

ui_tab_3

Captured URL: https://admin.myslbb.com/#/cust/acct/list

---

common_tab_1

Captured URL: https://admin.myslbb.com/#/cust/acct/list

---

common_tab_2

Captured URL: https://admin.myslbb.com/#/cust/acct/list

---

common_tab_3

Captured URL: https://admin.myslbb.com/#/cust/acct/list

---

common_tab_4

Captured URL: https://admin.myslbb.com/#/cust/acct/list

---

drilldown_one_item

Captured URL: https://admin.myslbb.com/#/cust/acct/list

cust > acct > vacct > 1001286 > 1287 > findetdv

cust > acct > vacct > 1001286 > 1287 > findetdv

Route: cust/acct/vacct/1001286/1287/findetdv

URL: https://admin.myslbb.com/#/cust/acct/vacct/1001286/1287/findetdv

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Fields detected: Document Type, Status, Date Range
• Actions detected: Auto, Close, Customer, Service Account, View, Transactions, Edit, Change Status, Renew, Cancel Plan, Reset MAC, Change Password, Live Monitoring, eCAF, Apply Filter, Clear Filter, Add Debit Note, Add Credit Note

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

drilldown_one_item

Captured URL: https://admin.myslbb.com/#/cust/acct/vacct/1001286/1287/findetdv

cust > actsess > all

cust > actsess > all

Route: cust/actsess/all

URL: https://admin.myslbb.com/#/cust/actsess/all

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Fields detected: Search Field
• Actions detected: Auto, Close, Customer, Active Session, Refresh, Clear, sn19a1002, bn3x16x16, snsuraj1_pc, bn17x6x6, sl_suryakant, tnrch, lacreme_301, maplea_1301, sn15a103, rakeshsolanki, kanakia_c1404, inyatshaikh, baalwadi, bn17x4x7

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

default

Captured URL: https://admin.myslbb.com/#/cust/actsess/all

---

default

Captured URL: https://admin.myslbb.com/#/cust/actsess/all

---

drilldown_one_item

Captured URL: https://admin.myslbb.com/#/cust/actsess/all

---

drilldown_one_item

Captured URL: https://admin.myslbb.com/#/cust/actsess/all

cust > autorenew > all

cust > autorenew > all

Route: cust/autorenew/all

URL: https://admin.myslbb.com/#/cust/autorenew/all

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Fields detected: Type
• Actions detected: Auto, Close, Customer, Auto Renewal

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

default

Captured URL: https://admin.myslbb.com/#/cust/autorenew/all

---

create_new

Captured URL: https://admin.myslbb.com/#/cust/autorenew/all

---

drilldown_one_item

Captured URL: https://admin.myslbb.com/#/cust/autorenew/all

cust > bulkrenew > all

cust > bulkrenew > all

Route: cust/bulkrenew/all

URL: https://admin.myslbb.com/#/cust/bulkrenew/all

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Actions detected: Auto, Close, Customer, Bulk Renewal, Create Bulk Renewal Batch

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

default

Captured URL: https://admin.myslbb.com/#/cust/bulkrenew/all

---

default

Captured URL: https://admin.myslbb.com/#/cust/bulkrenew/all

---

create_new

Captured URL: https://admin.myslbb.com/#/cust/bulkrenew/all

---

create_new

Captured URL: https://admin.myslbb.com/#/cust/bulkrenew/all

cust > cpo > banner mgmt

cust > cpo > banner mgmt

Route: cust/cpo/banner-mgmt

URL: https://admin.myslbb.com/#/cust/cpo/banner-mgmt

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Actions detected: Auto, Close, Customer, Portal Setting, Upload Image

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

ui_tab_3

Captured URL: https://admin.myslbb.com/#/cust/cpo/banner-mgmt

---

common_tab_3

Captured URL: https://admin.myslbb.com/#/cust/cpo/banner-mgmt

---

common_tab_4

Captured URL: https://admin.myslbb.com/#/cust/cpo/banner-mgmt

---

drilldown_one_item

Captured URL: https://admin.myslbb.com/#/cust/cpo/banner-mgmt

cust > cpo > pfv

cust > cpo > pfv

Route: cust/cpo/pfv

URL: https://admin.myslbb.com/#/cust/cpo/pfv

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Actions detected: Auto, Close, Customer, Portal Setting, Edit

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

default

Captured URL: https://admin.myslbb.com/#/cust/cpo/pfv

---

ui_tab_1

Captured URL: https://admin.myslbb.com/#/cust/cpo/pfv

---

common_tab_1

Captured URL: https://admin.myslbb.com/#/cust/cpo/pfv

cust > cpo > ppv

cust > cpo > ppv

Route: cust/cpo/ppv

URL: https://admin.myslbb.com/#/cust/cpo/ppv

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Actions detected: Auto, Close, Customer, Portal Setting, Add Plans

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

ui_tab_2

Captured URL: https://admin.myslbb.com/#/cust/cpo/ppv

---

common_tab_2

Captured URL: https://admin.myslbb.com/#/cust/cpo/ppv

cust > lead > all

cust > lead > all

Route: cust/lead/all

URL: https://admin.myslbb.com/#/cust/lead/all

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Fields detected: Show All Closed Lead
• Actions detected: Auto, Close, Customer, Customer Lead, New Customer Lead, Clear

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

default

Captured URL: https://admin.myslbb.com/#/cust/lead/all

---

ui_tab_1

Captured URL: https://admin.myslbb.com/#/cust/lead/all

---

common_tab_1

Captured URL: https://admin.myslbb.com/#/cust/lead/all

---

common_tab_2

Captured URL: https://admin.myslbb.com/#/cust/lead/all

---

create_new

Captured URL: https://admin.myslbb.com/#/cust/lead/all

---

drilldown_one_item

Captured URL: https://admin.myslbb.com/#/cust/lead/all

cust > lealineacct > list > all

cust > lealineacct > list > all

Route: cust/lealineacct/list/all

URL: https://admin.myslbb.com/#/cust/lealineacct/list/all

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Actions detected: Auto, Close, Customer, Group Account, New Group Account, Add New Service Account, Clear

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

default

Captured URL: https://admin.myslbb.com/#/cust/lealineacct/list/all

---

ui_tab_1

Captured URL: https://admin.myslbb.com/#/cust/lealineacct/list/all

---

common_tab_1

Captured URL: https://admin.myslbb.com/#/cust/lealineacct/list/all

---

common_tab_2

Captured URL: https://admin.myslbb.com/#/cust/lealineacct/list/all

---

drilldown_one_item

Captured URL: https://admin.myslbb.com/#/cust/lealineacct/list/all

cust > lealineacct > postpaid > create > 0

cust > lealineacct > postpaid > create > 0

Route: cust/lealineacct/postpaid/create/0

URL: https://admin.myslbb.com/#/cust/lealineacct/postpaid/create/0

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Fields detected: Group Name, Group Segment, Group Phone, Group Email, Group Charge Type, Group Category Type, Person Name, Person Phone, Person Email, CAFNO, Address Line 1, Address Line 2, Pincode, Sub District, District, State, Tax Zone, Billing Area
• Actions detected: Auto, Close, Customer, Group Account, Create Group Account, Cancel

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

create_new

Captured URL: https://admin.myslbb.com/#/cust/lealineacct/postpaid/create/0

cust > set

cust > set

Route: cust/set

URL: https://admin.myslbb.com/#/cust/set

---

Overview

This page is a draft SOP reference for the above screen in i2i Core OSS/BSS. It is auto-generated from UI exports and should be reviewed for operational correctness before customer release.

When to Use

• Use this screen for the workflow represented by this route.
• Do not make billing/AAA/provisioning-impacting changes without required authorization.

Typical Workflow

1. Verify you are working on the correct entity (Customer/Account/Service).
2. Review the current lifecycle state before making changes.
3. Apply changes and validate system response.
4. Confirm downstream impact (AAA/Provisioning/Billing) where applicable.

Field & Action Hints (Auto-detected)

• Actions detected: Auto, Close, Customer, Settings

Validation & Safety Checks

• Confirm identifiers before saving.
• Confirm lifecycle state allows the change.
• Confirm rollback/support path exists for production actions.

Escalation Guidance

• L1: Verify input, permissions, and entity state.
• L2: Validate dependencies and downstream state.
• L3/Admin: Policy/config changes or suspected defect.

---

Screenshots

default

Captured URL: https://admin.myslbb.com/#/cust/set

Customer & Subscriber Management – Overview

Customer & Subscriber Management – Overview

Product: i2i Core OSS/BSS
Company: i2i Tech Services Private Limited

---

Purpose

The Customer & Subscriber Management module is the foundation of i2i Core OSS/BSS. It establishes the authoritative identity and ownership model used across AAA, provisioning, billing, reporting, and audit flows.

Conceptual Model

• Customer: Legal/commercial entity (individual/organization/partner).
• Account: Billing & service container under a customer.
• Service: A provisioned offering (broadband, leased line, add-ons) owned by an account.
• Subscriber: End endpoint/identity consuming the service (credentials + network identifiers).

Lifecycle

1. Create Customer → Create Account
2. Attach Service(s) to Account
3. Create Subscriber identity and map it to service
4. Activate → Operate (Modify/Suspend/Resume) → Terminate

Operational Principles

• Data integrity first: Avoid duplicates and uncontrolled edits.
• Controlled state transitions: Changes must be lifecycle-aware.
• Downstream impact awareness: Customer data drives AAA & billing behavior.
• Auditability: All changes must be traceable to a user and time.

Role Responsibilities

• L1/NOC: Create customers/accounts, routine updates, status checks, basic lifecycle actions.
• L2 Ops: Validate AAA/provisioning dependencies, handle complex corrections safely.
• L3/Admin: Policy, configuration, integration, and defect triage.

---

Screenshots

Screenshots not yet added.

Customer Creation & Classification

Customer Creation & Classification

Product: i2i Core OSS/BSS
Company: i2i Tech Services Private Limited

---

Purpose

Customer creation establishes the legal and operational identity for all downstream workflows in i2i Core OSS/BSS. Classification determines policy eligibility, billing ownership, provisioning constraints, and reporting visibility.

When to Create a New Customer

• New legal/commercial entity onboarding (residential, enterprise, partner/reseller).
• Contractually separate ownership requiring distinct invoicing/compliance.

When NOT to Create a New Customer

• Additional services for the same entity (create a new Account or Service).
• New location under the same agreement (use account/service mapping as per policy).

Classification Guidance

• Residential: Standard policies, minimal exceptions.
• Enterprise: SLA-sensitive, multi-service/multi-site, approvals often required.
• Partner/Reseller: Revenue-share/settlement logic; restricted operational permissions.

Mandatory Data & Verification

• Customer name (legal), classification, verified contact details.
• Installation & billing address mapping (as applicable).
• Uniqueness checks (avoid duplicates).

Validation & Controls

• Mandatory fields enforced; role-based permissions apply.
• Classification changes should be restricted after dependent entities exist.
• All creation actions must be auditable.

Downstream Impact

• Billing: invoicing entity, tax/compliance behavior, ownership.
• AAA: root ownership for subscriber identities and policy boundaries.
• Provisioning: service eligibility and lifecycle enforcement.

---

Screenshots

Screenshots not yet added.

Account Creation & Billing Relationship

Account Creation & Billing Relationship

Product: i2i Core OSS/BSS
Company: i2i Tech Services Private Limited

---

Purpose

Accounts represent the commercial and billing container under a customer. Accounts are used to group services, define billing ownership, and enforce policies such as billing cycle, credit controls, and operational constraints.

When to Create a New Account

• Separate billing relationship required (different GST/tax entity, cycle, or payer).
• Multi-site enterprise requiring separate service grouping and reporting.
• Partner/reseller models where settlement and ownership boundaries differ.

Key Attributes

• Billing owner and invoicing details
• Billing cycle / effective dates
• Payment terms / credit policy (if applicable)
• Account status (active/suspended/closed)

Workflow

1. Select the correct customer → Create Account
2. Set billing ownership & cycle
3. Validate address/tax/compliance data (if used)
4. Save → Confirm account readiness for service attachment

Validation & Safety

• Do not attach services to incorrect account; ownership impacts billing and reporting.
• Do not change billing cycle/effective date without approvals.
• Account closure must ensure services are terminated/archived per policy.

Downstream Impact

• Billing: invoice generation, adjustments, and ledger grouping.
• Service: services inherit account ownership and constraints.
• Reporting: KPIs roll up by account/customer hierarchy.

---

Screenshots

Screenshots not yet added.

Service Association & Ownership

Service Association & Ownership

Product: i2i Core OSS/BSS
Company: i2i Tech Services Private Limited

---

Purpose

Services represent the deliverable offering mapped to an account. Service association defines entitlement, provisioning scope, AAA applicability, and chargeability. Ownership must remain unambiguous to avoid revenue leakage and provisioning conflicts.

Service Ownership Rules

• A service must belong to exactly one Account at a time.
• Service identifiers must remain stable (IDs used by provisioning/AAA/billing).
• Ownership transfers require controlled workflow and audit trail.

Workflow

1. Open Account → Add/Attach Service
2. Select service type/plan/profile (as per product configuration)
3. Set activation/effective dates (if applicable)
4. Validate mandatory attributes → Save

Validation & Safety

• Confirm service type aligns with customer classification (residential vs enterprise vs partner).
• Confirm charging/rating applicability before activation.
• Do not edit service identifiers in production without escalation.

Downstream Impact

• Provisioning: triggers activation workflows and network mapping.
• AAA: defines authorization scope and service entitlement.
• Billing: determines recurring/one-time charges and invoice mapping.

---

Screenshots

Screenshots not yet added.

Subscriber Creation & Identity Mapping

Subscriber Creation & Identity Mapping

Product: i2i Core OSS/BSS
Company: i2i Tech Services Private Limited

---

Purpose

Subscribers represent the operational endpoint identity consuming a service (credentials + network identifiers). Correct mapping ensures authentication success, accurate accounting, and consistent service state across systems.

Identity Components

• Authentication identity: username/identifier used by AAA
• Authorization mapping: which service/plan/profile applies
• Network identifiers: MAC/VLAN/Circuit/Interface mapping where applicable
• Status: active/suspended/terminated aligned to lifecycle

Workflow

1. Open Service → Create Subscriber
2. Assign identity/credentials per policy
3. Map subscriber to service entitlement
4. Validate uniqueness → Save
5. Perform post-save validation (AAA/provisioning readiness)

Validation & Safety

• Credentials must be unique within the defined domain/policy scope.
• Ensure correct plan/profile mapping; wrong mapping causes speed/policy mismatches.
• Any production credential reset should be auditable and approved.

Troubleshooting Signals

• Authentication fails → check identity mapping and subscriber status
• Session starts but wrong policy → check service profile mapping
• Usage not visible → check accounting correlation and identifiers

---

Screenshots

Screenshots not yet added.

Customer Search, Verification & Duplicate Prevention

Customer Search, Verification & Duplicate Prevention

Product: i2i Core OSS/BSS
Company: i2i Tech Services Private Limited

---

Purpose

Search and verification reduces duplicate creation, prevents ownership errors, and ensures operational accuracy. This workflow must be executed before creating any new customer or account in production.

Minimum Verification Checks

• Search by primary phone and email
• Search by identity reference (customer code/ID, document reference if used)
• Search by address keywords (when phone/email are unknown)

Duplicate Prevention Rules

• Do not create a new customer if the same legal entity already exists.
• If multiple records exist, escalate for merge/dedup policy handling.
• Prefer updating verified contact fields rather than creating a second customer.

Operational Workflow

1. Search using strongest identifiers first (phone/email/customer ID).
2. Open matching record and verify classification and active services.
3. If match confirmed → proceed with account/service actions under the existing customer.
4. If uncertain → escalate for verification before creation.

---

Screenshots

Screenshots not yet added.

Customer Updates & Controlled Changes

Customer Updates & Controlled Changes

Product: i2i Core OSS/BSS
Company: i2i Tech Services Private Limited

---

Purpose

Customer updates must be controlled because changes can impact billing, compliance communication, and operational routing. This page defines safe update practices and approval boundaries.

Allowed Routine Updates (L1)

• Contact phone/email corrections (verified)
• Address corrections (as per SOP)
• Non-policy metadata updates (tags/notes if used)

Restricted Updates (Require Approval / L2-L3)

• Customer classification changes (residential ↔ enterprise ↔ partner)
• Billing owner / invoicing identity changes
• Compliance identifiers used in invoices or regulatory reporting

Safe Workflow

1. Confirm you are editing the correct customer (ID verification).
2. Review active services and accounts before changes.
3. Apply minimal change; avoid bulk edits.
4. Save and document reason/notes (as per policy).

Common Risks

• Wrong customer edited → downstream billing/communication issues.
• Unapproved classification change → policy mismatches and audit risk.

---

Screenshots

Screenshots not yet added.

Service Lifecycle Actions – Suspend / Resume

Service Lifecycle Actions – Suspend / Resume

Product: i2i Core OSS/BSS
Company: i2i Tech Services Private Limited

---

Purpose

Suspension and resumption are controlled lifecycle actions used to enforce policy (non-payment, misuse, temporary hold) without full termination. These actions must be consistent across customer/account/service/subscriber states.

When to Suspend

• Billing/collection policy trigger (as approved)
• Security/abuse policy trigger (as approved)
• Customer-requested temporary hold (if supported)

When NOT to Suspend

• When service must be permanently disconnected (use termination workflow)
• When entity ownership is unclear (verify customer/account first)

Operational Workflow

1. Open the service → verify current status and active subscriber identity.
2. Trigger Suspend → confirm reason code/notes (if required).
3. Validate downstream: AAA should deny/limit session as per policy.
4. For Resume: confirm approvals/collection closure → resume → validate sessions.

Validation

• Confirm the correct service and subscriber mapping before action.
• Confirm the expected downstream enforcement behavior (AAA state).
• Record action reason for audit trail.

Troubleshooting

• Service suspended but user still online → verify AAA session handling and session termination policy.
• Service resumed but cannot authenticate → verify subscriber status and mapping.

---

Screenshots

Screenshots not yet added.

Service Termination / Disconnection & Data Retention

Service Termination / Disconnection & Data Retention

Product: i2i Core OSS/BSS
Company: i2i Tech Services Private Limited

---

Purpose

Termination is the permanent lifecycle closure of a service/subscriber relationship. Termination must ensure charging is closed correctly, AAA access is revoked, and records are retained according to policy.

Pre-termination Checks

• Confirm customer/account ownership and correct service selection.
• Confirm billing closure or final invoice policy (as applicable).
• Confirm provisioning rollback policy (if applicable).

Operational Workflow

1. Open service → validate active state and dependencies.
2. Trigger Termination/Disconnection → select reason and effective date if used.
3. Validate downstream: AAA access revoked, sessions terminated as per policy.
4. Confirm billing closure behavior and data retention flags.

Retention & Audit

• Operational records should remain queryable for audit for defined retention period.
• Do not hard-delete production entities unless explicitly approved and supported by policy.

Common Issues

• Residual sessions after termination → check AAA session termination enforcement.
• Final invoice mismatch → check effective date and billing cycle alignment.

---

Screenshots

Screenshots not yet added.

Common Operational Scenarios & Troubleshooting

Common Operational Scenarios & Troubleshooting

Product: i2i Core OSS/BSS
Company: i2i Tech Services Private Limited

---

Scenario A: Customer exists but onboarding fails

• Verify customer classification and mandatory data completeness.
• Verify account exists and is active.
• Verify service can be attached to that account per policy.

Scenario B: Authentication fails after subscriber creation

• Verify subscriber is active and mapped to correct service/plan.
• Verify credential uniqueness and correct username format.
• Verify AAA policy assignment and service entitlement mapping.

Scenario C: Wrong speed/policy applied

• Verify service plan/profile mapping.
• Verify subscriber is mapped to the intended service and not a stale record.
• Re-check effective dates and policy inheritance rules.

Scenario D: Billing mismatch after ownership changes

• Verify account ownership and billing cycle/effective date alignment.
• Verify service is attached to the correct account.
• Escalate if correction requires ledger adjustments.

Escalation Guidance

• L1: Verify IDs, status, and basic mapping.
• L2: Validate AAA/provisioning/billing dependencies and run corrective SOP.
• L3: Policy/config/integration issues and suspected product defects.

---

Screenshots

Screenshots not yet added.