Skip to main content

tSM Ticket Management

The tSM Ticket Management module (also sometimes referred to as “Trouble Ticket Management”) is a core component of the tSM ecosystem, facilitating the creation, tracking, and resolution of incidents, requests, or general problems reported by customers and other systems. While it is widely used in telecommunications (telco) and IT environments, tSM’s flexible architecture means it can also function as a general-purpose ticketing system, much like Atlassian Jira or other workflow-driven platforms.

In addition, tSM supports low-code capabilities. This means any business process can be modeled in tSM by defining the appropriate workflow logic and associating it with a ticket-like entity. Although “tickets” are often associated with troubleshooting, you can leverage this same framework for internal approvals, project tasks, or any other use case that requires a structured lifecycle.

ticket.png

1. Module Overview​

  1. Purpose and Scope

    • Captures and organizes all incidents and requests within an organization or service provider environment.
    • Accommodates a broad range of use cases: customer issues, network/system alarms, internal IT requests, project tasks, and more.
    • Specialized submodules—such as Preventive Maintenance, Change Management, Network Construction—extend this ticket foundation for domain-specific needs.

  2. Key Features

    • Ticket Lifecycle: Configurable statuses (e.g., “Open,” “In Progress,” “Resolved,” “Closed”) with robust SLA monitoring.
    • Automated Workflows: Control assignment, prioritization, escalation, and notifications.
    • Integration:
      • CRM: Associate a ticket with a particular customer or account.
      • Workforce Management: Dispatch technicians or internal teams for on-site or remote tasks.
      • Inventory: Pinpoint the affected product, service, or network resource (e.g., a broadband line or a core router).
    • Foundation for Other Modules: Serves as the central “ticket-based backbone,” onto which other processes—whether purely operational or business-oriented—can be attached.

2. Core Functionalities​

2.1 Ticket Creation and Management​

  • Create New Tickets
    A ticket is opened to capture an incident or request. Basic inputs commonly include:

    • Name (e.g., “Core Router Memory Warning”)
    • Type (e.g., “Technical,” “Customer Complaint,” or any custom domain-specific type)
    • Severity (e.g., “Critical,” “Low”)
    • Priority (e.g., “Highest,” “Medium”)
    • Channel (e.g., “Automatic Alarm,” “Email”)
    • Category (e.g., “IP Network,” “Billing Issue”)
    • External ID (optional reference to another system)
    • Description (high-level synopsis of the reported problem or request)

    All these attributes (and more) are drawn from dedicated “registers” or enumerations that keep data consistent and facilitate automation.

  • Lifecycle Status
    Tickets move through workflow-driven states. For example: Open → Assigned → Resolved → Closed. SLAs and tasks are triggered automatically at each stage, helping ensure timely follow-up.

2.2 Ticket Lifecycle Management​

  • Configurable Statuses
    Administrators define the valid lifecycle states per ticket type or domain. This flexibility supports simple or complex processes, from a basic “New → Resolved → Closed” flow to multi-step operational workflows.
  • SLA Tracking
    The system calculates “time to respond” or “time to resolve” based on severity, priority, or contract rules. If a threshold is close to being missed, automatic escalations or notifications can occur.
  • Escalations and Notifications
    Configure event-driven rules (e.g., “If no update for 24 hours, escalate to manager”) to ensure service commitments are consistently met.

2.3 Process-Oriented Resolution​

  • Workflow Engine
    Each ticket is backed by a process definition that can include tasks (e.g., “Investigate alarm,” “Contact customer,” “Dispatch field agent”).
  • “People” Section
    A specialized interface section displaying which tasks are assigned to which users or teams. This is where tasks are claimed, transferred, or completed.
  • Process Diagram
    A graphical representation of the workflow, showing tasks, transitions, user assignments, and the ticket’s current position in that process.

2.4 SLA Configuration​

  • Definition of SLA Targets
    For example: “Respond to critical tickets within 2 hours, resolve within 8 hours.”
  • Penalty or Escalation Rules
    If SLAs are missed or in danger of being missed, the system can auto-assign a higher priority or notify management.
  • Timer Pausing (Advice)
    If the ticket is waiting on an external factor (hardware shipment, third-party feedback, or customer response), the SLA timer can be paused to ensure fair measurement of resolution time.
  • Ticket Linking
    Tickets can reference each other (e.g., a parent “Major Outage” ticket with multiple child “Affected Site” tickets). This helps manage large incidents or problems with multiple root causes.
  • Impacted Services / Root Cause Analysis (RCA)
    For network or service outages, tSM can perform (or integrate with external systems to perform) Root Cause Analysis and Service Impact Analysis (SIA).
    • Root Cause: The underlying network event or infrastructure fault that triggered the incident.
    • Impacted Services: All customer or internal services impacted by that fault.
    • Once the root cause is identified and resolved, child tickets automatically update or close, reflecting the resolution. Similarly, if a new ticket arrives that matches a known root cause, the system links them so everything is tracked in one place.

2.6 Comments and Attachments​

  • Comments
    Users can add free-text updates (including rich text, images, or code snippets), capturing the conversation or troubleshooting notes in one location.
  • Attachments
    Supporting documents (network logs, screenshots) can be uploaded, ensuring all relevant data is stored with the ticket.

2.7 Additional Sections and Tabs​

Tickets can display customizable sections or tabs (beyond the defaults) depending on Type or business needs. Examples:

  • Dates: Tracks key timestamps (creation, resolution, closure).
  • Resolution: Summarizes how the ticket was ultimately fixed.
  • Advice: Indicates an external dependency or pause in SLA timing.
  • Reference Entities: Lists the affected network elements or business objects stored in the Inventory module (e.g., subscriber lines, router devices).

