Zendesk vs Jira Service Management vs Freshservice: CMDB, IT Asset Management, and AIOps (Part 3 of 5)

This is the third post in the series where I compare Zendesk, Jira Service Management (JSM), and Freshservice based on real implementations. Part 1 covered cost and licensing, Part 2 covered core service management. This time I'm moving into an area where it's easy to confuse a marketing claim with operational reality: CMDB, IT asset management, and AIOps.

The full series: Zendesk, Jira Service Management, and Freshservice - a field comparison guide

1. Cost, Licensing, and Vendor Lock-In
2. IT Service Management: Incident, Problem, Change, and CAB
3. CMDB, IT Asset Management, and AIOps (this part)
4. Automation, Integrations, and AI Agents
5. Platform Foundations: Reporting, Security, Implementation, and UX

One thing I've learned over the years is that CMDB, IT asset management, and AIOps are three different disciplines, even though vendors tend to blur them together in sales decks. A list of computers with a serial number and a username still isn't a CMDB, and automatically opening a ticket off an alert isn't necessarily AIOps.

IT asset management is about the lifecycle of hardware and software: what we bought, who it was assigned to, what condition it's in, when the warranty ends, and when it's time to replace it. A CMDB is supposed to add operational context: which servers, systems, business services, and infrastructure components depend on each other, and what the impact of an outage or a change would be. AIOps adds another layer on top: ingesting alerts, cutting noise, spotting relationships, and speeding up incident handling.

In practice, a lot of organizations ask for a CMDB when what they actually need is a reliable inventory of computers and servers. Others buy an advanced CMDB solution but never define data ownership, update rules, or a process for handling bad data. In those cases, the system quickly turns into a graveyard of Configuration Items nobody trusts anymore.

Jira Service Management and Assets - highly flexible, not simple to implement

Worth clarifying up front: Insight was originally a product by Mindville, which Atlassian acquired and turned into Assets inside Jira Service Management. So when people talk about Insight and Atlassian's CMDB today, it's not two competing solutions - it's the evolution of the same product.

Assets is a very flexible solution. You can manage computers, servers, networking equipment, software, users, contracts, sites, business services, and almost any other entity the organization wants to bring into the model. You can define object types, attributes, and relationships, and embed them directly inside an Incident, Service Request, Problem, or Change.

When the system is built correctly, a support agent can look at a ticket and see which computer belongs to the user, what's installed on it, which past tickets were opened for it, and which systems or services it's connected to. During an infrastructure change, you can use those same relationships to understand which services might be affected. That's exactly the point where a CMDB adds value beyond a plain equipment list.

The problem is that getting there isn't simple. Many customers expect that you turn on Assets, click a scan button, and quickly get a full, up-to-date CMDB. In practice, you need to download and run Assets Discovery inside the corporate environment, define scan ranges, credentials, permissions, patterns, and network settings. After that, you need to bring the scan results into Assets, build the import structure, and map the data to the right object types and attributes.

The process is more tedious than a demo makes it look. The scan doesn't always find every component, especially in environments with firewalls, network segmentation, different operating systems, endpoints that aren't reliably connected, or permission restrictions. Sometimes you get partial data, and sometimes you get a huge volume of technical data that isn't actually useful to the service team.

In my view, Discovery is a tool for collecting information, not a magic mechanism that builds a CMDB on its own. It can find a host, operating system, hardware components, software, services, and network components, but it doesn't know on its own which information matters to the organization, which business service is supported by which server, or who owns a given system.

I've more than once seen a project where Discovery was installed, wide network ranges were set, and almost everything the tool found got imported. At first the result looked impressive, because the system filled up with tens of thousands of objects. A few months later it turned out there were duplicates, components that were no longer active, many software versions, and relationships that didn't help answer the important question: what breaks if this component goes down?

The mistake was starting the scan before planning the model. Before I install a Discovery tool, I want to understand what questions the CMDB needs to answer, which asset types actually matter, what the unique identifier for each asset is, who owns the data, and which source is treated as authoritative in case of conflict. Only after that is it right to decide what to scan and what to import.

