Cross-Sell Strategy Builder

The bank offers products to customers in its app, on its website, and in chats. Cross-sell strategies determine who sees which products, under what conditions, and in what order.

Each strategy was written in code. Analysts defined the rules, and engineers implemented them. This took weeks, and the team could not keep up with the business's needs.

The bank needed a service where analysts could create and modify strategies themselves. Behind that task was a complex system: dozens of products, numerous conditions, branching scenarios, and different ways to shape the final output.

I started by reviewing strategy requests: how long they took, who was involved, and where engineering support was needed. This helped me understand the existing process and the scale of the problem.

I then held five sessions with the engineering lead, product manager, and analysts. Together, we examined how the engine worked, what made up a strategy, and which scenarios it supported.

The core entities were predicates and nodes. Predicates check conditions, such as whether a customer meets specific criteria. Nodes define what happens next: which products to select, how to process them, and what result to return.

The complexity came from combining these elements. Conditions could be nested, scenarios could branch, and the result could depend on several processing steps.

In the first concept, I split setup into audience, conditions, and output. This explained the parts of a strategy and gave users a clear sequence to follow.

We reviewed the concept against real scenarios with the team. Some strategies needed more complex branching, and the predefined structure limited what the system could express.

For the second concept, I drew on the existing strategy visualizer. Analysts already knew how to read its graph, so a familiar layout could help them move from viewing strategies to building them.

Testing complex scenarios revealed a different limitation: this approach could not support the required depth of nesting.

These early drafts were used to test whether the concepts worked. They were deliberately rough, before detailed interface design.

In the third concept, I separated components by function and introduced nested branches. Users could combine elements freely and make a strategy more complex as needed.

We reviewed the concept against the required scenarios. It supported both simple sequences and deeply nested, branching strategies. With the approach validated, I moved on to detailed design.

The final design organizes the engine's capabilities into four node types: conditions, products, filters, and branches. Each has a specific role and its own settings.

The canvas shows the structure of the strategy. Detailed parameters open in the selected node's side panel, so users can edit the details while keeping the overall logic in view.

Checks are combined in a single node. Users select a condition, set its value, and combine checks using AND / OR / NOT.

More complex rules use nested groups. Simple and compound conditions follow the same interaction pattern, so users do not need to learn a new workflow as their strategy grows.

The product node defines what to offer the customer. Selection methods are grouped by type, from choosing specific products to selecting them by description.

Final output settings live in a separate node. Once the product set is formed, users specify how to filter it and in what order to present it.

Branches let users create alternative scenarios and nest one part of a strategy inside another. They can start with a simple structure and add branches as needed.

I designed connection points and rules to prevent invalid links. A consistent left-to-right direction makes strategies easier to read, while the canvas shows their branching and nesting.

The strategy users built on the canvas had to match what the engine would execute.

Together with engineering, I worked out how to convert the graph to JSON and back. For each node, I documented its contents and the corresponding engine component. This map guided implementation and helped us verify the builder's logic.

I designed the full strategy creation workflow: adding and connecting nodes, configuring parameters, validating, saving, and publishing.

These actions form a single process. Analysts can build a strategy, change its logic, and prepare it for launch in one interface.

After launch, we held two user workshops. The first weeks showed that building strategies independently was still challenging: some strategies were difficult even to describe before putting them on the canvas.

I wrote a guide based on simple examples and created a backlog of further improvements. The launch gave us a starting point for making the tool easier to learn.