Skip to main content
Version: 2.4

Ticketing Module

The Ticketing module is the assurance and request-handling backbone in tSM. It manages incidents, requests, operational cases, and workflow-driven resolutions with SLA governance.

From architecture perspective, Ticketing is a business module built on top of the low-code platform:

  • dynamic attributes and UI are handled by the Characteristics/Form pattern,
  • workflows and task orchestration are handled by Process Engine and scripts,
  • integration is exposed via Public API and TM Forum aligned APIs (mainly TMF621 patterns).

Business Description​

Ticketing is the operational control layer for service disruptions and customer-impacting requests. In TM Forum terms, it aligns to TMF621 as the system of record for issue intake, tracking, responsibility assignment, and resolution lifecycle.

Ticketing can be utilized as a general-purpose ticketing system in the same class of usage as Jira, ServiceNow, Zendesk, Freshservice, or BMC Remedy:

  • centralized issue/request intake and tracking,
  • assignment and collaboration across teams,
  • workflow-driven lifecycle and audit trail,
  • reporting on throughput, backlog, and resolution performance.

At the same time, it is explicitly optimized for telecom and service-assurance operations:

  • service impact analysis (SIA) with impacted service/resource context,
  • root cause analysis (RCA) support through related entities and ticket relationships,
  • SLA governance with metric/goal evaluation and Advice-based pause semantics,
  • integration to network/fault monitoring systems for alarm-driven ticket creation and lifecycle updates.

Business value delivered by the module:

  • protects SLA commitments by making response and resolution timing measurable and enforceable,
  • gives one cross-domain case record shared by customer care, NOC, field operations, and service teams,
  • links customer-facing impact (RelatedParty) with technical cause context (RelatedEntity) for faster triage,
  • supports major-incident coordination through ticket relationship structures,
  • provides auditable closure evidence for compliance, partner governance, and post-incident analysis.

Typical business outcomes:

  1. lower mean time to acknowledge and resolve incidents,
  2. higher SLA compliance and fewer penalty events,
  3. faster root-cause correlation across CRM, Inventory, and WFM,
  4. better consistency of escalation and closure practices across operational teams.

Scope and Responsibility​

Ticketing is responsible for:

  • ticket lifecycle and classification (type, status, priority, severity, category, problem, resolution, channel),
  • SLA definition and evaluation (Sla, metrics, goals, and runtime linkage via sla),
  • advice-based SLA pause context (Advice, AdviceType, impactOnSla),
  • relationship and impact context (TicketRelationship, RelatedEntity, RelatedParty).

Downstream modules (CRM, Inventory, WFM, Service Orchestration, Billing) consume and enrich Ticketing context.

Detailed Subdocuments​

Configuration Model​

Ticketing follows the standard tSM Characteristics pattern:

  • dynamic business attributes on tickets are stored in chars (TsmChars),
  • processing-only context is passed in processingData (write-only, transient),
  • code tables (TicketType, TicketStatus, Priority, etc.) control lifecycle and UI behavior,
  • relationship and related-party/entity types provide controlled extensibility without schema branching,
  • SLA behavior is configured through Sla, Metric, Goal, and ConditionItem.

In practice:

  1. Configure ticket type/status/priority/severity/category/problem/resolution/channel registries.
  2. Configure related-entity/party type registries and ticket relationship types.
  3. Configure SLA definitions, metrics, goals, and condition rules.
  4. Configure advice types for SLA pause semantics.
  5. Use APIs and workflows for lifecycle, SLA, and operational handling.

TM Forum Governance​

Ticketing module is governed by TM Forum concepts:

  • TMF621 Ticket Management as the primary API/concept baseline,
  • TMF630 API guideline patterns for polymorphism/extension,
  • SID-aligned party/entity references for integration context.

tSM applies pragmatic alignment: core contracts stay close to TMF621 while additive fields support project-specific operational behavior.