Licensing is another aspect. In Assets, every record counts as an Object, and the count spans all objects across your schemas. Not every piece of installed software on every computer has to become a separate object - that depends on the model and mapping you choose. But if you import computers, servers, operating systems, hardware components, software, versions, users, and relationships without discrimination, the number can quickly climb into the tens or even hundreds of thousands of Objects.

So schema design isn't just a technical decision. It also affects license cost. The Standard tier currently includes significantly less capacity than Premium, and you can buy extra capacity for a fee. An organization that starts scanning before estimating the number of objects can discover that the CMDB it planned doesn't fit the tier it purchased.

On projects where the organization already had Microsoft Intune, Jamf, SCCM, Lansweeper, or a dedicated software license management system, I didn't always try to replace them. I generally got a better outcome when the external system stayed the source of discovery and technical data, while Assets received only the information needed for service processes.

That's also a case where the built-in CMDB didn't always meet expectations. In one recurring scenario, Assets was asked to be a discovery tool, an inventory system, a CMDB, and a software license management system all at once. After a few months there were duplicates, unnormalized software names, and data that wasn't accurate enough for financial decisions. The fix wasn't to throw out Assets - it was to redefine its role: an external tool stayed responsible for discovery and normalization, and Assets became the context layer connecting assets to incidents, problems, and changes in JSM.

Bottom line on the practical side: Assets can be a very strong CMDB solution, but it demands experience, planning, and governance. If you start scanning and importing before defining the goal and the data model, failure is almost guaranteed.

Freshservice - easier to get started, still an infrastructure project

Freshservice offers a more structured approach to asset management and CMDB. In most organizations it's easier to reach an initial result: bring in computers and servers, link them to users, and embed them in Incident, Problem, and Change. The system speaks a language IT teams are familiar with and doesn't require pre-planning a flexible object model the way Atlassian's does.

Freshservice offers a few discovery methods. The first is Discovery Probe, an application installed on a Windows machine inside the network. You configure IP or domain ranges and provide the right permissions. The Probe uses WMI to scan Windows, SSH for Linux and macOS, and SNMP for printers, switches, routers, and other network components. You can also import users from Active Directory, connect to SCCM, and schedule periodic scans.

The second method is Discovery Agent, installed on Windows, macOS, or Linux endpoints. The Agent collects hardware and installed-software information and updates Freshservice whenever it detects a change, as well as on a regular cycle. For laptops and remote employees, this is generally the more effective option, since the endpoint doesn't need to be reachable for a scan from inside the corporate network.

On new accounts opened after the ITAM model change in March 2026, there's also a more advanced Discovery environment. It uses Remote Collectors and separate scan jobs for network, Windows, Linux, virtualization, cloud, storage, and other components. The options are broader, but here too you need service accounts, open ports, defined subnets, Discovery Jobs, and result verification.

Freshservice provides views that help you understand which scans succeeded and which assets weren't confidently matched to an existing record. That's a meaningful improvement, but it doesn't eliminate the work. Records the system can't identify need review, merging, or deletion. Freshservice also can't automatically know whether two records with a different hostname and the same serial number are the same asset, or whether a record that hasn't appeared in a month represents a decommissioned computer or just an employee on vacation.

In my experience, getting Freshservice set up is generally smoother and more guided than Assets Discovery. It's easier to get to a first scan, see assets in the system, and link them to users. On a project where the goal was to get control over endpoint equipment, we managed relatively quickly to see who was holding each computer, what condition it was in, when it was last scanned, and which tickets had been opened for it.

But even here, you can't confuse success at scanning computers with actually building a CMDB. Once you move to mapping servers, virtual machines, cloud, and business services, the rollout becomes a genuine infrastructure project. You need to plan the order of scans, open up network access, decide which data source wins in a conflict, and handle records that didn't get matched.

Freshservice also changed its ITAM licensing model. On new accounts, consumption is measured in Asset Units, where different asset types consume different amounts. An endpoint, a server, a virtual machine, networking equipment, and a SaaS user aren't necessarily counted the same way. So here too you can't estimate cost by computer count alone - you need to map the real environment and check which ITAM tier includes the discovery, software, and service-mapping capabilities the organization needs.

