Telecom ERP & Manufacturing ERP — Custom CRM, Billing & Operations

Industry

Telecom / VoIP operator ops

Type

Custom SaaS ERP + CRM

Role

Architecture + full-stack

Portals

Admin · Employee · Customer · Vendor

Stack

Next.js · NestJS · PostgreSQL · Redis

Walkthroughs

VoIP ERP 31:37 · Manufacturing 17:27

A VoIP or telecom manufacturer does not fail because the PBX is missing a CRM plugin. The problem is usually operational fragmentation: sales, telecom services, billing, inventory, purchasing, finance and HR operate as separate systems with no shared business workflow. A domain-specific ERP brings those workflows into one API-first platform. This is software — UnifiedPBX does not operate your ISP.

One ERP across sales, telecom operations, inventory, finance & HR

BUSINESS
                            │
          ┌─────────────────┼─────────────────┐
          ▼                 ▼                 ▼
         CRM             TELECOM           SALES
          │              OPERATIONS          │
          └─────────────────┼────────────────┘
                            ▼
                       INVENTORY → PURCHASING → FINANCE → HRMS

Instead of connecting five disconnected applications, the platform uses a shared API and data model so CRM, telecom billing, inventory, purchasing, finance and HR workflows operate against the same business context.

Who can use this architecture?

Cluster with Insurance ERP + WebRTC (CRM/ERP + contact center) and Custom CRM/ERP / Full-Stack / SaaS for productization.

The business problem

Work after the call (or after the order) lives in five tools:

• A spreadsheet of leads that never become quotes
• Separate “billing software” that does not know SIP vs FXS ports
• Stock and purchase orders in email
• HR and recruitment off to the side
• No shared workflow from lead → sales → inventory → purchase → finance

Off-the-shelf ERP is generic. Off-the-shelf CRM does not price port slabs. A custom product is the honest path when the domain is the business.

Why generic ERP isn’t enough for telecom businesses

A conventional ERP understands products, customers, invoices, suppliers and inventory.

A telecom ERP additionally needs:

• SIP ports and FXS ports
• Subscribers, service providers, circles and districts
• Billing cycles, port slabs, charge heads
• Voice plans, VAS, revenue sharing
• Telecom-specific billing lines—not a generic invoice SKU

Off-the-shelf CRM does not price port slabs. This implementation models SIP/FXS ports, slab rents, providers, circles, districts, subscribers, charges and earning heads as domain objects.

Telecom ERP vs generic ERP

The difference is the domain model, not the color of the dashboard.

See the ERP in action

Evidence first—two working-system walkthroughs (watch pages keep one video as main purpose). Same practice; not every frame is this Clixxo skin.

Super Admin in this session: users, customers, employees, vendors, inventory, subscribers, tickets and earning heads as small demo counts. Export/refresh are UI—not a published BI suite.

Business requirements

One admin console for the operator. Role portals so employees, customers and vendors do not share the Super Admin desk. CRM that knows Outright vs Telecom customers. Telecom that knows ports, circles, subscribers and bills. Inventory, purchasing and finance as modules—even when a capture is empty. HRMS that can post jobs. Workflows that are rows, not a slide. The UI never writes around the API. Redis is documented cache for hot reads, not a second database.

The solution

Next.js (App Router) for operations screens. NestJS and TypeORM on PostgreSQL as the system of record. JWT / Passport with module permissions. Login offers Super Admin, Employee, Customer and Vendor—leave unselected and the product routes by role; picking a dashboard that is not yours is denied.

Settings in this capture: company profile, billing locations, location hierarchy, SMTP/email, notification preferences, user/role management, security policies, backup/restore, system logs. Twilio SMS and Firebase push exist as configuration surfaces—this page does not claim those channels were live in the session, and does not print keys.

What is not claimed: two-factor as shipped (marked ready, not shown), native iOS/Android apps, AI lead scoring, a drag-and-drop workflow designer, or a “57% faster dashboard” as a published outcome.

CRM + ERP + telecom architecture

