What most people came for got the least space on screen
Support grew up inside Tinkoff Messenger, the bank's in-app messaging product (Tinkoff was T‑Bank's name before the 2024 rebrand). A single tab held the support chat, marketing bots, person-to-person chats between customers, representatives who visit customers to deliver cards and sign documents, the relationship manager and second-line requests all at once.
Over time, customer behavior and the structure of the product drifted apart.
71% of tab users opened the support chat. 65% came to read a message from support. 31% used search inside support.
Meanwhile, in an average session marketing and person-to-person chats took up around 75% of the screen — use cases that 7.8% and 1.6% of the bank's monthly mobile app audience used respectively.
In practice we were optimizing the interface around the mechanics of a messenger, even though getting help had already become its main job.
We had to reduce customer effort and cost to serve at the same time
The Support Center strategy came down to a simple goal:
The customer solves their problem with minimum effort, in the format that suits them.
That did not mean making the chat as prominent as possible and funneling everyone into it.
Some problems are faster to solve by phone. Others are easier to handle in writing, with documents attached. Some questions can be closed without a person at all. And when a person is needed, quality and cost depend on who steps in and through which channel: a bot, first-line support, a specialist or a representative visiting in person.
So a good Support Center had to be all of these at once:
- convenient — let people use the channel that fits them;
- simple — show only the actions that are relevant right now;
- informative — explain what is happening with the problem;
- within reach — make digital help as good as walking into a branch.
The business case ran the same logic in reverse. The fewer interactions a question takes, the less handling time they consume and the more questions customers can close on their own, the cheaper it becomes to serve them.
That produced a key constraint for the project:
Reduce the cost of support without passing those savings on as extra effort for the customer.
Quality could not degrade in the process: CSAT had to stay high, channel SLAs had to hold, and the load on relationship managers serving high-value clients could not grow.
Both initial options kept the same underlying premise
When the Support Center working group formed in July 2024, two options were on the table.
The first kept the messenger and made support more prominent inside it.
The second turned the entry point into a hub screen with categories, canned answers and several channels.
I argued against both.
They looked different, but they asked the same thing of the customer: first understand how the service is organized, pick the right path, and only then start solving the problem.
By then I had spent more than two years growing the messenger itself. Changing the premise meant walking away from the next chapter of a product I had helped build.
The core design question became a different one:
Why make the customer choose a chat or a department at all, when they came here for help?
I proposed a third model — start from the problem, not the bank's structure
Research confirmed that support was the tab's main use case. It did not say that a single chat was necessarily the right answer.
That was a design hypothesis.
I put together an alternative concept where the customer landed straight in the main support chat, skipping both the list of chat threads and the help catalog.
They could simply describe the problem.
Calls, the representative, the relationship manager and existing requests did not disappear — they showed up alongside, in the right context.
Automation stayed inside the flow too. The bot could resolve a question on its own or route it onward, without becoming a mandatory barrier on the way to a person.
I designed around 80% of the first concept myself. We took it through several rounds of discussion with the working group and the business. After each meeting we refined the model and came back with a new iteration.
Arguing about taste was pointless, so I defended the concept with a metric the business owned itself. The metric that mattered was customer effort — chat prominence was never the point. A hub with categories added a step before the problem got solved; a single chat removed it. The simpler model hit the business goal more precisely than either of the originals, and gave a better experience at the same time.
Defending the concept took a series of difficult meetings with the customer service organization, the team that owns the bank's core interfaces, and the design team. In the end the third option was accepted as the basis for the Support Center.
A single chat turned out to be only the beginning
If you build a product around the customer's problem, changing the main screen is not enough.
The whole journey had to be rebuilt — from the moment the customer realizes they need help to the moment the problem is solved.
Help people pick the most effective path
Chat and calling sat side by side.
The customer could use whichever format suited their situation, and the service could move them to the channel where the question gets resolved faster or better.
On entry, a single top suggestion surfaced the most likely question and let people start solving it right away.
Don't make customers learn how support works behind the scenes
The bot, first-line support and a specialist team may be different parts of the operational process. For the customer it is one problem.
Handovers between them should happen inside the service, without forcing anyone to find a new chat or explain the context again.
Show what happens after a request is filed
When a question could not be solved right away and went to second line, the customer saw a progress tracker: the current stage, its status and an explanation of what was going on.
Before it existed, questions like "when will you fix it?" and "can it be faster?" generated around 100,000 repeat contacts a month.
In a separate experiment, the tracker cut those by roughly 8% against a 3.8% target, and the savings came in 60% above expectations.
SIDE STORY — VOICE MESSAGES
Voice messages started as a standalone messenger feature. For customers it was a natural way to communicate, but the feature had no obvious direct business effect, so we could not get its launch approved for more than a year.
At some point I took the negotiations on myself, brought several CPOs to a shared position and personally drove the agreement through to launch. This is not the central line of the Support Center, but it is an important part of my role: a finished interface solution became a product only after I took it through a standoff between competing interests myself.
Marketing turned a service channel into a source of frustration
In the old tab, marketing bots sat next to support, and promotional offers could appear right inside the service conversation.
For some business lines this was an effective communication and sales channel. For the customer, the line between help and promotion had all but disappeared: in the same space where they were waiting for a problem to be solved, the bank kept sending offers.
Customers complained about ads in chats on a regular basis. The volume and consistency of that feedback showed this went beyond a few badly targeted messages — the boundary of the service channel itself had been broken.
Support had to be separated from the bank's own communications
Together with product, we locked in a principle:
A service channel should not compete with the bank's other communications for the customer's attention.
"Clean support" required change at two levels: removing unrelated chats from the help space, and no longer using the main chat for outbound messages that had nothing to do with the request at hand.
The decision separated different user intents. It was never about removing marketing: the bank's communications kept their value, they just could no longer disguise themselves as help or block the customer from continuing a service flow.
My role was to fix this boundary in the concept and defend it from the customer experience side.
This migration is not finished. As of August 2026 the target model runs for part of the audience, and negotiations about moving the remaining marketing communications continue. The change touches many product teams, business processes and a channel that matters to the bank, so "clean support" here is a transition already underway that the team is still seeing through, rather than a finished win.
One principle did not mean one interface for everyone
We designed the first model for the mass-market segment, where a shared support chat was the natural main entry point.
For Premium and Private the situation was different.
There the relationship manager was a value driver in their own right, with a CSAT of around 4.9 out of 5.
They are also a real person with working hours and weekends, rather than a 24/7 channel. Many clients build a close relationship with them and discuss things that should not be mixed into general support correspondence. Collapsing them and support into one chat would have cost the privacy of that conversation and left clients without a clear way into help outside the manager's schedule.
So we kept the shared principle — fast, clear access to help — and dropped the requirement to implement it identically across segments.
In the mass-market segment, a single chat became the main entry. In Premium and Private several separate service threads remained, but unrelated use cases stopped defining the structure of support.
The experiment had to test the project's central trade-off
In April 2025 we launched the new experience in the mass-market segment.
1.74 million customers were split evenly between control and test. The sample took two months to accrue, and we observed the result for another month.
The question we cared about was never "is the new screen better".
We wanted to know whether we could make getting help simpler without damaging service quality or unit economics.
The answer came back different from what we expected.
Each individual contact became more efficient. But people started contacting us more often
At the level of a single interaction the model moved in the expected direction: customer effort fell by 1.85%, handling time per chat by 1.71%, and chat automation rose by 1.68%.
At the same time, the Support Center made help both more visible and easier to start. Chats per customer went up by 9.59%, and chats involving a human by 7.52%.
That gap changed the whole picture. People needed less time per chat, but there were more chats. Per customer, total effort, handling time and cost to serve all went up. CSAT did not drop significantly.
That was the main result of the experiment.
We had not made support less efficient. We had lowered the barrier to it and seen the volume of demand that a complicated entry point used to hide.
This interpretation has a limit, and I want to state it plainly. The mix of requests changed along with the barrier: once writing in became easier, simpler questions started coming to support, and those take less effort by their nature. We cannot separate the interface's contribution from the contribution of the changed mix in this data. But both parts support the same conclusion: the complicated entry point was hidden demand, not efficiency.
We decided not to bring the old barriers back
After the experiment we could have restored part of the old logic and made contacting support harder again. That would have helped the economics and contradicted the entire point of the Support Center.
Together with product and the business we decided to keep the new model and rolled it out to the whole mass-market segment — knowing by then that cost to serve had gone up.
I represented the design position: making help accessible cannot be treated as a mistake just because more people started asking for help once it improved.
The product's next task was a different one: bring down the cost of servicing itself, instead of saving money through a difficult way in.
At the same time, we did not defend the first concept at any cost.
We adapted the model for Premium and Private, and continued separating support from unrelated communications as its own migration.
The interface stopped being where our work ended
Before the Support Center, chat designers mostly worked with the messenger as a platform: designing screens, states, components and the familiar features of a messaging product.
When I gathered the design team around customer support, we kept owning the interface but stopped treating it as the boundary of the customer experience. We started looking wider: what support staff write and in what tone, how the bot replies, which procedures it walks the customer through, what actions it offers, what happens when a question is handed between lines, and whether the customer understands what is going on with their problem right now.
We did not take these areas away from the teams that owned them. When we found a gap in the experience, we articulated the problem and went to its owners to look for a solution together.
That shifted the team's design direction from "build a convenient chat interface" to "make the whole problem-solving experience coherent". The decision outlived the project itself: the team still works this way.
My role
I joined the project as Design Lead, accountable for final design decisions, and ran it from shaping the concept to the mass launch.
What I owned:
- formed the design position on the two initial options and proposed a third product model;
- designed the bulk of the first concept and translated strategic principles into the customer-facing interface;
- set the design direction once two more designers joined, and widened the team's focus from the interface to customer service as a whole;
- represented the customer experience position in discussions with the working group, the business and senior leadership;
- fixed the boundary between the service and marketing channels in the concept, and kept defending it through the unfinished migration;
- personally secured approval for the voice messages launch with several CPOs, after a year of unsuccessful attempts by the team;
- made the key calls on behalf of design and adapted the model once real data came in.
The choice of target model, the experiment, the launch and the major business trade-offs were team decisions.
The Support Center changed more than the tab's interface.
Support stopped being one of the chats inside a messenger and became a product in its own right, where the interface, the channel and the bank's internal structure adapt to the customer's problem — instead of the other way around.
But the Support Center was not the end point. It simplified access to an existing service model, and the next stage called for rethinking the way the interaction itself works: giving the customer a convenient channel, but also understanding their intent, preserving context and helping them get all the way to a result.
That grew into the next direction — AI-native Support, where search, support and AI come together into a single way of interacting with the bank.