Pisano Ticket Management Process for Root Cause Analysis and Issue Resolution
This article explains how issues reported in Pisano move through the Root Cause Analysis (RCA) and Problem Management Process, from reporting to closure.
If you've reported an issue or want to understand how support handles reported issues, this guide explains each stage of the Root Cause Analysis (RCA) and Problem Management Process.
Each section below describes what happens during that stage, who takes action, and how the issue moves forward until it is resolved.
What You'll Find in This Guide:
- How the Process Starts
- Stage 1: Ticket or Support Email
- Stage 2: Problem Definition
- Stage 3: Impact Assessment
- Stage 4: Technical Investigation and Log Review
- Stage 5: SLA Definition
- Stage 6: Prioritization
- Stage 7: Root Cause Analysis and Resolution
- Stage 8: Testing and User Acceptance Testing (UAT)
- Stage 9: Deployment
- Stage 10: Closure
- Alternative Workflow for Non-Development Cases
How the Process Starts
An issue enters the process after it is reported through one of the available support channels.
Entry Points
- A ticket created through the Pisano support system
- An email sent to support@pisano.com
Initial Response
The first response is provided within a maximum of 2 hours after the request is received.
Prerequisite
An issue must be reported through one of the available support channels before the process begins.
📌 Stage 1: Ticket or Support Email
The process begins when an issue is reported through one of the available support channels. The support team acknowledges the request and provides the first response within a maximum of two hours.
Entry points
- Ticket created through the Pisano support system
- Email sent to support@pisano.com
Outcome The issue enters the Root Cause Analysis and Problem Management Process.
📌 Stage 2: Problem Definition
The reported issue is documented by collecting the information required for investigation and reproduction.
The collected information includes:
- What is the problem?
- When did it start?
- What was the expected behavior?
- What actually happened?
- What information is needed to reproduce or investigate the issue?
Additional details may also be collected when necessary, including:
- User details
- Channel
- Flow
- Date and time
- Transaction ID
- Other related identifiers
Outcome The issue is documented with sufficient information for investigation.
Notes
- Additional information may be requested when necessary.
📌 Stage 3: Impact Assessment
The support team evaluates how broadly the issue affects users, systems, and operations.
The assessment determines whether:
- Only one user is affected.
- A specific flow or channel is affected.
- The issue is limited to one customer environment.
- Multiple users or systems are affected.
- A critical operation is blocked.
This assessment helps determine the importance and severity of the issue before prioritization.
Outcome The issue receives an appropriate impact assessment before prioritization.
📌 Stage 4: Technical Investigation and Log Review
The technical investigation reviews relevant system records to understand the reported issue.
Depending on the issue, the investigation may include:
- Application logs
- Integration logs
- Background job records
- Provider records
- Error messages
The findings from this investigation are used together with the impact assessment to define the appropriate SLA or severity level.
Outcome The technical investigation provides the information required for prioritization and resolution.
📌 Stage 5: SLA Definition
The findings from the technical investigation and impact assessment are used to determine the appropriate SLA or severity level for the issue.
Outcome The issue receives a defined SLA or severity level.
📌 Stage 6: Prioritization
After the SLA or severity level is determined, the issue receives an appropriate priority.
When development work is required, the issue is shared with the relevant development team together with:
- Problem description
- Impact area
- Relevant logs and technical findings
- Reproduction steps
- Expected behavior
- Actual behavior
Outcome The issue is assigned the appropriate priority and forwarded for development when necessary.
📌 Stage 7: Root Cause Analysis and Resolution
The development team performs technical analysis to identify the root cause of the issue.
The analysis documents:
- Why the issue happened.
- Which system or component caused the issue.
- How the issue was resolved.
After the root cause is identified, the required fix or development work is completed.
Outcome The root cause is documented and an appropriate solution is completed.
Notes
- Some issues may be resolved without development.
- Alternative solutions include configuration changes, system updates, integration settings, operational actions, and temporary or permanent workarounds.
📌 Stage 8: Testing and User Acceptance Testing (UAT)
The completed solution is validated before release.
The solution is tested in the relevant environment. After technical and functional testing is completed, User Acceptance Testing is performed with the customer or relevant business teams when required.
Once the solution is confirmed to work as expected, the process moves to deployment.
Outcome The solution is validated before release.
Notes
- UAT is performed when needed.
📌 Stage 9: Deployment
After testing and UAT are successfully completed, the verified solution is deployed to the relevant environments.
Following the production release, final checks confirm that the issue no longer occurs.
Outcome The verified solution becomes available in the appropriate environments.
📌 Stage 10: Closure
After deployment and final verification confirm that the issue has been resolved, the related ticket or support record is closed.
Outcome The support process is completed.
Alternative Workflow for Non Development Cases
Not every issue requires development work.
Some issues may be resolved through:
- Configuration changes
- System updates
- Integration settings
- Operational actions
- Temporary or permanent workarounds
When this happens, the development stage is skipped and the process moves directly to testing and User Acceptance Testing.
The alternative workflow is:
❓ Frequently Asked Questions
How do I report an issue to Pisano Support?
You can report an issue by creating a ticket through the Pisano support system or by sending an email to support@pisano.com.
How quickly will I receive the first response?
The support team provides an initial response within a maximum of two hours after your request is received.
What information should I include when reporting an issue?
Include a description of the problem, when it started, the expected behavior, the actual behavior, and any details that can help reproduce the issue. Information such as user details, channel, flow, date and time, or transaction IDs may also be requested.
What happens after my issue is reported?
After your request is received, it enters the Root Cause Analysis and Problem Management Process, where it is documented, assessed, investigated, prioritized, and resolved through the appropriate workflow.
How is the impact of an issue determined?
The support team evaluates how many users or systems are affected, whether the issue is limited to a specific customer environment or flow, and whether it blocks critical operations.
What is reviewed during the technical investigation?
The investigation may include application logs, integration logs, background job records, provider records, and error messages to identify the cause of the reported issue.
How is the priority of my issue decided?
Priority is assigned after the impact assessment and technical investigation establish the appropriate SLA or severity level for the issue.
Does every issue require development work?
No. Some issues can be resolved through configuration changes, system updates, integration settings, operational actions, or temporary and permanent workarounds without involving development.
What is User Acceptance Testing (UAT), and when is it used?
User Acceptance Testing verifies that the solution works as expected from the customer's or business team's perspective. It is performed when required before deployment.
When is my support ticket closed?
The ticket is closed after the solution has been deployed, final verification confirms that the issue has been resolved, and the support process is complete.