In my view, Freshservice's advantage is that the path from a scanned asset to an asset showing up inside a service ticket is generally shorter and clearer. The downside is that it's easy to get a false sense of confidence early on. The system looks organized quickly, but if there's no process for handling duplicates, stale assets, and conflicting data sources, data quality will degrade exactly the way it does in any other CMDB.

Zendesk - asset management without its own discovery engine

Zendesk approaches this from a different angle. It added IT asset management capabilities as part of the Employee Service environment: you can define asset types, fields, statuses, and locations, associate an asset with a user, and display it inside a ticket. For an agent who wants to know which computer or phone an employee has, that's a genuinely useful capability.

That said, as of now Zendesk doesn't include an independent network-scanning tool equivalent to Assets Discovery or the Freshservice Probe. It doesn't install a scanner inside the network and discover computers, servers, and switches on its own. The data generally comes from a CSV import, an API, or a sync with an external system.

Zendesk currently offers relatively built-in sync processes for Microsoft Intune and Jamf Pro. Using scheduled Action Flows, you can pull device and user data, map it to Zendesk's asset types, and create or update records. Zendesk also supports CSV import and scheduled sync from Intune and Jamf.

If the organization already manages its endpoints in an organized way via Intune or Jamf, the rollout can be relatively simple. You connect a service account, check permissions, adjust the field mapping, and turn on a daily sync. Zendesk can then show the asset inside the ticket, associate it with the employee, and, through the integration, even trigger actions like locking, restarting, or wiping a device.

I actually like this approach when the goal is to give the service agent better context. If Intune already knows which computer the employee has, there's not much value in having the service system try to scan that same computer again. In that case, Zendesk isn't trying to become the discovery system - it's using a source of data that already exists.

On the other hand, if the organization doesn't have an endpoint management system or an organized source of assets, Zendesk won't solve that problem on its own. You can load CSV files or build an integration, but responsibility for asset discovery, data cleanup, and syncing stays outside the product. A one-time spreadsheet import looks simple on launch day, but within a few months it turns into a repository that no longer reflects reality.

In terms of depth too, I wouldn't rate Zendesk today as equivalent to Atlassian's Assets or to Freshservice's more advanced CMDB capabilities. It's better suited to managing an asset's lifecycle and linking it to users and tickets. When you need a complex Configuration model, infrastructure mapping, Service Mapping, or deep analysis of dependencies between services, you need to look at an external solution.

So Zendesk is the simplest product to implement only when an external source of truth already exists. Without Intune, Jamf, or something similar, it isn't simpler - it just solves a smaller slice of the problem.

When does a built-in CMDB fall short of expectations?

Yes, I've run into cases where a built-in CMDB fell short compared to an external solution. Usually the problem wasn't a shortage of fields or screens - it was the gap between a system that holds records and a system that actually knows how to discover, normalize, and maintain technical reality.

In one common scenario, the organization imported data from an endpoint management system, a security system, and a file from procurement. The same computer showed up three times: once by hostname, once by serial number, and once by an internal ID. From the CMDB's point of view, those were three different assets. From the organization's point of view, it was one computer - but nobody had defined which data source was authoritative.

In a situation like that, another field or another workflow doesn't fix the problem. You need to define a unique identifier, ownership for each data source, matching rules, and priority between sources. You also need to decide what happens with an asset that hasn't shown up in a scan for 30, 60, or 90 days.

In some cases the external tool was significantly better at discovering endpoints, identifying software, or normalizing names and versions. Instead of fighting that, we kept it as the source of truth and passed only the information needed for ticket handling, impact analysis, and change management into the ITSM system.

My own test for a CMDB isn't how many records it holds - it's whether I can trust it during an outage or before a change. If, before shutting down a server, the change manager still has to call three people to understand what's running on it, having a CMDB in the organization doesn't really help.

AIOps - between real operations and a marketing label

