Enterprise ITSM & Service Inventory Platform for a National Wholesale Fiber Operator

Client Profile

A national wholesale fiber infrastructure provider supplying connectivity to dozens of ISP partners across the United Kingdom. The operator manages a growing fiber network with complex dependencies across devices, circuits, locations, and partner relationships — all requiring rigorous tracking, incident management, and service lifecycle governance.

The organisation operates within a broader technology ecosystem that includes a dedicated order fulfilment and activation platform (managed by a separate team), an Azure-based data lake for business intelligence, and enterprise-grade security and monitoring tooling. GoZupees was engaged not as a voice agent provider, but as the software engineering partner responsible for designing, building, and operating a core operational platform.

Industry: Telecommunications (Wholesale Infrastructure) · Region: United Kingdom · Products Used: ProGZ Platform (CMDB · Service Inventory · ITSM) · AWS Infrastructure · Enterprise Integrations

The Challenge

The operator had outgrown its tooling. As the network expanded and the ISP partner base grew, the gap between what the business needed to track and what existing systems could handle became a serious operational risk.

There was no single source of truth for services.

The operator sold wholesale connectivity to ISP partners — but the full picture of which services were active on which circuits, at which locations, serving which partners, on which contractual terms, was spread across spreadsheets, legacy databases, and tribal knowledge. When an ISP partner called asking “what services do I have with you?” the answer required a human to manually collate information from multiple sources. When a network fault occurred, understanding which partners and which services were affected required the same manual assembly — under time pressure.

Incident management was informal and unscalable.

Tickets were being tracked in email threads, shared documents, and basic tools that couldn’t enforce SLA timelines, priority-based escalation, or structured workflows. As the partner base grew, the volume of incidents, change requests, and service queries exceeded what informal processes could manage. SLA compliance reporting — a contractual obligation to ISP partners — was a manual, error-prone exercise conducted after the fact rather than tracked in real-time.

The network inventory was disconnected from the service layer.

The operator knew what devices existed on the network (routers, switches, OLTs, cabinets) and separately knew what services had been sold to partners. But the mapping between the two — which device supports which service, what’s the impact chain if this device fails, which services depend on this backhaul circuit — didn’t exist in a queryable, automated form. This meant that impact assessment during incidents was slow, capacity planning was guesswork, and change management couldn’t accurately predict blast radius.

The existing order fulfilment platform needed a counterpart.

The operator had invested in a dedicated order fulfilment and activation system (Tucana/OFX) that handled the provisioning lifecycle — from order receipt through to circuit activation. But once a service was activated, there was no platform to manage its ongoing lifecycle: monitoring SLA compliance, tracking incidents against that service, managing changes, and eventually handling decommissioning. The fulfilment system handed off into a void.

Our Approach

This was not a voice agent deployment. This was a full-stack enterprise software engineering engagement — designing, building, and operating a platform from the ground up on AWS infrastructure, integrated into the operator’s existing technology ecosystem.

We built ProGZ — a three-module platform comprising a Configuration Management Database (CMDB), a Service Inventory, and an IT Service Management (ITSM) system. The platform was designed as a cloud-native, containerised application with enterprise-grade security, monitoring, and integration capabilities.

What We Built

Module 1: Configuration Management Database (CMDB)

A structured, queryable database of every asset on the operator’s network and its relationships.

• Device inventory — every router, switch, OLT, ONT, cabinet, and piece of customer premises equipment registered with model, firmware version, location, rack position, and operational status.
• Relationship mapping — the dependency chain between devices. This cabinet connects to this aggregation switch, which connects to this core router, which connects to this upstream transit provider. When any device in the chain fails, the system can instantly calculate the downstream impact.
• Location hierarchy — sites, buildings, floors, racks, and slots — providing a physical-world context for every device.
• Change tracking — every modification to the CMDB is versioned with timestamp, author, and reason. The system maintains a complete audit trail of what changed, when, and why.
• API-first architecture — every data point in the CMDB is accessible via REST API, enabling other systems (monitoring, fulfilment, AI agents) to query the inventory programmatically.

Module 2: Service Inventory

The commercial layer that maps business services to the underlying infrastructure.

