Customers sometimes include multiple questions, problems, or service requests in a single ticket. Although these requests appear in one conversation, they may require different teams, priorities, workflows, service targets, or resolution timelines.

In these situations, agents can use Split Ticket to create a separate ticket from a customer reply. The new ticket can be assigned, prioritized, tracked, and resolved independently while remaining associated with the original ticket.

Split a ticket when part of the customer’s message represents a distinct request that should be owned, prioritized, tracked, or resolved independently.

1. Determine Whether the Customer Has More Than One Request

Review the customer’s message and identify whether it contains:

• Multiple requests
• Multiple issues
• Multiple service needs

Example: "I can't sign in to the customer portal. Also, please update the billing address on our account."
This message contains two separate requests:

• Login issue
• Billing address update

If the customer only has one request, do not split the ticket.

2. Determine Whether the Requests Can Be Managed Independently

Ask yourself the following question: Can any request be owned, prioritized, tracked, reported on, worked on, or resolved independently from the original request?

• If Yes, split the ticket.
• If No, keep the requests together.

3. Check for Split Indicators

A ticket should be split when one or more of the following conditions apply.

Scenario A: The Requests Are Unrelated

Example: "I can't sign in to the portal, and I need my billing address updated."
Why split?

• Different objectives
• Different resolution paths
• Potentially different teams

Decision: Split the ticket.

Scenario B: Different Teams Need to Handle the Requests

Example:
Customer reports:

• Product defect
• Refund request
• Security concern

Possible ownership:

• Product Support
• Finance
• Security/Compliance

Decision: Split the ticket so each team can manage its own request

Scenario C: The Requests Have Different Priorities

Example
Customer reports:

• Production service outage
• Typographical error in the application

Why split?

• The outage requires immediate attention.
• The typo follows a normal enhancement process.

Decision: Split the ticket.

Scenario D: The Requests Have Different Resolution Timelines

Example
Customer requests:

• Password reset
• Performance investigation

Why split?

• Password reset may be completed immediately.
• Performance issues may require extended troubleshooting.

Decision: Split the ticket.

Scenario E: The Requests Follow Different Workflows

Example
Customer submits:

• Product question
• Critical incident

Why split?

• Incidents require escalation and monitoring.
• Questions follow standard support processes.

Decision: Split the ticket.

Scenario F: The Request Requires Independent Follow-Up

Example: During troubleshooting, the customer asks: "Can you also arrange training for our new administrators?"

Why split?
The training request requires:

• Coordination
• Scheduling
• Follow-up communication

Decision: Split the ticket.

Scenario G: The Customer Introduces a New Issue

Example:
Original ticket: Email delivery issue
Customer later replies: "The email issue is fixed. I now need help configuring the customer portal."

Why split?
The portal configuration request is unrelated to the original issue.

Decision: Split the ticket.

Scenario H: One Request Can Be Closed While Another Remains Open

Example
Customer requests:

• Restore user access
• Add a new product feature

Why split?

• User access can be completed immediately.
• Feature requests may require long-term review.

Decision: Split the ticket.

4. Check Whether the Requests Should Stay Together

Do not split a ticket simply because the customer mentions multiple details, symptoms, or questions.
Keep the ticket together when all requests contribute to the same customer outcome.

Situation A: Multiple Symptoms of the Same Problem

Example: "The report loads slowly, shows an error, and sometimes exports an empty file."
Why keep together?
The symptoms may share the same root cause.

Decision: Keep together.

Situation B: One Action Depends on Another

Example: "Please restore the deleted record and verify it appears in the monthly report."
Why keep together?
Verification is part of confirming the restoration was successful.

Decision: Keep together.

Situation C: Additional Information Supports the Existing Issue

Example: "The login page displays an error. This started after we changed our SSO settings."
Why keep together?
The SSO information supports the investigation.

Decision: Keep together.

Situation D: The Customer Is Asking a Clarifying Question

Example: "Can you also explain why this happened?"
Why keep together?
The question relates directly to the original issue.

Decision: Keep together.

Situation E: The Requests Follow the Same Resolution Path

Keep the ticket together when all requests:

• Are handled by the same team
• Follow the same workflow
• Have the same priority
• Share the same resolution process

Decision: Keep together.

5. Identify the Primary Request

Before splitting the ticket, determine which request should remain in the original ticket.
Generally, keep the issue that is:

• Mentioned first by the customer
• The customer’s primary concern
• Already under investigation
• Associated with the current ticket subject
• The highest business-impact issue

Move the remaining request into a new ticket.

6. Create the Split Ticket

Create a new ticket for the secondary request so it can be managed independently.
The new ticket will have its own:

• Ticket number
• Status
• Assignment
• Priority
• Workflow
• Resolution history

while remaining associated with the original ticket.

7. Inform the Customer

Always explain what was separated and how each request will be handled.
Example: We have created a separate ticket to track your billing address update. Your login issue will continue to be handled under this ticket. The new ticket has been assigned to the Billing team, and you will receive updates there as work progresses.

Good communication helps prevent confusion and duplicate follow-ups.

Frequently Asked Questions

1. Does splitting remove the customer’s reply from the original ticket?
   No. The original conversation remains unchanged. A new ticket is created using the selected customer reply as context.

2. Does the new ticket receive a separate ticket number?
   Yes. The split ticket receives its own ticket ID, status, assignment, and workflow.

3. Can the same customer reply be split more than once?
   Yes. If one customer reply contains several unrelated requests, multiple tickets can be created from the same reply, provided the split option remains available. Create only the tickets required for independent ownership, tracking, and resolution.

4. Can an agent reply or note be split?
   No. The Split Ticket option applies only to replies submitted by the requester or another contact associated with the ticket. Agent replies, public notes, and private notes cannot be split into new tickets.