AIOps is an area where I'm especially wary of marketing claims. A system doesn't become AIOps just because it uses AI to summarize a ticket or draft a reply. In the operational world, I'm looking for the ability to ingest alerts from monitoring systems, normalize them, group related events, cut noise, link an alert to an asset or a service, open an Incident, and page the on-call team.

Jira Service Management has AIOps capabilities that include alert management, smart grouping of related alerts, noise reduction, and connecting information from observability systems, events, and assets. Atlassian integrates Rovo into the process to help with event analysis, surfacing context, and producing a post-incident review. Some of the more advanced capabilities may depend on your license tier or be rolling out gradually, so I always check what's actually active rather than settling for the sales page.

JSM's strength is the ability to connect Alert, Incident, Change, and the information in Assets. Its weakness is that the outcome depends heavily on the quality of the integrations and the data model. If services and relationships aren't defined correctly, even an advanced AI mechanism won't be able to show the real impact of the outage.

Freshservice offers a cohesive IT Operations layer that includes Alert Management, ingesting alerts from monitoring tools, normalization, grouping and noise reduction, opening Incidents, on-call management, handling major incidents, and tracking service health. Freddy AI can group alerts and associate them with existing incidents based on learned context and patterns.

In my experience, Freshservice generally gives an organization a shorter, clearer path to connecting a monitoring tool to the service system and setting up an organized operational process. JSM can be very flexible and deliver a strong result in an environment that's willing to invest in integrations and planning, but Freshservice is generally more built-in from the start.

Zendesk is strong mainly in AI that helps the service agent's own work: summarizing tickets, suggesting replies, routing, and automation. Those are valuable capabilities, but they aren't infrastructure-grade AIOps. Compared to JSM and Freshservice, Zendesk isn't the natural choice when the core requirement is event management, alert grouping, on-call management, service health, and impact analysis of infrastructure components. You can open tickets through integrations, but another system will generally keep doing the actual monitoring and event-correlation work.

Bottom line

If the organization is looking for a highly flexible CMDB that lets you build a custom model of assets, services, and relationships, Jira Service Management Assets is the strongest tool of the three. It's also the product where the risk of a complex, unsuccessful rollout is highest. Discovery requires installation, permissions, schema planning, data mapping, and ongoing maintenance. Without experience and up-front planning, it's very easy to end up with a large, expensive, unreliable repository.

Freshservice provides the best balance between discovery capabilities, ITAM, CMDB, and relative ease of implementation. You can use the Agent, the Probe, or the more advanced Discovery capabilities, and the connection to service processes is clear. It's easier to start with than JSM, but in a complex environment it also demands a properly run infrastructure project. You also need to check the ITAM tier and Asset Unit consumption carefully.

Zendesk fits an organization that needs to show, inside the service desk, the assets associated with an employee - especially when Intune or Jamf already serve as the source of truth. In that case, the rollout can be simple and very effective. It doesn't currently provide an independent discovery engine or a CMDB as deep as the other two products, so I wouldn't choose it if the main goal is infrastructure and business-service mapping.

In AIOps, the real competition is mainly between JSM and Freshservice. JSM offers flexibility and a deep connection between alerts, events, changes, and assets, while Freshservice provides a more structured, more accessible process for alert management, on-call, and major-incident handling. Zendesk remains stronger at AI that streamlines service-desk work than at infrastructure-grade AIOps.

At the end of the day, there's no outright winner here. JSM suits an organization willing to invest in order to get flexibility and depth. Freshservice suits someone looking for a more structured, faster way to connect service, assets, and operations. Zendesk suits someone who already manages assets in another system and wants to bring that information to the service agent without standing up a new enterprise CMDB.

Above all, a good CMDB isn't the one holding the largest number of records. It's the one that can answer, in real time, three questions: what's affected, who's impacted, and what's the risk of the next change. If it can't answer those, what you have is an asset repository - not really a CMDB.

---

In the next part, I move from data to actual execution: how a ticket becomes a correctly classified request, and how automation, integrations, and AI agents shorten the distance between opening a request and getting it done.

Continue the series: Part 4 - Automation, Integrations, and AI Agents