Case 02 · 2024
From Fragmented Requests to Digital Service Workflows
Digitalizing internal services with Enterprise Service Management
Transforming operational services into structured digital workflows.
- Request
- Validate
- Approve
- Fulfil
- Close
- Feedback
At a glance
- Context
- Enterprise internal services moving to a central service-management platform
- Timeframe
- Feb – Dec 2024
- Role
- Business Analyst
- UX Champion
- Service Transformation Contributor
- Status
- Selected services went live in December 2024
The challenge
The challenge was not simply implementing software.
Technical engineering services relied on fragmented requests, inconsistent communication channels and varying interpretations of the process. Customers needed significant effort to understand how to request a service and follow its progress, and existing workflows were hard to scale and lacked a consistent service experience.
An organization-wide initiative aimed to give customers a single entry point to internal services through a structured service catalogue. For my service area, this meant that requests previously handled through different channels, systems and personal contacts had to become digital workflows.
Before anything could be digitized, the underlying processes had to be rethought — while balancing requester needs, the fulfilment side, approval logic and platform constraints.
- Understood
- Simplified
- Translated into digital logic
- Validated
- Improved
- Implemented
My role
I helped translate operational service activities into structured digital workflows on an enterprise service-management platform — through stakeholder interviews, requirement clarification, process mapping, workflow definition, UAT coordination, rollout readiness support and user documentation. The goal was not only digitalization, but a service experience that is easier to understand and use. The platform itself was owned by others; my focus was the service, process and user side.
Discovery & requirements
- Mapping existing processes
- Internal stakeholder interviews
- Finding simplification opportunities
Workflow & UX
- Supporting request, approval, fulfilment and closure logic
- Reviewing customer and agent journeys
- Identifying IA and navigation issues
Validation & rollout
- Planning and coordinating UAT
- Structuring feedback into recommendations
- Training support and step-by-step user guide
Provided expertise
- Process Discovery
- Business Analysis
- Requirements
- Process Simplification
- Service Design
- UAT
- Usability
- Implementation Support
- Change & Adoption
Glimpse of the process
A request-to-fulfilment logic built step by step — with simplification before translation.
- 01
Understand
Map existing processes, users and operational logic.
- 02
Simplify
Ask what is truly needed before digitizing a process.
- 03
Translate
Convert processes into a request-to-fulfilment workflow.
- 04
Validate
Coordinate several days of User Acceptance Testing.
- 05
Prioritize
Sort recommendations: implemented, platform limitation, workaround or future improvement.
- 06
Enable
Prepare step-by-step guidance for both requesters and service teams, covering access, submission, tracking and communication.
- 07
Roll out
Support selected services through go-live.
Service experience · Conceptual model
One service, two perspectives
Start
- Requester
- Understand the offer
- Service team
- Understand the need
Align
- Requester
- Clarify expectations
- Service team
- Confirm scope
Deliver
- Requester
- Stay informed
- Service team
- Coordinate the work
Close
- Requester
- Review the result
- Service team
- Complete the handover
Across the service: clear information · visible responsibilities · two-way communication
Key insights
What User Acceptance Testing revealed
UAT went beyond “does it work?” — it became a usability review from both the requester and the agent perspective.
Information overload
Long forms and scattered details made essential information hard to scan. Grouping related fields and removing nonessential clutter were recommended.
Information hierarchy
Information appeared differently across views. A consistent structure was needed so users could recognize the same request context throughout the service.
Discoverability
Mixed service types and unclear labels made it hard to choose the right entry point. Users also needed to recognize their requests without relying only on generated identifiers.
Workflow transparency
Similar request and task views obscured responsibilities and next steps. Clearer overviews, meaningful stage names and visible progress were recommended.
Customer ↔ agent communication
Testing exposed gaps in shared updates, attachment visibility and change tracking during ongoing work — particularly important for iterative services.
Realistic customer input
Some information could only be clarified later. Recommendations distinguished what was essential to start from what could be agreed as the work progressed.
UAT synthesis · Observations to recommendations
From friction to a clearer service experience
Observed friction
Long, inconsistent information layouts
Underlying need
Scan essential details quickly
Recommended direction
Group related information consistently
Observed friction
Mixed service types and unclear labels
Underlying need
Recognize the right service
Recommended direction
Differentiate entry points and use meaningful labels
Observed friction
Hard-to-distinguish requests and tasks
Underlying need
Understand context and next steps
Recommended direction
Clarify the overview, responsibilities and stage names
Observed friction
Limited visibility during ongoing work
Underlying need
Collaborate before completion
Recommended direction
Review shared updates, attachments and change visibility
Observed friction
Inputs requested before they were known
Underlying need
Provide what is realistic at each stage
Recommended direction
Distinguish essential inputs from later clarification
Recommendations from testing — not a claim that every change was implemented.
Key decisions
“Not every user need should automatically become a feature.”
After UAT, each recommendation was assessed and sorted into what could be implemented, what was a platform limitation, and what needed a workaround such as training or a future improvement.
Recommendation triage after UAT
Implemented
Changed within the platform
Platform limitation
Documented, not changeable
Workaround / future
Training now, improvement later
“Simplify first, then digitize.”
For a more complex service, I contributed to a leaner workflow proposal: retain meaningful alignment and approval points rather than turning every internal activity into a separate digital task. Feedback at completion was part of the proposed experience. This proposal was separate from the selected services that went live.
Constraints & trade-offs
Enterprise platforms come with fixed patterns and many dependencies.
Platform patterns
Some recommendations involved shared platform behaviour — including identifiers and request/task views — and required assessment beyond the service team's scope.
Process complexity
Long, iterative engineering work fit a ticket model less well than smaller transactional services.
Shared ownership
Platform, approval and fulfilment logic involved several teams and decision makers.
Outcome
Only documented outcomes are listed.
Implemented
- — Standardized request-to-fulfilment flow: selected services became structured, workflow-based services with clearer customer touchpoints and expectations (go-live Dec 2024)
- — Reduced process ambiguity: service definitions, requirements and interactions became more transparent for customers and internal service providers
- — Rollout support: coordinated UAT, prioritized recommendations and developed customer and agent documentation to support adoption
Not part of this go-live
- — The digitalization of the most complex engineering service remained on a separate track.
What this case demonstrates
Digital transformation succeeds when processes are not only automated, but redesigned around customer understanding, transparency and usability.