Your CMDB knows your phones exist. It has no idea what they do.

Quick question about your ServiceNow CMDB: does it know which of your phones haven’t placed a call since 2024?

It knows the phones exist. Probably. If we’re being honest, even that part is shaky. ServiceNow Discovery is happy to find your CUCM publishers and subscribers, because those are servers and servers answer to credentials. The phones themselves however… they generally expose no login, no agent, often no open ports. So a lot of ServiceNow shops end up with phone CIs that came from a spreadsheet import three years ago, or from a ping sweep, or from nowhere at all. Go read the ITOM forums sometime and you’ll see ​“how do I discover IP phones?” is a recurring question, and not one with very satisfying answers.

But let’s say your shop is one of the tidy ones, and every phone has a clean, current CI. Here is the sum total of what that CI knows: the phone exists, and here’s its metadata. Model, MAC, maybe a location, maybe an owner.

What it cannot tell you is anything about what the phone does. Whether anyone has touched it this quarter. Whether calls from it fail. Does it only receive inbound calls? Does maybe the branch office it sits in have a queue-abandonment problem that’s been quietly getting worse for six months?

We can fix that. And this is the part that surprised us when we sat down and worked through it — nobody has to build an integration. The plumbing already exists on both ends. You have to schedule a search.

The data: an inventory that actually knows things

If you have set up our Cisco CDR Reporting and Analytics app along with our Supporting App for AXL, your Splunk instance then already has a complete, continuously refreshed inventory of every device your CUCM cluster knows about — hardphones, Jabber clients, device profiles, the lot — along with the metadata AXL knows: model, firmware, device pool, directory numbers, owner, description.

On its own, that’s already a better phone inventory than most CMDBs are holding. The interesting part is what happens when Cisco CDR Reporting and Analytics joins that inventory against your call detail records. Now every device row picks up behavior: call counts by direction, durations, failures, last-seen times.

Notice something about that view: it doesn’t care whether a device made calls or not. Devices with zero calls still show up, because the inventory is the backbone and the stats are the decoration. That ​“zero calls” case turns out to be worth actual money. 

Here below the user has simply searched for all devices ​“calls=0” over the last 6 months.

The pipe: it already exists, and Splunk supports it

Here’s the lucky break. Our apps run on Splunk, and Splunk ships a supported add-on for ServiceNow that can push search results straight into a ServiceNow instance. It can raise incidents, it can send events to Event Management, and — the one we care about — its snowrecordstream command streams the rows of any search into an arbitrary ServiceNow table via an import set.

So the entire ​“integration” is:

1. A scheduled search in our app that joins the AXL inventory with whatever call stats you care about, per device.
2. | snowrecordstream (or an alert action) at the end of it, pointed at a staging table in your ServiceNow instance.
3. On the ServiceNow side, a transform map that coalesces rows onto your phone CIs by device name or MAC — as a related table or a handful of enrichment fields, refreshed nightly or hourly.

No middleware. No custom REST glue. Nothing for your ServiceNow team to build beyond an import set and a transform map, which for them is a Tuesday.

And a word of respect for CMDB governance, because your ServiceNow admins have earned it: we are not suggesting anything write directly into cmdb_​ci tables from the outside, and we are not auditioning to be a new source of record for what phones exist. Discovery — or whatever your source of record is — keeps that job. This pattern is enrichment: behavioral data, keyed to CIs that already exist, flowing through the sanctioned import-set path. Your CMDB stays governed. It just stops being ignorant.

OK, but what would you actually do with it?

Reclaim the dead fleet. Join ​“every phone AXL knows about” against ​“phones with zero calls in N months” and you get a defensible, continuously-updated reclamation list, sitting inside the system your asset managers already live in. Phones to unrack, licenses to trim, refresh budgets to shrink. This is the use case where somebody can attach a dollar figure by Friday.

Incidents that arrive knowing things. A failure-rate spike on a gateway or a device can open a ServiceNow incident bound to the right CI, with usage stats attached — instead of a ticket that says ​“phones broken in Building C?” and a technician starting from zero.

And then there’s the part nobody else can do.

Leg types: shipping your call-flow logic into your CMDB

If you’ve used our leg type system, you know it lets you define arbitrary — frankly, idiosyncratic — labels for call legs based on whatever logic matters to you. Not ​“inbound” and ​“outbound.” Things like long queue time. Abandoned in IVR. Transferred more than twice. After-hours call to the emergency line. You define the classification once, and every matching leg gets the label, forever, across arbitrarily long timescales.

Those labels roll up at the device level, which means they ride the exact same pipe as everything above. Which means your ServiceNow instance can know, per phone, per site, per whatever: how many abandoned-in-IVR legs touched this branch office last quarter, and whether that number is going up.

Stop and think about what that actually is. It’s contact-center behavioral analytics, classified by your business logic, surfaced as first-class data on configuration items in your ITSM platform. No generic connector can ever produce this, because the classification layer is the whole point — ​“abandoned in IVR” isn’t a field in any CDR. It’s a judgment your organization defined, computed across every call leg you’ve ever recorded.

As always, this is just the beginning

If you run our apps and ServiceNow side by side, everything above is buildable today with things you already own. We’re considering packaging it properly — ready-made scheduled searches on our side, an update set for the ServiceNow side — and we’d like to hear whether that’s worth doing. If you’d use it, or if you’ve already wired up something like this yourself, please let us know. 

And if you’re not running our apps yet — the free trial is right here