← AetherONE™ / ALL FAMILIES
AetherAetherONE™AetherCIS™

Customer information system

Party, Customer Account, Premise, Service Point, Service Agreement and Service Request identity and lifecycle.

PRODUCT OVERVIEW

Keep customer and service identity in one place.

AetherCIS is the customer-and-service component of AetherONE. Its design owns the identity and lifecycle of Party, Customer Account, Premise, Service Point, Service Agreement and Service Request.

The current edition is a read-only evaluation interface on synthetic data. It lets teams review customer and service relationships without presenting a live customer operation.

Who it is for

  • Customer-service and service-administration leads
  • Business analysts and integration architects
Concept illustration of customer, account, premise and service-location relationships.
Concept illustration of the product responsibility. It is not a customer installation or an operational record.
Open full-size image ↗

Responsibilities and evaluation scope

Party
Approved design scopePerson/organization identity and roles, separate from Customer Account; search, Customer 360, roles and duplicate review.
Available in this editionEvaluation interface with synthetic data; no live business operation or persistence.
Customer Account
Approved design scopeAccount identity and lifecycle, with list/detail views; not a financial ledger or portal login.
Available in this editionEvaluation interface with synthetic data; no live business operation or persistence.
Premise
Approved design scopeSite, building or unit receiving service, with a GIS address-validation projection; normalized location stays in GIS.
Available in this editionEvaluation interface with synthetic data; no live business operation or persistence.
Service Point
Approved design scopeElectricity service-location identity, list, 360 and creation wizard; distinct from an MDMS Metering Point.
Available in this editionEvaluation interface with synthetic data; no live business operation or persistence.
Service Agreement
Approved design scopeService relationship and responsibility, agreement detail, new service and move-in/move-out workflows.
Available in this editionEvaluation interface with synthetic data; no live business operation or persistence.
Service Request
Approved design scopeOriginating-request identity, intake, inbox and routing; it is not a Dispatch Work Order.
Available in this editionEvaluation interface with synthetic data; no live business operation or persistence.
Supporting views
Approved design scopeEntitlement inspection, customer portal preview, data quality/reconciliation and configuration.
Available in this editionEvaluation interface with synthetic data; no live business operation or persistence.
Optional supplier switching
Approved design scopeAn optional competitive-retail queue in selected demo profiles; no jurisdiction-specific market-rule claim.
Available in this editionEvaluation interface with synthetic data; no live business operation or persistence.

How the work connects

The original diagrams and interface excerpts below are in English. The surrounding description explains their scope in the page language.

CIS design responsibility map for customer/service identities and neighbouring products.
Design workflow. The relationships shown are not a claim of running cross-product integration.
Open full-size image ↗

Clear responsibility across products

AetherMDMS
Owns Metering Points, installations, channels/registers, measurements, VEE, Usage and technical Bill Determinants. CIS holds versioned references and compact projections only.
AetherGIS / AetherRevenue
GIS owns normalized addresses and spatial truth. Revenue owns financial work — tariffs, bills, payments, debt and prepayment — using financial-context account references. These documents do not establish a mapping between those references and the CIS Customer Account identity and lifecycle.
AetherDispatch
Owns work-order planning and field execution. CIS keeps the originating Service Request. The cis.service-request.created.v1 schema is a design contract; this edition neither produces nor delivers it.

Utility scenarios

A household moves

Review the Party, account, premise, service point and agreement as separate identities while following the intended move-in/move-out responsibility.

A reading is questioned

Start from the service relationship and request, then use explicit MDMS and field-work projections; synthetic linked records do not establish a live inquiry-to-visit flow.

A replacement is requested

CIS holds the request, Dispatch plans the work and collects field evidence, and MDMS commits the validated installation and continuity.

Evaluation views · synthetic data

The original diagrams and interface excerpts below are in English. The surrounding description explains their scope in the page language.

Synthetic Service Point list excerpt showing its CIS owner.
Evaluation interface excerpt with synthetic data. Identifiers, amounts, dates and counts are examples, not customer or performance evidence.
Open full-size image ↗

Edition and evaluation conditions

Read-only evaluation with explicit synthetic demonstration mode. Default views show no connected live records. There is no backend connection, authentication or persistence, and actions do not perform CIS business operations.

An operational deployment needs a CIS backend and private store, authentication/authorization and approved contracts with metering, spatial, revenue and field-work products. No customer installation, production deployment or measured capacity is claimed.

Document edition 2026.10 identifies the supplied documents, not a commercial release or a deployed version.

Product documents

Choose a language to download the matching document edition.

Discuss an evaluation ↗