Why in DARCA support is built as an action layer, not an answer layer
One of the weakest habits in digital products is treating support as complete the moment the user receives an answer. In practice, that is almost never enough. If a person has a problem, what they usually need is not text, but a result: send money, restore access, get a document, change a limit, resolve a disputed action, understand what to do next without walking through five screens and without re-explaining the context. And the more complex the financial product is, the more obvious it becomes that a regular “chat with tips” is a poor way to solve a real problem.
That is exactly why, in DARCA, we think about support not as a separate helpdesk, but as part of the control interface. For us, support is not a layer of advice sitting on top of the product. It is a layer of actions inside the product. The user should not receive an answer like “go to the menu,” “open this section,” or “find that button,” and then be left to reconstruct the route alone. Instead, inside the dialogue they get buttons and deep links that take them to the exact screen already in the right state. If they need to send money, the send-money flow opens. If they need a document, the document-generation flow opens. If they need to change a password, they do not land in generic settings - they land at the point where the action can actually be completed.
In my view, this is where the real line sits between “support as a communication channel” and support as action. In the first model, the operator or bot explains what to do. In the second, the product helps the user do it right now. That matters even more in financial scenarios, because the user’s problem rarely exists separately from the operation context. If the issue is about a transfer, a card, a document, or access, the best answer is often not an explanation. It is getting the user into the right action inside the same flow.
This changes the role of both the operator and the bot. In DARCA, they work within the same logic: not to describe the path, but to launch the path. The user presses a button and confirms the action, instead of manually navigating through screens, menus, and settings. That model turns support from an external service into part of the product UX. And to me, that is much closer to how good systems should solve problems in general: not by pushing navigation back onto the user, but by reducing the number of steps between the question and the result.
There is also a straightforward product reason this matters. The more complex the system, the more expensive every extra context switch becomes. In a simple app, maybe you can tolerate “go to settings and find this section.” In a financial product, that is already poor UX. The price of error is higher, user anxiety is higher, the need for clarity is higher, and sometimes the issue exists right inside a sensitive flow. So support that merely sends the user back into the interface maze does not actually solve the problem. It just adds another layer of friction.
For me, the conclusion is simple: support in a complex product should lead to an action, not to an instruction. The moment support starts working through buttons, deep links, and pre-configured screen states, it stops being “a chat with answers” and becomes part of the product architecture itself. And that is the moment when support starts actually reducing friction instead of politely explaining where it lives.
What feels like the more mature model for product support - telling the user what to do, or taking them directly to the action inside the product itself?
Top comments (0)