Linking Accounts (or similiar) to Service Offerings

[C_K_1]

Hi, I want to document the companies that use service offerings we provide but I wasn't able to identify a good way to achieve this. Does someone have any insights or recommendations on this?

I know that simply linking a Company that acts as a customer to a service offering is most likely the wrong approach or a workaround at best. The more appropriate way could be linking accounts entitled to use this service offering. But this depends on the licencing of CSM and also has a few other caveats. Maybe using some kind of contract is also a solution?

Any kind of insight would be greatly appreciated.

Regards

Chris

[CMDB Whisperer]

The clearest platform capability for this would be in Customer Service Management, which ties the Sold Products to specific customers they are sold to.  The Sold Products have a Service Model that is the same as the Service Offering.  So for a given Service Offering you can tell which customers have a Sold Product that shares the same Service Model.  If that product requires an application instance to be deployed for the customer there is also an Install Base that tracks which Application Services are in use for each Sold Product.  So you can see at a high level what Service Offerings are used by which customers, and also manage the infrastructure and applications needed to main targeted service levels for those customers.

In lieu of that you could design something like you mention, where you have a related list of Company records representing the users of the service.  But you would have to define a process for keeping this up to date, and a clear method of using the data to actual deliver value, and none of this would be CSDM related.  It smells a bit like technical debt to me because the more functionality you build in to get that value, the further you stray from standards.  I would recommend taking a look at the CSM capabilities and seeing if you can make the business justification to expand your platform capabilities.  If you can't then you might want to consider whether you want to incur the technical debt either, because that could cost you more in the long term.

[Dylan Veerman]

Hi,

As mentioned above, the install base / sold products are most useful, but they are CSM.

Another option you could also explore is the: "Subscribe by" functionality and see if you can make it fit. OOTB the functionality is there on Service Offering. As also mentioned above, also here you should think smart about how to maintain it. 

[Barry Kant]

Hi,

if CSM is not within the consumed products, or if companies are internal legal entities than an alternative can be to use Subscription on the offering. There are 5 ways to subscribe to service offerings:

• Subscription by User (service_subscribe_sys_user)
• Subscription by Group (service_subscribe_sys_user_grp)
• Subscription by Location (service_subscribe_location)
• Subscription by Department (service_subscribe_department)
• Subscription by Company (service_subscribe_company)

It is part of the Service Builder function. 
The benefit can be that when a user is subscribed via 1 of the above methods to the service offering that you can make use of the catalog items related to that service offering as well. (If you can see the categories as well and depending on the available for/not available for criteria --> it should prevent to some extend to use those criteria).
An ootb script include (ServiceSubscriptionUtils) can be used to filter out all service offering that a logged on person is entitled to. 

So this is an alternative if CSM is not an option and still you want to link companies to service offerings. 

BR,

Barry

[C_K_1]

Hi,

thank you all for your insights. We are already using the "subscribed by" information to track the user base consuming a service offering. At the moment we often use "subscribed by company", but we want to be more precise and are using location/department/group subscriptions more and more.

So I'll probably take a closer look at CSM and see if there's we should use. Maybe I'm able to build a proper business case.

Regards

Chris