Customer problem
Something is not working.
A prescription did not process, a claim rejected, an order was delayed, information does not match, or a customer received an unexpected result.
Analyst + Engineering Mindset
Where customer service meets analysis, systems, and software.
My work as a Customer Service Advocate is more than answering questions. Every interaction requires me to investigate problems, analyze information, identify patterns, navigate complex systems, evaluate processes, and determine the right next step.
The connection
Customer service taught me how systems behave in the real world.
Working directly with customers has given me something I could not learn from technology alone: a view of what happens when systems, processes, policies, and people meet.
Investigation
What actually happened?
I gather information, review available details, compare what should have happened with what actually happened, and identify where the situation changed.
System thinking
What is connected to the problem?
I think about the relationship between the customer, prescription, claim, pharmacy, benefit rules, workflow, documentation, and the systems involved.
Resolution
What needs to happen next?
I identify the next actionable step, explain it clearly, document the situation, and help move the issue toward resolution.
Pattern recognition
Is this an isolated problem?
When similar problems appear repeatedly, I become interested in the larger pattern: where the workflow creates confusion, where information is missing, or where a process may be creating unnecessary friction.
Improvement
How could this work better?
This is where my curiosity moves beyond the individual interaction. I start thinking about better processes, clearer information, system improvements, and eventually technology that could prevent recurring problems.
How I think like an analyst
I do not want to stop at the answer. I want to understand the reason.
My current role constantly puts me in situations where I need to investigate information, connect details, identify barriers, and determine what should happen next.
Analyst Thinking 01
I break complex problems into smaller pieces.
A customer may describe one large problem, but the actual cause may involve several smaller issues.
I have learned to separate the situation into pieces: what the customer expected, what the system shows, what happened previously, what information is missing, and what rule or process may be affecting the outcome.
That same habit of breaking a complex problem into smaller, understandable components is something I want to continue developing through business analysis, quality analysis, and software engineering.
Analyst Thinking 02
I compare expected behavior with actual behavior.
One of the most useful questions I have learned to ask is: What should have happened?
Then I compare that expectation with what actually happened. A prescription should process one way, but the claim may produce a different result. An order should follow one path, but something may have interrupted the workflow.
That difference between expected and actual behavior is often where the investigation begins.
Analyst Thinking 03
I look for patterns instead of treating every problem as isolated.
When I encounter similar customer problems repeatedly, I naturally start asking whether there is a larger pattern.
Is the same step confusing multiple people? Is information consistently missing? Is a workflow creating repeated handoffs? Are customers asking the same question because something is unclear?
That curiosity is what draws me toward analysis and continuous improvement.
Analyst Thinking 04
I think about the person affected by the process.
My customer service background gives me a perspective I want to carry into technical work: systems are experienced by people.
A technically correct solution can still create frustration if the workflow is confusing, the information is difficult to understand, or the user does not know what to do next.
Understanding the customer helps me think about usability, communication, requirements, and the real-world effect of a system.
How I am developing an engineering mindset
The questions are becoming more technical.
Customer service showed me the problems. Analysis is teaching me how to understand them. Software engineering is where I want to develop the technical ability to build solutions.
Understand Before Building
I want to understand the problem before jumping into a solution. What is the requirement? Who is affected? What constraints exist? What should the system accomplish?
- Problem definition
- Requirements thinking
- User perspective
Trace the Logic
When something produces an unexpected result, I want to understand the path that led there. That means thinking about inputs, rules, dependencies, processes, outputs, and where something may have changed.
- Workflow thinking
- System dependencies
- Root-cause investigation
Test the Solution
I am developing the habit of asking whether a solution actually works, whether it handles unexpected situations, and whether the result matches the original requirement.
- Testing mindset
- Validation
- Edge-case thinking
Build for the User
My customer service experience keeps the human side of technology visible. I want to build solutions that are not only functional, but understandable, useful, and grounded in real user needs.
- Usability
- Accessibility
- User-centered thinking
The transition
I am not leaving my customer service experience behind. I am building on it.
My current role gives me the foundation. My next roles will allow me to apply that way of thinking at a deeper level.
Today
Customer Service Advocate
- Investigate customer problems
- Navigate complex systems
- Interpret information and processes
- Identify barriers
- Document issues
- Communicate solutions
Next
Analyst / Quality Analyst
- Analyze processes and data
- Identify recurring patterns
- Investigate root causes
- Document requirements
- Test and validate changes
- Recommend process improvements
Long term
Software Engineer
- Translate problems into technical requirements
- Design and build solutions
- Write and test code
- Debug system behavior
- Improve reliability and usability
- Build technology around real needs
The connection I want to carry forward
Listen to the problem. Understand the system. Find the pattern. Build the solution.
Customer service taught me how to listen to people and understand problems from the user's perspective. Analysis is helping me learn how to investigate those problems systematically. Software engineering is the technical direction I am building toward so I can eventually turn that understanding into solutions.
The bigger picture
Different role. Same problem-solving mindset.
I am building from the experience I already have: understanding customers, investigating problems, navigating systems, recognizing patterns, and looking for better ways to work.