3. Key Entities: Ticket, RelatedEntity, and RelatedParty​

3.1 Ticket​

A Ticket is the central record for an incident, request, or process. It includes:

  • Key (unique identifier for display)
  • Lifecycle Status
  • Severity, Priority, Type, Category
  • Attachments, Comments, Links

These fields are selected or constrained by the relevant “registers” (enumerations), keeping data standardized.

3.2 RelatedEntity​

RelatedEntity entries capture external or internal objects that the ticket is associated with. This can be:

  • A network resource (e.g., “Router #R12 in Data Center 3”)
  • A service (e.g., “Fiber 500Mbps plan for Customer X”)
  • A hardware device (e.g., “Set-Top Box #ABC123”)
  • Another master system object (e.g., “CRM Opportunity #OPP-789”)

In telco contexts, RelatedEntity is crucial for:

  • RCA (Root Cause Analysis): Identifying a specific failing resource or site that triggered the incident.
  • SIA (Service Impact Analysis): Listing all impacted services in the ticket automatically, so stakeholders see the broader effects.

If a new customer ticket arrives for the same root cause, the system automatically links that new ticket to the ongoing incident and updates relevant statuses. Once the root cause is fixed, the system can close or resolve all dependent tickets.

3.3 RelatedParty​

RelatedParty captures persons, groups, or organizations connected to the ticket. Examples:

  • A customer who reported the issue or is impacted.
  • An operator or vendor providing a sub-service or technology.
  • A third-party partner (e.g., an upstream carrier in a telco scenario).

These references allow the system to track roles (like “requester,” “resolver,” “affected user”), maintain contact details, and enable direct communication channels or escalations.

4. Integration with Other Modules​

  1. CRM
    Pull or push customer data (e.g., subscription details, contact info).
  2. Inventory
    Reference specific products, services, or resources from the Inventory module to unify ticket context with real-time asset/service data.
  3. Workforce Management
    Dispatch tasks to field technicians if an on-site repair is needed, track job completion.
  4. Change Management
    If resolving the ticket requires changes to production environments, automatically create or link a change request, ensuring governance and audits are maintained.

tSM’s open APIs and low-code extensibility allow the Ticketing Module to interact seamlessly with diverse third-party or custom systems.

5. Examples of Ticket Usage​

A. Core Network Node Failure​

  1. An internal monitoring system detects a memory overload on a core switch.
  2. A Ticket is automatically created, Type = “Technical,” Severity = “Critical.”
  3. Root Cause Analysis from the network system identifies the failing switch. The ticket’s RelatedEntity is set to “Switch #SWCH-101.”
  4. Service Impact Analysis finds 200 enterprise circuits impacted, each listed in RelatedEntity references.
  5. Once the switch is replaced, the main ticket is resolved. All child/linked tickets automatically move to a resolved state.

B. Customer Support Request (Non-Telco)​

  1. A customer logs into a self-service portal to request a new software license (no hardware involvement).
  2. The system creates a “Request” Ticket, Priority = “Low.”
  3. The user’s record is captured as a RelatedParty.
  4. An SLA sets a resolution target of 3 business days. The assigned group “IT Licensing” receives the ticket.
  5. Once the license is provisioned, the ticket is set to “Resolved,” and automatically transitions to “Closed” after final validation.

C. Internal Low-Code Workflow​

  1. The marketing team wants an approval workflow for a new campaign. They create a custom Ticket Type = “Marketing Approval.”
  2. Each campaign becomes a “ticket” with tasks for design review, budget sign-off, final scheduling.
  3. The system auto-routes tasks among multiple departments. Communication is tracked in the ticket’s comments.
  4. Because tSM is low-code, administrators quickly adapt the workflow without heavy development.

6. Best Practices​

  1. Standardize Registers
    Keep severities, priorities, types, and categories well-defined. This consistency enhances reporting, filtering, and automation rules.
  2. Leverage SLA
    Use realistic SLA timers and escalation policies to ensure timely handling of urgent matters.
  3. Automate
    Let the system auto-assign tickets based on type or severity. Use triggers for escalations or notifications.
  4. Utilize Relationships
    Link related tickets (e.g., parent–child) for big incidents. Leverage RelatedEntity for real-time network or service references.
  5. Adopt a Low-Code Mindset
    Implement custom workflows or forms for broader business processes (e.g., approvals, HR requests, or project tasks).
  6. Monitor KPIs
    Track resolution times, SLA compliance, backlog age, or user productivity. Use analytics to improve processes continuously.

7. Summary​

The tSM Ticketing Module provides a versatile, workflow-driven approach to managing incidents and requests—whether these are technical outages, customer inquiries, or entirely different business processes. It supports:

  • Configurable Ticket Lifecycles: From simple to complex, with SLA monitoring and escalation.
  • Deep Integration: CRM, Inventory, workforce tools, and other systems—ensuring end-to-end visibility for both technical and non-technical stakeholders.
  • Root Cause & Impact Analysis: Leverage RelatedEntity references to connect issues to network elements or services, and automatically reflect these in child or impacted tickets.
  • Flexible Low-Code Development: Tailor the module to unique organizational processes, beyond classic “trouble tickets.”

By harnessing tSM Ticketing, companies can centralize problem-solving, unify cross-department workflows, and gain real-time transparency across the entire service lifecycle.