CUSTOM ERP
                             │
          ┌──────────────────┼──────────────────┐
          ▼                  ▼                  ▼
         CRM              TELECOM            ERP OPS
          │              OPERATIONS            │
          │            ┌─────┼─────┐           │
          │            ▼     ▼     ▼           │
          │          Ports Billing Subscribers │
          └────────────────┬───────────────────┘
                           ▼
                      PostgreSQL ← NestJS APIs ← Next.js

flowchart TB
  UI[Next.js admin employee portals]
  API[NestJS TypeORM JWT]
  PG[(PostgreSQL)]
  Redis[(Redis cache)]
  CRM[CRM Sales]
  Tel[Telecom ports bills]
  Ops[Inventory Purchasing Finance]
  HR[HRMS]
  UI --> API
  API --> PG
  API --> Redis
  API --> CRM
  API --> Tel
  API --> Ops
  API --> HR

API-first ERP architecture

The ERP is an API product that happens to have screens. Warehouse, sales and finance do not share a spreadsheet.

Web · Mobile · External API · Integrations
              │
              ▼
           NestJS API
              │
     ┌────────┼────────────┐
     ▼        ▼            ▼
    CRM    Telecom        ERP
              │
              ▼
         PostgreSQL

• Frontend does not bypass APIs
• Integrations use defined contracts
• Mobile can reuse the same backend
• Workflows and business rules stay centralized

PostgreSQL vs Redis

Eight modules on one sidebar

Super Admin map: Dashboard, Workflow, Tickets, Complaints, CRM, Telecom, Sales, Inventory, Purchasing, Finance, HRMS, Settings. Module grid labels HRMS, CRM, Inventory, Sales, Purchasing and Finance as Core; Telecom as Specialized; Workflow as Process.

Analytics in this capture: API Health Healthy, Database Connected, Active Modules 8/8, Data Integrity Good. Activity names are demo rows—not a published client list.

Cross-department business workflows

The objective is not simply to place modules in one sidebar. The value comes from connecting modules into executable business workflows.

Lead → Sales → Inventory → Purchase → Finance → Customer
Telecom Billing Cycle (ports → charges → invoice → collection)

Active types on the overview: Lead → Sales Pipeline, Sales → Inventory Check, Inventory → Purchase, Purchase → Finance, Telecom Billing Cycle. This session showed seven active lead-pipeline runs (progress still early). Templates and history are in-product; a visual drag-and-drop designer is not on these screens.

CRM & sales — custom, not a plugin

CRM home: customers, active leads, opportunities, open tickets. Quick actions add a lead, customer, activity or territory. Modules include opportunities, activities, territories, customer groups, channel partners and CRM settings.

The lead form is the domain tell: Lead Type New/Existing, Customer Type Outright or Telecom, then branch, territory, telecom circle and district before name and company. Industry, source, requirement, priority, address hierarchy and products sit on the same record.

Sales quotes in this capture: one pending test quote. RMA and sales orders are in Sales; they are not empty-state screenshots.

Telecom operations workflow

Lead → Customer → Service / Product → Port / Subscriber
  → Billing Plan → Usage / Charges → Invoice → Collection → Finance

Telecom Management is ten cards: Port Management, Service Providers, Circles, Districts, Billing Cycles, Subscribers, Slabs, Charges, Earning Heads, Reports. Record counts in this session are small—proof of surface, not traffic.

Ports: SIP and FXS with slab rents in rupees, charge heads (SIP GW RENT), revenue-share flag, skip-port count, active status.

Telecom billing & revenue management

Implementation surfaces include SIP/FXS port rent, SIP gateway rent, VAS rent, R&G, fixed charges, voice plans, call charges, billing cycles, slab pricing, charge heads, revenue-share flags and bill generation with PDF.

Customer → Subscriber / Port → Billing Plan
  ├── Port Rent · Gateway Rent · VAS · Voice · Other
  → Billing Engine → Invoice / PDF

Bill modal in this capture (Kolkata circle/district, corporate branch) itemises PORT RENT, SIP GW RENT, VAS RENT, R&G, fixed, voice plan and call charges. Amounts are demo. Subscriber numbers are not repeated here.

Manufacturing & inventory workflow

Customer Demand → Sales Order → Material Requirement
  → Inventory Check → Purchase / Procurement → Warehouse
  → BOM / Assembly → Finished Product → Dispatch → Finance

