IT service management software built on a real asset register

MeltX ITSM is the IT service management module built by MeltX Software Solutions in Pune, India.

  • Incident, problem and change management in one practitioner console
  • Configurable SLAs with escalation paths and breach alerts
app.meltxsoftware.com/itsm/queue

Service desk

SLA 96%
Open
38
Within SLA
96%
At risk
3
  • INC-4471Rack B switch unreachable00:42 to breachP2
  • INC-4468Licence renewal, 42 seats6h 10mP3
  • CHG-0912Firmware rollout, plant 2ScheduledP3
  • INC-4465Laptop will not charge2d 4hP4
  • Every record linked to its asset and configuration item
  • Dashboards and trend analytics for the people accountable for service

THE PROBLEM

A service desk without asset context is just a mailbox with tickets

Requests arrive by email, phone and corridor conversation. Priority is decided by who asked loudest. Nobody can say whether the same laptop has failed four times this year, or which services will stop if a particular host is taken down for maintenance. Reporting becomes an exercise in reconstruction.

  • SLAs that exist only in the contract

    Response and resolution commitments are written into an agreement but never measured, so breaches are discovered in a review meeting.

  • Repeat failures nobody notices

    The same device or service fails repeatedly under different ticket numbers, and no one connects them because tickets are not tied to assets.

  • Changes made without impact analysis

    A host is patched or moved without knowing which business services depend on it, so a routine change becomes an outage.

  • Reporting assembled by hand

    Monthly service reports are built from exports and memory, which makes them slow to produce and easy to dispute.

THE THREE PRACTICES

Different work, different records, one console

Incidents, problems and changes answer different questions. Running them as one undifferentiated ticket queue is why most service desks record work without ever reducing it.

  1. 01

    Incident

    Restore service

    An interruption to a service, worked against a running clock. The record carries the affected asset, its warranty position and its failure history, so triage starts with context rather than with questions.

    • Logged from portal, email, service desk or an automated alert
    • Priority, category and affected asset set the routing and the SLA
    • Escalation fires before the target is missed, not after
  2. 02

    Problem

    Remove the cause

    The underlying cause behind one or more incidents. Related incidents are grouped, a root cause is established, and a workaround is published as a known error while the permanent fix is tracked.

    • Incidents with the same signature grouped into one investigation
    • Workaround published so the next matching incident closes in minutes
    • Repair history and cost pulled from the asset record to justify replacement
  3. 03

    Change

    Move deliberately

    A controlled modification to the estate. Standard changes run on a pre approved model, normal and emergency changes collect approvals in sequence, and impact is assessed against the configuration database before anything is scheduled.

    • Standard, normal and emergency types with their own approval paths
    • Impact analysis against the CMDB, so dependent services are known in advance
    • Implementation scheduled inside a maintenance window, with rollback recorded

The three are linked. An incident can raise a problem, a problem can raise a change, and when the change lands it closes both. That chain is what turns a service desk from a record of work into a way of reducing it.

CAPABILITIES

What IT Service Management actually does

Four capability pillars, each grounded in the mechanism behind it rather than in adjectives.

01

Incident, problem and change management

Three practices in one console, each with the fields a practitioner actually works from.

  • Incidents restore service: logged from portal, email, service desk or an automated alert, routed by category, location or asset, and worked against a running clock.
  • Problems remove the cause: related incidents are grouped, a root cause is established, a workaround is published as a known error, and the permanent fix is tracked to closure.
  • Changes move deliberately: standard, normal and emergency types, impact assessed against the configuration database, approvals recorded and implementation scheduled inside a maintenance window.
  • The three are linked, so an incident can raise a problem, a problem can raise a change, and the change closes both when it lands.
INC-447100:42 to breachINC-44686h 10mCHG-0912ScheduledINC-44652d 4h
02

SLA and escalation control

Configurable response and resolution targets, with escalation that happens before the breach rather than after it.

  • Define response and resolution targets by priority, category, customer or location, including business hours and holiday calendars.
  • Escalate automatically at defined thresholds, so a supervisor is engaged while the ticket can still be saved.
  • Alert on tickets approaching breach, and report on breaches with the reason attached rather than as a bare count.
  • Hold vendors and internal groups to the same measured commitments as the service desk itself.
03

Asset linked service operations

Every ticket points at a real asset or configuration item, which makes impact and root cause analysis possible.

  • Attach tickets to the asset and configuration item they concern, drawn from the same records MeltX ITAM maintains.
  • See the full failure history of a device before deciding whether to repair it again or replace it.
  • Run impact analysis before a change using the dependency map, so downstream services are informed in advance.
  • Trace an incident back through recent changes on the affected configuration item during root cause analysis.
Agent0hTeam lead+4hService owner+8h
04

Operational visibility and optimisation

Dashboards and trend analysis that show where service is failing and why, not just how many tickets closed.

  • Track volume, ageing, first response time, resolution time and reopen rate by team, category and location.
  • Surface recurring categories and problem assets so effort moves from firefighting to elimination.
  • Report service performance to business owners on a schedule, with the same numbers the service desk sees.
  • Use workload and backlog trends to plan staffing rather than react to it.
