Ownership & Task Lifecycle Redesign
Tinkoff Bank
Ownership redesign
Ownership redesign
A year‑long migration from legacy Siebel to a secure in‑house CRM, where I redesigned hidden post‑call work into an explicit Task life ails.
Role: Interaction UX Designer | Channels: chat, telephony | Constraints: SLA stability, RBAC, auditability
350+
Migrating supports to a secure in‑house
CRM - without SLA regression
Migrating supports to a secure in‑house
CRM - without SLA regression
4.8
Internal operator CSAT
3.5 → 4.8 (survey)
Internal operator CSAT
3.5 → 4.8 (survey)
+500k
Monthly customers
that CRM platform serves
Monthly customers
that CRM platform serves
My role & approach
Users
Problems
Insights
Solution
Lo-Fi Wireframes
Results
High‑volume first-line service for standard requests. Fast
resolution, strict SLA, minimal required data exposure.
Premium support
second-line support for higher‑value clients with more complex
requests. Needs clearer ownership and safe follow‑ups.
Highest‑value clients expecting a white‑glove experience
(proactive follow‑up, fewer handoffs, higher trust).
Back‑Office specialists
Specialists who complete deeper operations asynchronously
(document/account processing, approvals). They rely on
structured tasks, due dates, and clear context.
Click any image to enlarge
The support organization ran multiple service lines with different permissions and identity‑verification requirements.
Migration required role‑aware workflows, strict access control, and an auditable trail for sensitive actions, while maintaining SLA stability through rollout waves. I mapped stakeholders and dependency owners early to prevent blind spots and to align rollout responsibilities.
Involvement & blockers matrices included to show cross‑functional dependency surface during migration
How I worked — Phase 1
Understand the operation (AS‑IS)
What I designed
New “Task Mode”
Deferred work
Why this segmentation mattered
The solution required role-specific workflows with shared system objects (case/task/queue) and strict permission boundaries.
I used role models and a permission corridor to define what each group can see, do and turned those constraints into interaction rules (role and state gating, explainability for blocked actions).
Scroll to see other roles (Frontline / Back office / …)
Before Task Mode: what work looked like
Why it mattered: (1) security risk from unnecessary data exposure, (2) operational blind spots with lost follow‑ups, and (3) motivation & fairness issues caused by manual monitoring and late‑shift overload.
The challenge looked like a migration readiness problem: prioritize capabilities, coordinate teams, and ship safely.
But the real problem…
So the solution wasn’t to improve “post-call mode” — it was to replace it with a new “Task Mode”, a first-class operating environment where follow-ups surface as owned work instead of being tracked manually.
So the migration required a scalable interaction system: task object, lifecycle, policy layer
What I decided
to build
(owner, queue, states, audit log)
Deferred Task lifecycle
with SLA-aware routing
as the single policy source for UI/BE/QA
Explainability
at every blocked decision point
Hypotheses
and how I validated it
H1 Ownership
If ownership is explicit (Task and owner),
handoffs will drop and supervisors won’t need manual policing.
If routing rules are encoded as decision tables,
handling becomes consistent across teams.
H3 ExplainabilityIf blocked states explain why and what to do next,
users are less likely to create unsafe workarounds.
The AS-IS analysis showed that post-call work was treated as time, not as a system object.
Phase 2 focused on converting that gap into an enforceable lifecycle model.
How I worked — Phase 2Design the interaction model (TO-BE)
I modeled the domain (Request/Task/Owner/Queue/State), defined lifecycle states and transitions, and translated tribal rules into decision tables shared by UI/BE/QA. I validated the core mechanics in lo‑fi walkthroughs before final implementation details.
Design the interaction model (TO‑BE). I redesigned system logic before UI:
domain model → lifecycle states → decision rules → lo‑fi validation → implementation alignment.
Once the system rules were defined, I expressed them at interface level to validate how agents would experience the change
Click any image to enlarge
Then, I mapped the operating model at system level: where verification happens, how requests become tasks, and how exceptions escalate to Supervisor / On‑call with audit visibility.
Lo-Fi Wireframes
validating mechanics before visual polish
Finnaly, the deferred follow‑ups became a structured lifecycle with identity gates, explicit ownership, two due dates (customer due date, internal processing date), and predictable escalation paths.
Low-fidelity prototypes validated task surfacing, state gating, escalation paths, and explainability before final UI implementation. The goal here is not visual polish, but to validate that the interaction model works under real operational constraints
Deferred tasks are one workflow type
Task Mode is the environment
where this work lives (instead of post‑call time)
Task Mode is the environment
where this work lives (instead of post‑call time)
- desided whether to defer
- create the deferred task
- execute at due time
To remove ambiguity, I translated informal rules into decision tables
and mapped each rule to expected UI behavior (why blocked / what next).
Click any image to enlarge
NEW “TASK MODE” prototype
Translates policy into interaction: auto-assigned tasks, state-aware actions, and auditable routing.
The shipped baseline: tasks surface automatically (auto‑assigned), actions are state‑aware, and every step is auditable. This “as implemented” baseline is what I took into pilot for Phase 3 validation and iteration.
Click any image to enlarge
What’s the result
Task became a first-class object (not a note)
Ownership is continuous across shifts
Two due dates enforce customer promise vs internal processing
Exceptions route through Supervisor / On-call with audit visibility
Ownership is continuous across shifts
Two due dates enforce customer promise vs internal processing
Exceptions route through Supervisor / On-call with audit visibility
How I worked — Phase 3
auto-assigned tasks that surfaced late in the shift still landed on agents who were about to go offline. Ownership broke across shifts, and tasks were being rerouted manually or simply left untouched until the next day, becoming overdue and creating avoidable SLA risk.
Telephony load
instant auto‑answer created abrupt context switching for chat + call agents, increasing missed steps and stress during peak load.
if a complex task surfaces in Task Mode after 21:30 (auto-assigned),
it is re-queued to the next shift queue
Telephony feature
added a 5-second telephony auto-answer delay and a softer alert tone
to reduce abrupt context switching
I used task‑based pilot sessions (think‑aloud) to validate the operating model under load. Below is an excerpt of the pilot script focused on ownership continuity, due dates correctness, and exception safety rather than “happy path” completion alone.
Pilot test script
- Complete an auto-assigned task end-to-end without using chat as a tracker
- Create a deferred task with two due dates and required context
- Escalate to Supervisor / On-call with an auditable reason
- Handle a task surfacing in Task Mode after 21:30 correctly
- Resolve a case while switching between chat and telephony
and standardized operating rules so support agents could work confidently under load. Training focused on the few behaviors that prevented most failures: working inside Task Mode (no “status in chat”), correctly setting two due dates, and escalating exceptions to Supervisor/ On‑call with a logged reason.
So I redesigned standard form of feedback into a structured streamintake with standard fields and auto‑captured context → triage board for deduplication/merge → convert to owned tasks (including automation to handle volume).
I reinforced quality through incentives: actionable feedback taken into work earned KPI credit in the internal portal (important for annual accreditation), increasing participatory reporting and reducing clarification loops.
Reinforced quality through incentives:
actionable feedback taken into work earned KPI credit in the internal portal (important for annual accreditation),
increasing participatory reporting and reducing clarification loops.
I redesigned the workflow: mapped end‑to‑end service flows, defined roles and permissions, and structured follow‑ups as deferred tasks. Task Mode replaced post‑call coordination with an execution environment built for ownership.
I scaled through six new procedures, iterated on pilot failures (late‑shift routing, telephony load), and drove adoption with training and a feedback pipeline that converted operator input into actionable work.
Keep ownership continuous across roles and shifts → clear ownership and predictable escalation to Supervisor / On‑call.
Make it intuitive for support agents → designed for real workflows under load, reinforced with procedures and training.
- structured tasks, clear ownership reduce coordination overhead and improve reliability.
- explicit roles/permissions make the system safer and easier to operate.
Adjusted after pilot
- auto‑assignment needed shift-boundary logic → late‑shift re‑queue rule.
- instant telephony auto‑answer increased stress → short delay and softer alert.
Adoption check
people don’t switch tools automatically → I reduced friction and improved signal quality with a structured feedback flow, automation, and incentives.
The Human Side of Scale
— it was the scale and the responsibility
What was hardest for me was the mix of tight timelines and high responsibility. I remember the pilot day clearly: about 200 supports agents were trying the new flow live with real customers, and I stayed on call because I knew I might need to react quickly. It was intense, but it also made the work feel very real and it pushed me to design and iterate with a lot of care.
— was the emotional side of the project
The excited feedback from supports, meeting so many people across roles, and getting to work not only as a designer, but as a listener, a facilitator, and a translator between teams, someone who helps make complex systems feel workable.
I also genuinely enjoy building things from scratch and bringing order to ambiguity, turning messy reality into something structured people can trust. And honestly, it was fun !! I was in constant conversation with the teams, and that energy made the work feel very real.
That’s the part of this job I care about: understanding how people actually work, what stresses them, what helps them feel in control and then building products that respect that reality.
Prototypes
Validation
Res