Workflow builder

Context

Tinkoff is a fully online, branch-free financial ecosystem offering banking, investment, and lifestyle services through a single digital platform. Customer support is a massive operational effort, requiring highly optimized workflows to handle millions of customer interactions daily across multiple channels (calls, chats, in-app support).

What is workflow

A client loses their card and messages support.

For them it’s a quick chat.

For the operator, it’s juggling several conversations while checking accounts, recent activity and internal systems. A workflow is a built-in script that guides the operator through resolving a request: they type a keyword, the system pulls up the right steps. It speeds things up while leaving room for judgement.

Challenge

At first, we used a third-party tool to guide support agents through step-by-step workflows. But it wasn’t built for our level of complexity. Agents had to jump between screens, copy-paste data into separate admin systems, and repeat actions manually. Support was slow, inconsistent and expensive to scale. We needed something that integrated with 10+ internal systems, met the bank's security rules and lived inside our existing tools. So we built our own.

Starting point

An early version of the Workflow Builder let methodologists (support specialists trained to design procedures) build workflows visually instead of going through developers. In theory.

In practice, when I joined, the tool was barely functional: it supported 200–300 workflows, took weeks to learn, and most serious flows were still built manually.

Metrics & objectives

Before this project, the numbers looked like this: methodologists needed around two weeks to learn the tool, auditing a single workflow took up to three days, and releases depended on developer availability.

Our objectives: let non-technical staff build workflows independently, cut release and audit time, and bring down request handling times across calls and chats.

I started with research

I went to the floor and watched methodologists work. 3 pain points came up in nearly every session:

– Unintuitive UI. The early version was developer-first: setting up a workflow required understanding logic that had nothing to do with the support process itself.

– Slow release cycles. There was no built-in verification. Every approval was manual, and every release waited on someone's calendar.

– No feedback loops. Once a workflow shipped, nobody could see how it performed or where it needed fixing.

Prioritizing features using Kano Model

To kick off the work effectively, I conducted research, prioritized the backlog using the Kano model, and presented the results to the team.

Started with obvious improvements

I started with the basics: visual order, predictability, and trust. I cleaned up the interface using foundational UX laws like Jakob’s Law (keep it familiar) and Aesthetic-Usability Effect (make it feel smooth and reliable).

We were using PlumbJS for drag-and-drop editing, but interactions were buggy. I partnered closely with engineers to improve visual consistency and interaction feedback, fixing edge snapping, improving latency, and tightening layout logic.

It fixed basics and laid the foundation for everything that followed.

Added console for management errors

After shipping core improvements, I prioritized high-impact UX pain points.

One was error validation: before launching a workflow, users needed to test it, but errors were shown in generic pop-ups with no link to the faulty block. Debugging meant hunting.

I redesigned it as a console-style error log, borrowed from dev tools, that highlighted the exact block and message. Validation time dropped 3x, and power users finally felt in control.

Removed audit frictions

As the number of workflows and updates grew, reviewing them became a pain. Reviewers had to re-check everything, even if only 5% changed, because the only way to compare versions was two open windows. Some authors left notes for reviewers in Slack, some didn’t. It was messy, slow, and error-prone.

I designed a visual diff that greyed out unchanged blocks and highlighted updates, combined with version control and approval tracking. Review went from days to hours, with fewer errors and more confidence in every release.

Implemented 19 other features from user’s feedback

There were plenty of other updates: variable paths, sub-workflows, unused variable, version clean-up, comments, mentions and more.

Each should be a standalone case. What matters for me, teams and the company: we shipped everything from must-be and performance backlog backets, solved real pains, and empowered teams to move fast without breaking things.

Conducted bi-weekly field UX tests

I ran bi-weekly field UX tests: real tasks, think-aloud format, actual users (methodologists). We sat in the same building as every user of the product, which made the iteration loop delightful fast: I could watch a fix land on Tuesday and see it change someone's workday by Thursday. Watching the core of the bank being built on top of something I designed is still one of my favourite memories in this job!

Result

Scalability: Workflow usage grew from 200+ to 3,000+, covering all major support cases.

Speed: Release time dropped from 4 days to 1 — a 75% reduction, so business changes reached operators in a day instead of a week. Methodologists training time fell from 7 days to 3.

Service efficiency: call handling time dropped by 20.6%, chat handling time by 41.7%.

Cost: Eliminating developer dependency for workflow changes saved millions of rubles in operational expenses.

This platform was part of the work behind Tinkoff being named Most Innovative Digital Bank in Central and Eastern Europe at the 2021 World's Best Digital Bank Awards.

Takeaways

Simplification isn't dumbing down. My users were methodologists who knew the support processes better than anyone in the building. Hiding complexity from them would have made the tool useless; the job was sequencing it: surfacing the right logic at the right moment. Designing for non-technical experts is harder than designing for either novices or engineers.

The Kano workshop's real output was consensus. 23 features, every stakeholder in one room, one shared picture. We never argued about high-lvl priorities for this projects since then, and that bought more velocity than any single feature we shipped.

Sitting in the same room as your users is a real advantage. Bi-weekly field tests with people two floors away gave me an iteration speed I've been chasing ever since. If I could design the conditions of a project before the project itself, this is the one I'd pick.