Inventory is fully scaffolded (item master, stock transfer/adjustment, warehouse, BOM, assembly/disassembly, merge, reports) with zeros in this capture—honest empty, not a fake warehouse.

Purchasing: quotes, orders, receipts, vendors. The large “total purchase value” banner in this session is a display glitch (dollar prefix on a padded figure)—not a published TPV. Finance exists (bank, collections, cash flow, tax); empty rupee totals omitted so emptiness is not sold as a dashboard.

One platform for employees, customers & vendors

Telecom and manufacturing SMEs often need operational software beyond CRM and billing. The same platform can provide employee and vendor workflows without another disconnected HR product.

HRMS overview: master data, employee master, leaves, attendance, payroll, holidays, recruitment, appraisals, announcements. This capture: a handful of employees and departments; leave and payroll counters at zero.

Headline counters on recruitment are this session’s seed data—not a hiring report.

Public careers page

The same job posts surface on a public Career Opportunities page—no Super Admin chrome. Search, department, employment type and experience filters; Apply Now. Demo seed, not a live hiring campaign.

Employee portal — self-service, not the admin desk

Employees get a different product surface: welcome header, Update Profile, Mark Attendance, birthday chips, then tabs for Overview, My Tasks, Recent Activity, Holidays, Alerts, Announcements, Appraisals and Create Task. This is the employee role from the login picker—not a reskin of Super Admin.

My Profile is tabbed: Basic Info, Job Info, Education, Documents, Emergency, Job Details, Family, Resume, Exit. Exit is self-service and can sit in Pending HR review. Dummy remark text is not quoted.

Technology decisions

Scaling the ERP

Load Balancer
                         │
            ┌────────────┼────────────┐
            ▼            ▼            ▼
          API-1        API-2        API-3
            └────────────┼────────────┘
                         ▼
                    PostgreSQL · Redis · Workers

• Application — horizontal NestJS API instances
• Database — indexes, pooling, read scaling where needed
• Redis — shared cache across API instances
• Workers — reports, notifications, imports/exports, billing jobs, integrations
• Storage — object storage for documents and generated PDFs

Connects to SaaS Development for productization and multi-tenant paths.

Production considerations

• API security, RBAC, audit logs
• Database backups and migration strategy
• Redis failure handling (cache is not SoR)
• Background jobs, logging, monitoring, error tracking
• Deployment, rollback, performance monitoring, hardening
• GST-style billing lines tied to inventory and port sold — one system of record
• Integration hooks to telecom ops (numbers, trunks) without duplicate SKUs

Related: Cloud DevOps · Security & Reliability · Production Rescue.

Could this be adapted?

This architecture does not have to remain only a telecom ERP. The reusable part is API-first modules, RBAC portals and PostgreSQL as record; the domain-specific part is the data model, workflow and business rules.

• Manufacturing, distribution, logistics, field service
• Subscription / service businesses
• Equipment and channel-partner ops
• Other verticals—see Insurance ERP for a tenant + WebRTC variant

My role

• ERP architecture — bounded modules, API contracts, portal split
• Domain model — telecom ports/slabs, CRM types, inventory/BOM, HRMS
• Backend — NestJS, TypeORM, PostgreSQL, Redis caching
• Frontend — Next.js Super Admin, employee portal, public careers
• RBAC — JWT/Passport module permissions across portals

What this proves for a buyer

• Custom SaaS ERP / CRM can follow your modules instead of a generic accounting SKU
• Telecom billing (ports, slabs, GST-style heads) can share the login with CRM and HRMS
• Role portals (admin / employee / customer / vendor) are product, not a second app
• Empty warehouse and empty finance in a capture still leave the module map honest
• Same engineering bar as the PBX work: APIs first, screens second

Explore the working product — screenshots

Related work & services

• Insurance ERP + WebRTC Contact Center — CRM/ERP + calling sibling
• VoIP CRM & predictive dialer
• SMS CPaaS / SandeshX — messaging SaaS
• Custom CRM & ERP · Full-Stack · SaaS · VoIP · Asterisk · FreeSWITCH

Disclaimer: Demo seed counts, empty warehouses and bill amounts are session evidence—not published SLAs, TPV or ISP traffic. UnifiedPBX does not operate your network.