Wrightery for MSPs: AI-Assisted RCA & Post-Incident Reporting
Document type: Product Strategy & Definition Brief
Working product name: Wrightery Incident Analyst
Initial vertical: Managed Service Providers (MSPs) and enterprise managed-services organizations
Primary workflow: Root Cause Analysis (RCA) / Post-Incident Review (PIR) investigation and client-facing reporting
Status: Product hypothesis for customer discovery and pilot validation
1. Executive Summary
Wrightery Incident Analyst is an AI analyst workspace for Managed Service Providers that helps service teams investigate major incidents and produce evidence-backed Root Cause Analysis (RCA) and Post-Incident Review/Report (PIR) deliverables.
The opportunity is not simply to generate an RCA/PIR template. Major IT service-management platforms already support incident records, timelines, problem management, and PIR reporting. ServiceNow, for example, has a Post Incident Report workflow that compiles an overview, findings, resolution information, and an incident timeline and can export the result as a PDF.
The harder problem is what happens before the report is complete.
For a complex customer incident, the relevant evidence can be fragmented across:
ServiceNow or another ITSM/PSA platform
previous incidents and problem records
client-specific knowledge bases
internal operational documentation
emails with the client
emails with vendors and partners
meeting notes and transcripts
change records
engineering notes
monitoring and observability evidence
attached documents and other unstructured sources
A service manager, major incident manager, problem manager, or technical lead must reconstruct what happened, find relevant historical incidents, reconcile conflicting information, identify evidence supporting possible causes, determine corrective actions, and then turn the investigation into a professional client-facing deliverable.
Wrightery's wedge is the investigation layer, not the report template.
Turn fragmented incident evidence into a traceable, client-ready RCA/PIR - with the human expert making the final call.
2. Why This Is Different From Existing MSP Reporting
Existing systems are systems of record
ITSM, PSA, RMM, monitoring, documentation, and collaboration systems are optimized to store and manage operational information.
Examples include:
incident tickets
alerts
timelines
changes
assets and configuration items
problem records
knowledge articles
communications
service metrics
They may also provide structured PIR/RCA forms and reports.
Wrightery should be the system of investigation
Wrightery sits across those systems and answers a different question:
Given everything we know about this customer and this incident, what actually happened, what evidence supports that conclusion, what remains uncertain, and how should we explain it to the customer?
The differentiation is therefore not:
"We use AI to write RCA reports."
It is:
"We give your incident team an AI analyst that investigates across the customer's operational history and produces an evidence-backed RCA/PIR for expert review."
3. The Problem
Current workflow
A significant incident occurs.
The MSP resolves or mitigates the immediate problem, but the work is not finished. Someone must investigate and communicate:
What happened?
When did it happen?
What was the customer impact?
What events led to the incident?
Has something similar happened before?
What changed before the incident?
What was the root cause?
What factors contributed?
What actions restored service?
What corrective/preventive actions should follow?
What evidence supports each conclusion?
What should be communicated to the customer?
The information needed to answer these questions may span multiple systems and multiple organizations.
The expensive part
The expensive part is usually not formatting the final PDF.
It is:
search -> collect -> reconstruct -> compare -> cross-check -> reason -> validate -> draft -> review
This is precisely the type of analyst workflow Wrightery is designed to address.
4. Product Definition
Product category
AI Incident Investigation & Reporting Workspace
Alternative category descriptions to test:
AI Incident Analyst for MSPs
AI-Assisted RCA & PIR
Incident Intelligence Workspace
AI Investigation Layer for IT Service Management
Evidence-Backed Incident Analysis
For initial outreach, "AI Incident Analyst for MSPs" is the clearest.
Product statement
Wrightery Incident Analyst investigates customer incidents across ITSM records, historical issues, knowledge bases, emails, meeting notes, and other evidence, then helps the service team produce a traceable RCA/PIR for customer delivery.
Product promise
From fragmented incident history to an evidence-backed client deliverable in a fraction of the manual investigation time.
The time-savings claim should remain qualitative until additional MSP pilots establish a defensible benchmark.
5. Core Workflow
Step 1 - Start from an incident
The user selects a major incident, problem record, or investigation.
Wrightery retrieves the core incident context from the MSP's ITSM/PSA system.
Step 2 - Build an evidence workspace
The product searches authorized sources associated with the customer and incident:
current incident
related tickets
previous similar incidents
problem records
changes
client knowledge base
service documentation
email threads
meeting notes/transcripts
partner/vendor communications
attachments
optionally logs, alerts, or observability summaries
Every retrieved item retains source metadata.
Step 3 - Reconstruct the incident
AI analysts create a working investigation:
event timeline
customer impact
systems/components involved
actions taken
people/teams involved
relevant changes
similar historical incidents
unresolved questions
contradictions between sources
Step 4 - Develop and test hypotheses
Rather than immediately declaring a root cause, the system can generate candidate hypotheses and evaluate each against the available evidence.
For each hypothesis:
supporting evidence
contradicting evidence
missing evidence
related historical evidence
confidence/uncertainty
questions requiring human investigation
This is an important product principle: Wrightery assists the investigation; it does not pretend that an LLM's first answer is the root cause.
Step 5 - Human expert review
The Major Incident Manager, Problem Manager, technical lead, or other authorized expert:
reviews evidence
accepts/rejects findings
corrects conclusions
adds missing context
approves root cause
approves corrective actions
Step 6 - Generate the client deliverable
Wrightery converts the approved investigation into the MSP's RCA/PIR format.
Possible sections:
Executive Summary
Incident Overview
Customer Impact
Timeline
Technical Findings
Root Cause
Contributing Factors
Resolution
Corrective and Preventive Actions
Lessons Learned
Open Actions / Owners
Evidence / References
Step 7 - Preserve institutional knowledge
The approved investigation becomes reusable knowledge for future incidents.
A later incident can ask:
"Have we seen anything like this before for this customer or across permitted historical cases?"
This creates a compounding value proposition: every completed investigation improves the organization's accessible incident knowledge.
6. Unique Value Proposition
Primary value proposition
Investigate first. Report second. Every conclusion traceable to evidence.
Four sources of differentiation
1. Cross-system investigation
An ITSM product knows what is inside the ITSM system.
Wrightery's opportunity is to reason across the broader evidence environment surrounding the incident.
2. Customer-history awareness
The system investigates an incident in the context of the customer's history rather than treating it as an isolated ticket.
This is particularly valuable for recurring or related failures.
3. Evidence traceability
Important claims in the deliverable should link back to their supporting evidence.
The reviewer can ask:
Where did this claim come from?
Which email supports it?
Which incident established this?
Which meeting note contradicts it?
Is this a fact or an AI inference?
4. Multi-agent investigation
Different analyst agents can perform specialized tasks:
Timeline Analyst
Historical Incident Analyst
Change Analyst
Communications Analyst
Root-Cause Hypothesis Analyst
Evidence/Contradiction Reviewer
Client Report Writer
The product should not market "multi-agent" as the main customer benefit. The customer benefit is a faster, more complete and auditable investigation.
7. Competitive Positioning
Do not compete with ServiceNow/PSA systems as the system of record
Wrightery should complement them.
A useful mental model:
Layer Primary job
ITSM / PSA / RMM / monitoring Capture and operate
Knowledge & collaboration systems Store context
Wrightery Investigate, synthesize, cross-check and produce the deliverable
The key positioning question
Do not ask:
"Can ServiceNow generate a PIR?"
It can.
Ask:
"How much expert work is still required to investigate the incident and assemble a trustworthy PIR when the evidence is spread outside the incident record?"
That is the market hypothesis to validate.
8. Ideal Customer Profile
Initial ICP
Prioritize MSPs and managed-services organizations that:
serve mid-market or enterprise customers
operate formal Major Incident Management processes
have contractual RCA/PIR obligations or strong customer expectations
use ServiceNow or another mature ITSM/PSA platform
have information fragmented across several systems
manage complex cloud/infrastructure/application environments
experience enough significant incidents for RCA/PIR work to be recurring
have service managers or technical leaders spending meaningful time assembling customer reports
Higher-potential environments
Likely stronger candidates include:
enterprise MSPs
cloud managed-service providers
infrastructure managed-service providers
application managed-service providers
cybersecurity/MSSP organizations where the workflow is appropriate
organizations providing mission-critical managed services
A small MSP primarily handling endpoint support for small businesses may have less need for formal RCA/PIR workflows.
9. Buyer, Champion and Users
Economic buyer / executive sponsor
Roles to test:
VP / SVP Managed Services
Head of Managed Services
COO of an MSP
VP Service Delivery
Head of Service Management
CIO/CTO in smaller MSPs
Their concerns:
service-delivery margin
customer satisfaction
SLA performance
consistency
operational scalability
reducing senior-engineer toil
client retention
Best operational champion
Director/Head of Service Delivery or Major Incident Management
This person is likely close enough to understand the pain and senior enough to sponsor a pilot.
Primary users
Major Incident Manager
Problem Manager
Service Delivery Manager
Technical Service Manager
Incident Manager
Service Manager
Senior support/operations engineers
Technical Account Manager, depending on organization
Technical/integration stakeholder
ServiceNow Platform Owner
ITSM Product Owner
Enterprise Architect
Security/Compliance
IT Operations leadership
Recommended outreach priority
Head/Director/VP of Service Delivery
Head/Director of Managed Services
Major Incident Management leader
Problem Management leader
ServiceNow/ITSM leader
COO/CTO for smaller MSPs
10. Discovery Questions
The first conversations should validate the problem rather than pitch a finished product.
Ask:
After a major customer incident, do you normally provide an RCA, PIR, or similar report?
Which incidents require one?
How many do you produce in a typical month or quarter?
Who owns the investigation and final report?
Roughly how many person-hours go into one?
What portion is investigation versus writing/formatting?
Which systems must the team search?
How much relevant information lives outside the ITSM incident?
Do investigators search previous incidents for similar patterns?
Are email and meeting discussions important evidence?
What makes an RCA/PIR difficult or slow today?
What is the review/approval process?
Are there contractual deadlines for delivering the PIR?
What happens when evidence conflicts?
How important is it to show the source behind a conclusion?
What prevents you from using general-purpose AI for this today?
What systems would a solution have to integrate with before you would trust it?
Would you pilot this on historical closed incidents where the accepted root cause is already known?
Question 18 is especially valuable because historical incidents create a low-risk way to evaluate the product against known outcomes.
11. Pilot Definition
Recommended pilot
Historical RCA/PIR Reconstruction Pilot
Use 10-20 previously closed incidents for which the MSP already has an approved RCA/PIR.
For each incident, provide Wrightery access to an agreed set of historical evidence and ask it to independently build the investigation dossier and draft.
Compare against the existing human-produced report.
Pilot measurements
Measure:
investigator time saved
report preparation time saved
relevant evidence discovered
historical incidents correctly surfaced
timeline completeness
unsupported claims
contradictions detected
reviewer corrections required
factual accuracy
source traceability
user trust
final deliverable quality
Pilot success criterion
Do not define success as "the AI guessed the same root cause."
A stronger success definition is:
Wrightery materially reduces investigation/reporting effort while giving the expert a more complete, traceable evidence set and maintaining or improving deliverable quality.
12. Product Guardrails
RCA is consequential. The product should be designed as an investigative assistant, not an autonomous authority.
Important controls:
Never silently convert inference into fact.
Clearly distinguish facts, hypotheses, and human-approved conclusions.
Preserve source citations.
Show contradictory evidence.
Allow reviewers to reject AI findings.
Require human approval before a client-facing report is finalized.
Respect tenant/customer data boundaries.
Provide role-based access.
Maintain an audit trail of evidence, AI analysis, edits, and approvals.
Do not reuse one customer's confidential incident evidence for another customer without explicit authorization and appropriate isolation.
Support configurable retention and governance.
Trust is part of the product, not merely a compliance feature.
13. MVP Scope
Must have
Create an investigation from an incident
ServiceNow or selected ITSM ingestion
document/knowledge-base ingestion
email ingestion or selected-thread import
meeting-note/transcript ingestion
semantic retrieval across historical incidents
evidence-backed timeline generation
related-incident discovery
hypothesis/supporting-evidence workflow
contradiction/uncertainty identification
source citation for generated claims
human review/edit/approval
configurable RCA/PIR template
export to DOCX/PDF or publish back into the customer's workflow
Later
additional PSA/ITSM integrations
observability/log integrations
automatic incident clustering
cross-customer anonymized pattern intelligence where legally and contractually permitted
corrective-action tracking
proactive recurring-problem detection
customer-specific report styles
automated SLA/deadline workflow
analytics across RCA/PIR history
14. What Not to Build First
Avoid starting with:
Generic QBR generator
This is easier for existing PSA/MSP platforms to commoditize because much of the underlying information is structured metrics.
Generic AI report writer
This competes with broad document-generation tools and does not exploit Wrightery's research/cross-checking capabilities.
Fully autonomous root-cause engine
This creates a much higher technical and trust burden and moves the product toward observability/AIOps competition.
Another ITSM
Wrightery should integrate with the operational system of record rather than replace it.
15. Messaging
One-line category
AI Incident Analyst for MSPs
Short product description
Wrightery investigates major incidents across tickets, historical issues, knowledge, email and meeting evidence, then helps your team produce a traceable client-ready RCA/PIR.
Value proposition
Turn hours of fragmented incident investigation into an evidence-backed RCA/PIR your experts can review, verify and deliver.
Differentiation line
Your ITSM records the incident. Wrightery investigates the story behind it.
Trust line
Every important claim links back to the evidence. Your expert makes the final call.
16. Recommended First LinkedIn Connection Note
Keep the connection request focused on learning rather than selling.
Hi [Name] - I'm exploring how MSPs handle RCA/PIR after major client incidents, especially when evidence is spread across ITSM, past issues, email and meeting notes. I've built a solution in this area for an enterprise MSP and would value comparing notes. - Gary
If the character limit is tight:
Hi [Name] - I'm exploring how MSPs handle RCA/PIR when incident evidence is scattered across ITSM, history, email and meetings. I've built in this area for an enterprise MSP and would love to compare notes. - Gary
17. Recommended LinkedIn Message After Connection
Hi [Name],
Thanks for connecting. I'm researching a workflow I previously worked on with an enterprise managed-services provider: producing a client-facing incident/RCA report required pulling together the current ITSM record, historical issues, customer knowledge, emails, and meeting notes.
It made me wonder how common this problem is across MSPs. I'm now developing Wrightery, an AI analyst platform, and we're exploring an incident analyst that assembles and cross-checks that evidence before drafting a traceable RCA/PIR for human review.
I'm not looking to pitch you on a finished product - I'd really value 20 minutes to understand how your team handles RCA/PIR today and whether this is a meaningful problem across the industry.
Would you be open to a short conversation?
Cheers,
Gary
18. Recommended Cold Email
Subject: How does your team build client RCA reports?
Hi [Name],
I'm researching how managed-service teams investigate major incidents and produce client-facing RCA/PIR reports.
In a project with an enterprise MSP, I saw that the difficult part wasn't the report template - it was reconstructing the incident across the ITSM record, previous customer issues, knowledge bases, email threads, meeting notes and partner communications.
I'm now building Wrightery, an AI analyst platform, and we're exploring a focused incident-analysis product that brings that evidence together, cross-checks it, builds the timeline and findings, and drafts a source-traceable RCA/PIR for expert review.
Before we go further, I want to understand how consistently this problem appears across MSPs.
Would you be open to a 20-minute conversation about how your team handles RCA/PIR today? I'm primarily looking to learn, not sell you a finished product.
Cheers,
Gary
19. Message for an MSP Industry Expert / Connector
This is appropriate for someone who advises many MSPs.
Hi [Name],
Thanks for connecting. I noticed you work closely with MSPs, and I'd value your perspective on a workflow I'm investigating.
I previously worked on a solution for an enterprise MSP where a client incident report had to be assembled from ServiceNow, the customer's historical issues and knowledge base, plus emails and meeting notes with the client and partners.
I'm now exploring whether RCA/PIR investigation could be a focused use case for Wrightery: an AI analyst that researches across those sources, reconstructs the incident, cross-checks evidence, and drafts a traceable report for the service team to approve.
My main question right now is whether this pain is common and expensive enough across MSPs to justify a dedicated solution. If you're open to it, I'd love to get your perspective and learn how you see MSPs handling this today.
Cheers,
Gary
20. Initial Go-to-Market Motion
Phase 1 - Problem validation
Interview 15-25 people across:
enterprise MSPs
mid-sized MSPs
MSP consultants
ServiceNow/ITSM specialists
Major Incident Management leaders
Do not lead with a product demo.
Quantify:
frequency x people involved x hours per investigation x loaded labor cost + customer/SLA impact
Phase 2 - Historical incident pilot
Find 2-3 design partners.
Run historical incidents through Wrightery and compare the output against approved RCA/PIRs.
Phase 3 - Live assisted workflow
Use Wrightery on real incidents with mandatory human review.
Phase 4 - Repeatable MSP package
Standardize:
connectors
incident workspace
evidence model
RCA/PIR templates
governance
onboarding
pilot methodology
pricing
Phase 5 - Channel expansion
MSP consultants, ITSM consultants, ServiceNow partners, cloud advisers and other ecosystem participants could become distribution partners once the workflow has been validated.
21. Pricing Hypothesis
Do not lock pricing before discovery.
Potential models to test:
Per investigation / deliverable
A natural fit when RCA/PIR volume is measurable.
Workspace subscription + usage
Base platform fee for governance, integrations, collaboration and auditability, plus usage tied to investigations/evidence processing.
Enterprise annual contract
Appropriate for large MSPs with multiple service-delivery teams.
The pricing anchor should be the cost and value of the investigation, not the cost of generating a document.
22. Key Validation Risks
Before committing to this vertical, answer these questions:
How frequently do MSPs actually produce formal RCA/PIR deliverables?
Which MSP segments produce enough volume?
Is investigation time materially larger than report-formatting time?
How much critical evidence exists outside ITSM?
Are customers willing to connect email/meeting/knowledge sources?
Can existing ServiceNow AI capabilities solve enough of the problem?
How much variation exists between MSP RCA processes?
Who owns the budget?
How urgent is the problem relative to other MSP automation priorities?
Is the value primarily labor savings, report quality, SLA compliance, customer trust, or all four?
These are hypotheses, not assumptions to hide.
23. Why This Is a Strong Wrightery Wedge
This workflow fits Wrightery's broader product thesis unusually well because it has all of the characteristics that make an AI analyst valuable:
evidence is fragmented
much of it is unstructured
historical context matters
cross-checking matters
reasoning is required
conclusions have to be explained
source traceability matters
the output is a professional deliverable
a human expert remains accountable for the final decision
The end product is a report, but the product value is the analyst work that produces it.
That distinction should guide product design, positioning, demos, pricing and sales.
24. Recommended Product Narrative
A simple narrative for prospects:
A major client incident is resolved, but now your team has to explain what happened.
The answer isn't sitting in one ticket. It's spread across ServiceNow, previous incidents, customer documentation, email threads, meeting notes, changes and conversations with partners.
Today, experienced people manually reconstruct that story.
Wrightery gives them an AI incident analyst. It gathers the relevant evidence, builds the timeline, finds related historical issues, tests possible explanations, surfaces contradictions, and drafts the RCA/PIR with every important claim traceable to its source.
Your expert reviews the evidence and makes the final call.
Your ITSM records the incident. Wrightery investigates it.
25. Research Basis
This product hypothesis deliberately assumes that existing ITSM platforms already cover significant portions of formal PIR/RCA reporting.
ServiceNow's current Major Incident Workbench includes a Post Incident Report with Overview, Findings, Resolution and Timeline sections and supports compiling the completed report into a PDF. ServiceNow also describes PIR publication to stakeholders as part of the post-major-incident workflow. This reinforces the need to differentiate Wrightery on cross-source investigation and evidence synthesis, rather than basic report generation.
Research on operational RCA also supports the importance of historical incident knowledge and evidence-backed investigation. Salesforce researchers have described extracting root-cause knowledge from past incident investigations to make that knowledge reusable for future RCA. More recent research on AI-assisted incident diagnosis emphasizes auditable evidence and the role of AI as an investigative assistant rather than an opaque oracle.
Sources
ServiceNow, Major Incident workbench - The Post Incident Report tab
https://www.servicenow.com/docs/r/it-service-management/incident-management/mi-workbench-pir-tab.htmlServiceNow, Review and update a post incident report
https://www.servicenow.com/docs/r/it-service-management/service-operations-workspace/review-update-pir-mim-sow.htmlSaha & Hoi, Mining Root Cause Knowledge from Cloud Service Incident Investigations for AIOps (2022)
https://arxiv.org/abs/2204.11598Zhang et al., Automated Root Causing of Cloud Incidents using In-Context Learning with GPT-4 (2024)
https://arxiv.org/abs/2401.13810
26. Immediate Next Step
Before building a dedicated MSP product, use this document as a customer-discovery thesis.
The next milestone should not be "ship the RCA feature."
It should be:
Interview enough MSP service-delivery and incident-management leaders to prove that cross-source RCA/PIR investigation is frequent, expensive, painful, and insufficiently solved by their existing ITSM stack.
If that is validated, the existing enterprise-MSP implementation becomes a powerful proof point for turning Wrightery Incident Analyst into a repeatable vertical solution.