Plant 1Plant 2Acknowledged

IN DETAIL

The parts that decide whether it works in practice

Enterprise software succeeds or fails on the details nobody demonstrates. These are the ones that matter after go live.

The record knows the asset

Because ITSM and ITAM share records, an incident carries the device, its warranty status, its custodian and its failure history. A problem inherits the repair history. A change knows what depends on the host before anyone approves it. Triage starts with context rather than questions.

Business hours and holiday calendars

SLA clocks respect working hours, weekly offs and public holidays, including location specific calendars.

Change approval and CAB

Standard changes run on a pre approved model. Normal and emergency changes collect their approvals in sequence, with each one dated and attributable.

Known errors and workarounds

A problem publishes its workaround as a knowledge article, so the next matching incident is resolved in minutes rather than reinvestigated.

Multi location service desks

Run distinct queues, calendars and escalation paths for each site under one platform and one report.

Role based visibility

Requesters, agents, supervisors and business owners each see the view their role needs.

Audit trail on every record

Status changes, reassignments, approvals and SLA events are recorded and cannot be edited away.

Scheduled service reports

Monthly and weekly packs generated from live data and delivered without anyone assembling them.

SLA governance you can evidence

For managed service contracts, government engagements and internal service charters alike, the question is the same: can you prove the commitment was met. MeltX ITSM answers it from recorded data.

Security and compliance position
  • Measured commitments

    Response and resolution targets are configured per contract or charter, and measured against business hours rather than wall clock time.

  • Immutable ticket history

    Status changes, reassignments, escalations and SLA events are recorded permanently, so performance reporting is not a matter of opinion.

  • Change control evidence

    Approvals, impact assessments and implementation records are retained against the change and the configuration item it touched.

  • Vendor accountability

    Third party groups work inside the same SLA framework, so contractual performance is visible rather than asserted.

LIFECYCLE

One record, six stages, no re-keying

Each stage writes to the same record. Nothing is retyped into a second system, which is where most asset data goes wrong.

  1. 1

    Log

    The incident arrives from portal, email, service desk or an automated alert.

  2. 2

    Classify

    Priority, affected asset and service are recorded, and the SLA clock starts.

  3. 3

    Resolve

    The group that can fix it works the ticket, with escalation before the target is missed.

  4. 4

    Group

    Repeating incidents are pulled into a problem, and a workaround is published.

  5. 5

    Change

    The permanent fix goes through impact analysis, approval and a maintenance window.

  6. 6

    Close

    The change closes the problem and its incidents, and the asset history records all of it.

Built for the people who answer for the numbers

One register, read four different ways. Each of these roles asks it a different question, and gets the answer without asking anyone for an extract.

  1. IT service desk managers

    A queue with real priorities, measured SLAs and reporting that does not need to be assembled by hand.

  2. CIOs and IT heads

    Service performance and problem concentration visible in one place, with the asset data to act on it.

  3. Managed service providers

    Contractual SLA evidence per client, per site, with escalation configured to the agreement.

  4. Government IT departments

    Citizen facing and internal services supported under measured commitments with a permanent audit trail.

WHERE IT'S DEPLOYED

Runs alongside the estate it supports

MeltX ITSM is deployed with MeltX ITAM in environments where service commitments are contractual, including managed service and public sector engagements across the MeltX and partner clientele.

  • Borivali Education Society

    Education

    MeltX FAM and ITAM were configured to the institution department structure, with tagging across laboratories, classrooms and administrative offices, and custody recorded against named department heads.

    Custody
    Department wise
    Grant traceability
    Retained per asset
    How the deployment ran

SECTORS

Where ITSM is running

The sectors whose deployments include IT Service Management. Each page sets out what the register has to answer for in that sector.

What buyers ask about ITSM

The questions buyers actually ask during evaluation, answered without marketing language.

What is ITSM software?

IT service management software runs the processes an IT function uses to deliver and support services. It handles incidents, service requests and changes through structured workflows, measures performance against service level agreements, and records the history needed to improve service rather than simply record it.

What is the difference between an incident, a problem and a change?

An incident is an interruption to a service, and the goal is to restore it quickly. A problem is the underlying cause behind one or more incidents, and the goal is to remove it. A change is a controlled modification to the estate, and the goal is to make it without causing new incidents.

How does MeltX ITSM enforce service level agreements?

Targets are configured by priority, category, location or contract, and measured against business hours and holiday calendars. Tickets approaching their target raise alerts, escalation engages a supervisor automatically, and every SLA event is recorded so performance reporting is evidence rather than assertion.

Why link tickets to assets?

Because it changes what the data can tell you. Linked tickets reveal which device fails repeatedly, what a specific asset has cost to support, and which services depend on a host before you take it down. Without that link, a service desk records work but cannot reduce it.

Can MeltX ITSM support multiple locations and service desks?

Yes. Each site or business unit can run its own queues, calendars, priorities and escalation paths while reporting rolls up centrally. This matters for organisations with plants, branches or district offices operating on different working calendars.

See it against your own register

Configured around your asset classes before the call. Thirty minutes.

  • No obligation
  • Run on your register
  • Answered within a business day