Project ticketing or ITSM: the question comes up as soon as a service contract is set up, service center, application maintenance outsourcing or support. Project ticketing is a function: recording a request and following it to closure. ITSM (IT service management) is a way of organizing an IT service, its incidents, its changes and its service levels. Neither has as its main purpose the contract itself: its volume, its committees, its decisions and the projects around it. This guide says where each line falls.
Three different objects, which get confused because they often live in the same team and under the same contract.
The individual request: a ticket, its status, its priority, its owner, its history, until its resolution. It is a queue and traceability tool. Project ticketing such as Jira, Redmine or GitHub Issues tracks the requests and problems raised on a project.
The IT service end to end: incidents, service requests, problems, changes, service catalog, knowledge base, service levels, often IT assets. Incident ticketing there is one function among others, serving processes described by a framework such as ITIL.
The commitment that surrounds the service: the maintenance contract, its volume and its committee, the enhancement projects and their milestones, risks, decisions and actions, the team's workload, and what the client follows and approves. It does not track tickets.
A ticket is a record: someone asks for something, or reports that something does not work, and the request becomes traceable. Project ticketing software knows how to receive these requests, sort them, assign them, chase them and close them. Atlassian, which publishes Jira and Jira Service Management, puts it in one sentence: IT ticketing systems are only one aspect of ITSM.
ITSM, IT service management, is of another order. IBM defines it as the practice of planning, implementing, managing and optimizing the end-to-end delivery of IT services, to meet users' needs and the organization's objectives, and points out that ITIL is its most widespread reference framework. An ITSM therefore organizes processes: restoring a service after an incident, treating the cause of repeated incidents, getting a change through without breaking production, keeping a catalog and measuring service levels.
There are thus two distinct practices, serving different needs. Project ticketing tracks the requests and problems of a project or a product: a defect found in acceptance testing, a requested enhancement, a technical task. Incident ticketing, within an ITSM, serves operational upkeep, support and operations. On this site, "project ticketing" means the first, and we write "ITSM" for the second.
"Family" means the tool for which it is the center; the last column says where the scopes touch, and what depends on the vendor.
| Need | Family | pylotik | Overlap or limit |
|---|---|---|---|
| Receiving, assigning and following a request | Project ticketing, ITSM | No The request stays in its tool | Project ticketing often also carries tasks; pylotik does not track tickets |
| Incidents, problems, changes | ITSM | No | The remediation or migration projects that follow are projects, which pylotik carries |
| Service catalog, knowledge base | ITSM | No | The "catalog" of a contract in pylotik is something else: the intervention types authorized on that contract |
| Service levels, lead times, penalties | ITSM, or the contract's tool | No Neither service levels nor penalties calculated | The service level report comes from the ITSM; the committee held in pylotik records its decisions |
| Portal where the client submits requests | ITSM | No | The client follows and approves in pylotik their projects and contracts, not their tickets |
| Contract volume: consumed, committed, remaining | Depends on the ITSM or the ERP | Yes In days, deducted at each approved intervention | Units of work specific to a contract are measured in the tool that counts them |
| Contract committee, minutes approved by the client | Rarely the center of an ITSM | Yes Indicators frozen at each session, minutes approved or refused | Some ITSM offer service reports; approval of the minutes by the client is to be checked |
| Enhancements delivered with milestones and acceptance | Project management, project ticketing | Yes A project, its milestones, its risks, its contract | The technical detail of acceptance defects can stay in project ticketing |
| Workload of a team shared between support and projects | PSA; the ITSM sees the queue, not the rest | Yes Workload plan, weekly time, overload alerts | The ITSM sees the time spent on tickets; pylotik sees the team's workload on projects and interventions |
| Contract margin | PSA, ERP | Yes Fixed price or time and materials, ordered, invoiced, paid | The invoice is still issued by the ERP |
An integrator maintains a client's business application: a volume of days per year, user support, enhancements delivered in releases, a monthly committee with the client.
Users' incidents, qualified and prioritized; service requests; response and resolution times measured against service levels; changes to deploy. This is the right place for all of it, and nothing justifies moving it.
The contract volume already consumed, and what remains for the quarter. Three enhancements requested at committee that await arbitration. A release that is late because the client's acceptance test data has not been delivered. A key consultant, split between this contract and a fixed-price project, who will not be able to hold both.
On the side of the families, scopes vary a great deal from one vendor to another. Depending on the product and its modules, an ITSM also covers project management, a full client portal, service level reports or contracts; project ticketing can carry boards, timesheets or approvals. This guide describes families, not products: each function is to be checked in the documentation of the tool considered. For Jira in particular, see the pylotik vs Jira comparison, and for the contract itself, maintenance contract management.
The ticket is the record of a request. Project ticketing is the tool, or the function, that receives tickets and follows them to closure. ITSM is the discipline that organizes an IT service end to end, incidents, problems, changes, catalog and service levels, and that relies on incident ticketing among other functions.
Jira is a ticket tracking and agile project management tool, centered on the work of software and technical teams. Atlassian's ITSM offer is a separate product, Jira Service Management, with its client portal and service levels.
No. It calculates neither service levels nor penalties. It holds the maintenance contract, its volume, its catalog and its committee, where the service level report produced by the ITSM is discussed and where decisions are recorded.
No data exchange is in place by default. The pylotik connectors are optional and built to clients' needs, from the Business tier: an exchange with an ITSM is therefore defined for a specific use case, based on the useful data and the available interfaces.
Yes, it is one of the modes where it is most useful: dates that fall due, committees, enhancements to deliver, a shared team. The ticket queue and the measurement of service levels stay in the ITSM; pylotik carries the contract, the committee, the decisions, the projects and the team's workload.
Their tickets, no: they stay in the portal of the ITSM or project ticketing tool. In pylotik, with free access, they follow their projects and contracts, read the indicators frozen at the last committee, and approve or refuse the minutes, interventions and amendments.
Page updated on . Sources consulted on that date; what pylotik does is described from the product in service on the same date.
A demonstration on a data set that is already filled in: a maintenance contract, its committee and approved minutes, an enhancement project, and the workload of a shared team.