From AS-IS to TO-BE: Redesigning the Support Resolution Process
Part 2 of my “Closing the Loop” portfolio case study on support operations, process improvement, and knowledge reuse.
In Part 1, I explored a process gap that can exist even when a support issue is successfully resolved:
the resolution does not necessarily become easy to find and reuse the next time a similar issue appears.
That led to the next stage of my portfolio project — moving from the current-state process (AS-IS) to a redesigned future-state process (TO-BE).
The goal was not to automate every support decision.
It was to create a more structured path between:
issue submission → historical knowledge → resolution → knowledge reuse
while keeping human judgment where it is still required.
The AS-IS Process
The simplified current-state workflow I mapped was:
Agent faces an issue
↓
Checks SOP
↓
Searches Slack for similar past issues
↓
Resolved?
If Yes:
Agent applies the solution
If No:
Issue is posted in the relevant Slack channel
↓
Client or Team Lead responds
↓
Agent applies the solution
↓
Tracker is manually updated
↓
Does the issue repeat?
If No:
Process complete
If Yes:
The issue may later become a bug investigation or an SOP update.
At first glance, the process works.
Issues are escalated when needed and eventually resolved.
But from a process-improvement perspective, several weaknesses become visible.
Where the Current Process Breaks Down
Historical knowledge requires manual searching
The agent needs to know where to search and how to describe the issue effectively.
A relevant answer may already exist, but finding it still depends heavily on manual effort.
Escalation can become a knowledge-retrieval mechanism
Some issues genuinely require more expertise.
Others may be escalated because a previously confirmed solution is difficult to locate.
Those are two different operational problems.
Resolution capture happens after the work
The tracker is manually updated after the issue is resolved.
That introduces another step that depends on consistent human follow-through.
Recurring issues may not become visible immediately
Individual incidents can be closed successfully while the same underlying issue continues to reappear.
The process handles single incidents, but does not automatically connect them into a broader pattern.
Moving to the TO-BE Process
I redesigned the workflow around one question:
Before escalating a new issue, can the process first determine whether a genuinely similar issue has already been resolved
The redesigned process begins with structured capture.
The TO-BE Workflow
Issue raised
↓
Issue automatically logged in the tracker
↓
Approved SOP / knowledge checked
↓
Relevant previously resolved incidents retrieved
↓
Matching issue found?
If Yes:
Show suggested historical resolution
↓
Issue resolved?
If Yes:
Record resolution used
If No:
Escalate the structured issue
If no reliable match is found:
Escalate the structured issue
↓
Client / Team Lead provides guidance
↓
Confirmed resolution captured
↓
Resolution linked back to the tracker
The broader future-state process can then continue into:
Recurrence Detection → Bug / SOP Review → Human Approval → Knowledge Update
Design Decision 1: Structure the Issue Before Searching
One of the first changes was moving from an informal issue description to structured intake.
Get Aovila Saandeep’s stories in your inbox
Join Medium for free to get updates from this writer.
The information I designed the workflow around includes:
- Product
- Issue Summary
- Customer Impact
- SOP Checked
- Steps Tried
- Evidence
- Help Needed
This gives the process a consistent starting point.
It also makes both escalation and historical comparison more reliable.
Design Decision 2: Retrieve Relevant Cases First
I did not design the process around sending the entire historical issue repository into the AI step.
Instead, the workflow first retrieves a smaller set of relevant resolved incidents.
Then semantic matching happens against those candidates.
Conceptually:
New Issue → Relevant Historical Cases → Similarity Comparison
This keeps the matching step focused and reduces irrelevant context.
Design Decision 3: Do Not Force a Match
This became one of the most important requirements.
Two incidents can involve the same product without representing the same problem.
For example, API incidents may involve:
- authentication;
- rate limiting;
- documentation;
- streaming;
- permissions.
Simply sharing the product name should not be enough to recommend a previous resolution.
The workflow therefore needs to be able to return:
No Match
when the symptoms and context are not genuinely similar.
That is more useful than always returning the closest available historical issue.
Design Decision 4: Suggested Resolution Is Not Confirmed Resolution
I deliberately kept these as separate concepts.
Suggested Resolution
A previously confirmed historical solution that appears relevant to the new incident.
Confirmed Resolution
The solution that has actually been validated for the current incident.
The distinction matters because historical similarity does not guarantee that the previous solution applies to the current case.
A changed configuration, product update, or different underlying cause could make the historical guidance inappropriate.
So the workflow can surface knowledge.
It does not automatically declare that knowledge correct.
Escalation Still Matters
The TO-BE design does not try to eliminate escalation.
Escalation remains necessary when:
- no reliable historical match exists;
- the suggested resolution does not work;
- additional expertise is required;
- or the issue context remains uncertain.
The difference is the order.
Instead of:
manual search → escalation
the redesigned flow becomes:
structured issue → historical retrieval → suggested match if appropriate → human validation or escalation
The purpose is not to replace specialists.
It is to make better use of knowledge the organization may already have before involving them.
What Changed From AS-IS to TO-BE
The biggest change is not simply the addition of AI.
It is how knowledge moves through the workflow.
AS-IS
Issue → Manual Search → Escalation → Resolution → Manual Capture
TO-BE
Issue → Structured Capture → Historical Retrieval → Suggested Match → Human Validation / Escalation → Confirmed Resolution → Reusable Knowledge
That creates a more direct connection between:
past resolutions
and
future issues
Instead of treating each resolved ticket as an isolated event, confirmed resolutions can become part of a reusable knowledge history.
Keeping the First Build Smaller
The complete future-state design goes further into:
recurrence detection → bug / SOP review → AI-assisted drafting → human approval → knowledge-base update
But I intentionally kept those stages outside the first implementation.
For the MVP, the boundary was:
Issue Submission → Tracker → Historical Retrieval → Matching → Suggested Resolution → Tracker Update
That kept the first version focused enough to build and validate properly.
Next: Building the MVP
Once the AS-IS and TO-BE processes were clear, I moved into implementation.
For the working prototype, I used:
Google Forms → Google Sheets → Make → Historical Issue Retrieval → AI Matching → JSON → Tracker Update
In Part 3, I’ll break down how I translated this process design into a working MVP, including:
- the issue submission form;
- the operational tracker;
- the historical incident dataset;
- retrieval logic;
- AI-assisted semantic matching;
- structured output;
- and writing the results back into the same issue record.
Closing the Loop — Portfolio Series
Part 1 — The Process Problem
Why support resolutions often fail to become reusable knowledge
Part 2 — AS-IS to TO-BE
Redesigning the support resolution process
Part 3 — Building the Working MVP
From issue submission to historical resolution matching
Part 4 — Validation, Governance and Next Steps
Testing the workflow and extending the knowledge loop
For Medium, use these five topics:
Business Analysis · Process Improvement · Workflow Automation · Artificial Intelligence · Knowledge Management
