Tracking phone services offered to our employees - software or hardware asset?

[ahbrook]

Hey everyone! 

I'm currently trying to figure out how best to handle phone services on my campus. Our university is very much like a small city, only we have a dedicated telecom/ISP. 

In our case, we offer phone lines to the campus, in the form of office numbers, elevator numbers, convenience phones, softphone-only numbers, fax lines, and a variety of other flavors.

On each of those, we have different options:

• Will the phone number display as masked or unlisted?
• Does a given device have a primary and a secondary phone line that goes to it?
• What kind of phone is deployed at the other end?
• Is there specific programming to the directory number? 
• Is there voicemail?

Underpinning all of these services are things like the actual voice/network lines and such.  

The more I investigate the offerings (both in TNI and in ITSM/ITAM), the more I'm thinking those features should all be product models of some kind, and therefore assets. Then they can be bundled up where people can request the whole package. 

My main question, though, is - do you classify these things as a hardware or software asset? Like, the physical Cisco phone I could see as an asset (and a CI of "Communication device"). If they have Cisco Jabber installed on their computer, that could be a software asset (and definitely a software CI). But how would I classify the phone number and all of its features, which may or may not link to physical components? What about if they want a phone number to have a call menu associated with it?

If anyone has real-world examples of how they've approached this or tracked this kind of information (even if they use an external system that then feeds into ServiceNow), I'm all ears. We have a ton of historical data, I just need to slice and dice it into the right ways in our new product. 

[ahbrook]

This is extremely helpful, thank you! 

When you say "Service CI" - I assume you don't mean in the same sense as a Business Service / Offering or Technology Management Service / Offering? I know the terminology can get confusing, especially when trying to align with the CSDM and its recent updates. 

Also: In this case, how would you handle naming? Traditionally our telecom team has tracked what they call service features and service feature types using the associated telephone line number. Is this still a good idea, even with the linking? Or should it be something like "[Phone Number] - [Service Name]"? And is this something you can automate as part of building the product bundle, so our techs don't need to enter in a lot of manual information?

I guess this gives me a good reason to watch the ITAM training so that I can link up all this and track the assets and CIs together. 

[M Iftikhar]

Hi @ahbrook ,

Glad it was helpful!

By Service CIs, I mean logical service records representing the phone number and its features. These aren’t the same as Business Services/Offerings or Technology Management Services in CSDM, but they can be linked to them. A custom CI class like u_telephony_service works well to model the line and its features while connecting to the hardware/software CIs.

For naming, your telecom team’s approach using the phone number is fine. You could also use [Phone Number] - [Service Name] for clarity, especially if multiple services share a line.

This can be automated in the Service Catalog/product bundle. Workflows can:

• Create the logical Service CI with the correct name

• Link it to the relevant hardware (phone) and software (softphone)

• Populate key attributes (voicemail, call menus, etc.)

This reduces manual effort and keeps relationships consistent.
Watching ITAM training is a good next step—it will help you see how assets, software, and Service CIs can all be linked and managed together efficiently.

Thanks & Regards,
Muhammad Iftikhar
If my response helped, please mark it as the accepted solution so others can benefit as well.

[Shashank_Jain]

Hii @ahbrook ,

You can go through the following approach :

1. Physical Phones

   • Desk phones, elevator phones, or other devices → Hardware Assets

   • Also modeled as CIs of class “Communication Device”

2. Softphone Applications

   • Apps like Cisco Jabber or MS Teams Phone → Software Assets / Software CIs

3. Phone Numbers & Service Features

   • Voicemail, call menus, masking/unlisting, primary/secondary lines → Service CIs or Service Attributes

   • Not hardware or software; represent service entitlements

4. Bundling Services

   • Combine device + number + features into Service Catalog bundles (e.g., Office Phone Package) for easy ordering

5. System Usage

   • ITSM / Service Catalog → Ordering, fulfillment, linking to users

   • CMDB / CSDM → Model relationships between devices, numbers, and services

   • ITAM → Track physical devices and software licenses

   • TNI (Telecom & Network Inventory) → Optional, can sync telecom data to CMDB

6. Best Practice Approach

   • Desk phone → Asset + CI

   • Softphone → Software Asset + CI

   • Phone number → Service CI

   • Features → Service attributes/options in catalog

   • Call menus/IVR → Service Offering, independent of device