Submitting tickets on behalf of clients

[Ryan S]

Hi All,

I'm curious how folks are handling the different scenarios where an MSP is creating tickets for a client and being able to track the original requester. Speaking in a domain-separated environment. Apologies in advance if this is confusing as I'm still wrapping my head around parts of it.

Let's say MSP provides an application hosted in MSP environment, to client A. If the client is requesting something related to this service, a Service Request could be created under 'Client A' and the 'Requested For' can be a user in Client A's Company. What if the request is indirectly for the client? Maybe it's the MSP application team (tier 2) that needs to request a patch on the OS. It's still related to Client A but the 'Requested For' really wouldn't make sense as a client user. What company and requested_for are used in this (or other) scenarios?

Ok, let me pause there before I confuse things more. Hopefully starting a conversation...

[Ryan S]

Hi Kim, the idea of a generic user available to select on each company makes sense. But let's say Tier 2 is requesting the service but that Tier 2 person isn't the one entering the ticket? So the 'requested for' is the generic user and 'opened by' is someone else. Tier 2 user doesn't get tracked and doesn't have visibility to the ticket.

[Kim Sullivan]

Add whoever else needs visibility to the watch list

[Nicholas Bentle]

Hi Ryan,
If I’m interpreting your use case correctly, it sounds like you’re describing a scenario where ‘Client A’ has purchased a Service from an MSP. While Client A can raise requests related to that Service—requests that can be surfaced via a Service Catalog and processed through standard Service Request workflows—you're also highlighting the need for the MSP to independently manage that Service, regardless of how or if the client is currently consuming it.

Essentially, this leans towards a Service Provider operating model—one where the MSP handles Changes, Incidents, or other underlying activities that support the service offering, even if there's no direct impact to Client A. These operational tasks need to be managed outside the Client A domain. A simple analogy I often use is utility providers: they regularly perform maintenance or changes that don’t affect us as end consumers. But when there’s something significant—like an action that would interrupt power supply—we’re notified. The routine, behind-the-scenes work, however, goes unnoticed.

To support this model, there are several approaches you could take. Most critically, having a mature and well-structured CSDM in place is key. Given you’re operating in a domain-separated environment, you might consider creating a dedicated ‘Service Provider’ domain. This would sit independently from the MSP and customer domains and house the ‘as-a-Service’ offerings you want to support in this manner. This domain would contain only the necessary CSDM constructs and grant visibility exclusively to the MSP teams responsible for managing the work.

You could layer in further functionality by selectively exposing relevant details to customers when they're impacted. I highly recommend exploring ServiceNow's TPSM feature known as Proactive Service Experience Workflows—it’s designed precisely for scenarios like this.

[DaveMerrett]

So I can't speak for your situation, but this is how we as a MSP are doing it via the CSM Module


Best Practices for Tracking Original Requester in CSM Scenarios

1. Use the "Contact" Field Effectively

• In CSM, the Contact field on the Case record should represent the original requester (i.e., the client user).
• The MSP agent creating the ticket can be tracked via the Created by field or a custom field like MSP Agent if needed.

2. Leverage Case Relationships

• Use Case Relationships to link the MSP-created case to the original client case or request.
• This helps maintain visibility into the origin of the issue and allows for better reporting and SLA tracking.

3. Custom Fields or UI Policies

• Introduce a custom field like "Requested for" to explicitly capture the end-user.
• Use UI Policies to make this field mandatory when an MSP agent is creating a case.

4. Automation and Assignment Logic

• Automate assignment of related tasks (RITMs, SCTASKs) to appropriate teams while maintaining the original requester for communication.
• Consider using Advanced Work Assignment (AWA) to route tasks intelligently, but be cautious of overloading agents with multiple linked tasks.

5. Portal Experience

• Ensure that comments and updates from the client portal are routed to the correct agent or team.
• If RITMs are used for communication, assign them to someone responsible for client interaction, even if the SCTASK is doing the actual work.

6. Reporting and SLA Management

• Use reporting filters to distinguish between tickets created by MSPs and those by clients.
• Track SLA performance based on the Contact or Requested for fields to ensure client expectations are met.   

References

CSM and Request Management assignments best practices - ServiceNow