Ownership & Task Lifecycle Redesign
Tinkoff Bank
Ownership redesign
Ownership redesign
Role: Product - UX Designer | Channels: chat, telephony | Constraints: SLA stability, RBAC, auditability
350+
Migrating service lines to a secure in‑house
CRM - without SLA regression
Migrating service lines to a secure in‑house
CRM - without SLA regression
4.8
Internal operator CSAT
3.5 → 4.8 (survey)
3.5 → 4.8 (survey)
+500k
Monthly customers
that CRM platform serves
Monthly customers
that CRM platform serves
High volume, strict SLA, minimal data exposure
Premium
Complex cases, frequent follow‑ups, ownership clarity needed
High-touch, fewer handoffs, higher trust expectations
Back‑Office
Regulated ops, async work, structured tasks + audit trail
Stakeholder Map — Internal CRM Migration
Why this mattered: multiple roles + strict verification.
Design requirement: role-aware workflows + auditable actions without SLA regression.
My move: mapped ownership/dependencies early to prevent blind spots in rollout.
How to read: closer layers touch day‑to‑day workflows more directly; outer layers constrain or enable the system.
Dependency matrices to align ownership early and unblock rollout.
How I worked — Phase 1
Understand the operation (AS‑IS)
What I designed
New “Task Mode”
Deferred work
Why this segmentation mattered
or break back‑office security.
Design principle: role-specific workflows with shared objects (case/task/queue) and strict permission boundaries.
Permissions shaped the UX. I defined a role corridor (what each group can see/do) and turned it into UI rules: role+state gating and “why blocked / what next”.
Before Task Mode: what work looked like
Follow‑ups lived outside the CRM, ownership broke across shifts, and supervisors policed manually — creating blind spots and security risk
Initial framing
Technical CRM migration with strict security constraints
Success = no SLA regression during rollout
Success = no SLA regression during rollout
Discovery
SLA risk was driven by hidden ACW & fragmented ownership
Critical work happened outside an auditable system
ACW wasn’t “extra time” — it was a missing system object that made Tasks first‑class
Critical work happened outside an auditable system
ACW wasn’t “extra time” — it was a missing system object that made Tasks first‑class
But the real problem…
Hidden after-call work lived outside the CRM, so ownership broke across shifts.
Core insight
ACW was not extra time — it was missing system logic for tracked follow-ups.
Make follow-ups first-class work through Task Mode.
What it required
A shared task object, task lifecycle, role-aware permissions, and decision-table rules.
What I decided
to build
Shared Task object
owner, queue, states, audit log
Deferred Task lifecycle
with SLA-aware routing
with SLA-aware routing
Decision tables
single policy source for UI/BE/QA
Explainability
at every blocked decision point
Hypotheses
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.
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.
How I worked — Phase 2Turning discovery into the interaction model (TO-BE)
The goal was to make follow‑up reliable: a stateful task lifecycle with explicit ownership, predictable routing, and auditable actions.
Approach: domain model → lifecycle states → decision rules → lo‑fi validation → implementation alignment.
I translated the lifecycle into interface flows to validate the agent experience before visual polish.
System operating model: 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
Deferred tasks live in
Task Mode (instead of post‑call time)
Task Mode (instead of post‑call time)
Instead of exposing raw tables, I showed how policy becomes visible interaction: what is allowed, what is blocked, and what happens next.
Task Mode is stateful: actions depend on role × task state × verification × timing.
Ownership handoffs are auditable (who → where → why), so work stays in the system instead of chat.
NEW “TASK MODE” prototype
auto‑assigned tasks, state‑aware actions, and auditable routing
— designed to keep follow‑ups reliable across shifts.
— designed to keep follow‑ups reliable across shifts.
Shipped baseline: tasks surface automatically (auto‑assigned), actions are state‑aware, and every transition writes to the audit log.
This is the baseline I took into Phase 3 pilot for validation and iteration.
What’s the result
Tasks became first‑class objects (not notes).
Ownership stayed continuous across shifts.
Two due dates separated customer promise vs internal processing.
Exceptions routed through Supervisor / On‑call with audit visibility.
Ownership stayed continuous across shifts.
Two due dates separated customer promise vs internal processing.
Exceptions routed through Supervisor / On‑call with audit visibility.
How I worked — Phase 3
The goal was reliability under real shift constraints: ownership continuity, due-date correctness, and safe escalation to Supervisor / On-call.
Validated: ownership transfers • two due dates • late-shift routing • exception handling under load
Auto-assigned tasks surfaced late in the shift and landed on agents about to go offline.
Ownership broke across shifts, tasks went overdue, and manual reroutes created avoidable SLA risk.
Telephony load
Instant auto-answer forced abrupt context switching for chat + call agents, increasing missed steps during peak load.
If a complex task is auto-assigned after 21:30, re-queue it to the next-shift queue (with logged ownership transfer).
Telephony feature
Added a 5-second auto-answer delay and a softer alert tone to give agents a short prep window before the call starts.
To validate the operating model under load, I ran task-based think-aloud pilot sessions during rollout waves.
Below are the key outcomes and feedbacks
Below are the key outcomes and feedbacks
The screens below are public reference views of that environment, shown to make the operational context visible.
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 and escalating exceptions with a logged reason.
So I redesigned standard form of feedback into a structured stream intake with standard fields and auto‑captured context →
triage board for deduplication/merge • convert to owned tasks (including automation to handle volume).
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.
The Human Side of Scale
The hardest part for me
Were 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.
What I loved most
The human side: support feedback, cross-team conversations, and the chance to act not only as a designer, but also as a listener and translator between teams.