• Service catalogue — every product the operator sells to its ISP partners, with standard specifications, SLA tiers, and pricing parameters.
• Active service registry — every live service instance: which partner, which product, which circuit, which devices, what capacity, what contractual commitments. The definitive answer to “what services does Partner X have?”
• Service-to-infrastructure mapping — the critical link between what’s been sold and what’s physically delivering it. Service A runs on Circuit B, which traverses Devices C, D, and E, located at Sites F and G. This mapping enables instant impact assessment: when Device D fails, the system identifies every service affected and every partner impacted.
• Lifecycle management — tracking each service from provisioning through active operation to eventual decommissioning, with status transitions, date stamps, and associated documentation at each stage.
• Bidirectional integration with the order fulfilment system — when Tucana/OFX activates a new circuit, the service is automatically registered in ProGZ with full configuration details. When ProGZ identifies a service for decommissioning, the instruction flows back to the fulfilment system.

Module 3: IT Service Management (ITSM)

The operational workflow engine for managing incidents, changes, and service requests.

• Incident management — structured ticket lifecycle from creation through triage, investigation, resolution, and closure. Every ticket is linked to the affected service(s) and underlying infrastructure, providing investigators with immediate context.
• SLA tracking — real-time monitoring of response and resolution times against contractual commitments per partner and per service tier. SLA clocks start automatically on ticket creation and escalation triggers fire before breach, not after.
• Priority-based routing — incidents are classified by impact and urgency, with routing rules that ensure critical issues reach the right team immediately. A P1 incident affecting an enterprise-grade service for a Tier-1 partner triggers a different workflow than a P3 query about a standard residential circuit.
• Change management — structured workflows for planned changes to the network or services, with impact assessment (powered by the CMDB and Service Inventory), approval gates, implementation tracking, and post-implementation review.
• Service request management — handling partner requests for information, capacity changes, and administrative actions through standardised workflows with defined response times.
• Reporting and compliance — automated generation of SLA compliance reports per partner, per service, and per time period. These reports are contractual deliverables — automating their production eliminates a significant back-office burden and ensures accuracy.

Technical Architecture

The platform was built cloud-native on AWS:

• Compute: Amazon ECS (Fargate) — serverless containers eliminating server management overhead
• Database: Amazon Aurora PostgreSQL — enterprise-grade relational database for CMDB, Service Inventory, and ITSM data
• Storage: Amazon S3 — document storage for attachments, reports, and audit logs
• CDN & Frontend: Amazon CloudFront serving a React single-page application
• Security: AWS IAM with role-based access, AWS Secrets Manager for credential management
• Monitoring: Amazon CloudWatch and AWS CloudTrail for operational and security logging
• CI/CD: AWS CodePipeline, CodeBuild, and CodeDeploy for automated deployment
• Load Balancing: Application Load Balancer with AWS Certificate Manager for SSL/TLS

Enterprise Integrations

• Tucana/OFX — bidirectional API integration for order-to-service lifecycle continuity
• Azure Entra — SSO authentication for business users via the operator’s existing identity provider
• Azure Data Lake — data export pipeline for business intelligence and reporting
• Datadog — application performance monitoring via ECS sidecar agents
• Microsoft Sentinel — security log shipping to the operator’s SIEM platform

Environment Strategy

Four environments (Development, UAT, Pre-Production, Production) with separate AWS accounts per environment, ensuring isolation and compliance with enterprise security requirements.

Projected Impact

Metric	Before	After
Service impact assessment during incidents	Manual, 30–60 minutes	Automated, seconds
SLA compliance reporting	Manual compilation, days	Automated generation, real-time
”What services does Partner X have?”	Multiple sources, manual collation	Single query, instant
Incident routing accuracy	Human judgment, inconsistent	Rules-based, SLA-aware, automatic
Service lifecycle visibility	Fragmented across systems	End-to-end, single platform
Change management blast radius analysis	Tribal knowledge	CMDB-powered, automated
Audit trail completeness	Partial, informal	100%, versioned, queryable

Why This Matters

This case study demonstrates that GoZupees is not only a voice AI company. We are a software engineering firm capable of designing, building, and operating enterprise-grade platforms on modern cloud infrastructure — with the integration depth, security posture, and operational maturity that wholesale telecommunications operators require.

The ProGZ platform fills a critical gap in the operator’s technology stack: the space between order fulfilment (getting a service turned up) and network monitoring (knowing if the network is healthy). That space — understanding what services exist, who they serve, what they depend on, and whether they’re meeting their commitments — is where operational maturity lives. Without it, an operator is flying blind between “we provisioned it” and “something is broken.”

For any wholesale or infrastructure operator evaluating GoZupees, this engagement demonstrates that we understand the full operational stack — not just the customer-facing voice layer, but the systems, data models, and workflows that underpin a well-run network operation.