The company’s offering had changed. The way teams worked together hadn’t.

Moving from selling an established product to a broader platform proposition required more than new technology. Customers were increasingly being sold a larger vision: a platform capable of supporting more complex agreement workflows, automations and agentic use cases.

But internally, the methodology required to deliver that promise had not developed at the same pace. As the new VP leading the enterprise organisation put it:

“The promise makes sense, the methodology is missing.”

The consequences were appearing throughout the customer journey. Customer Success had historically been heavily focused on adoption and renewal.

“They're super transactional. They push conversation, push renewal.”

And conversations tended to stay close to the product itself:

“They talk a lot of feature function, they don't talk customer use case, customer design.”

That becomes increasingly problematic when what is being sold isn’t a single product with a relatively predictable implementation path. A platform sale requires teams to understand what a customer is actually trying to change through use of the platform, which workflows are involved, what outcome they expect and how different capabilities need to come together to produce it.

Without that context, adoption becomes much harder.

Customers were buying the platform before teams had agreed what value it should create

One of the clearest symptoms appeared at the transition between sales and post-sales teams.

Information about why a customer had bought the platform was not consistently travelling with the deal.

“The CSM really has no idea what use cases were sold and what the customer is looking to accomplish.”

In some cases, platform deals were being agreed before anyone had properly mapped the outcome the customer expected.

“We're selling a bunch of deals without a tangible customer outcome and deliverable map, and then we run into these adoption problems.”

That had implications for time to value. During one of the workshops, the VP expressed the concern directly:

“I worry about the time to value being 24 months for anything that we're selling.”

The challenge, therefore, was creating a shared way for teams to move from:

customer problem → use case → solution design → delivery → measurable value

Teams that had barely worked together needed to design the customer journey, together

Stellafai began by bringing together people who were involved at different stages of the customer lifecycle. Across workshops in Ireland, America and Australia, multidisciplinary groups included people from product, design, account management, pre-sales, Customer Success, partnerships and technical teams.

That was significant in itself. As the VP observed during the San Francisco workshop:

“These teams have not talked to each other for like, 10 years.”

Stellafai used Event Storming and domain-driven design principles to help those teams map how work actually moved through the organisation.

Rather than starting with an idealised process, participants examined the current system:

• Where does information enter?
• Where is it handed over?
• Where does a person have to intervene?
• Where does context disappear?
• Where does a customer wait?
• Which decisions are repeated?
• Which systems hold the data?

And, critically:

Where does the process stop being about customer value and start becoming an internal workflow?

The exercise gave teams a shared picture of a system they had previously experienced only in fragments.

The immediate benefit was greater cross-functional understanding.

“This was really helpful, just to get some of the teams talking to each other.”

And:

“It definitely got people thinking a little bit more systematically about how they bring requirements to their peers.”

Mapping the process exposed where AI agents could actually be useful

The work had a second purpose. The organisation was exploring how agents could replace or augment parts of its internal workflows.

But Stellafai’s approach was deliberately process first, agent second. The VP described the principle simply:

“I told our team, I need a spec. You only get the spec by mapping the current problem.”

If an organisation automates a poorly understood process, it risks creating an agent that performs the wrong activity, faster. Event Storming gave the teams enough detail to understand events, decisions, dependencies and human interventions before deciding what should be delegated to an agent.

That included questioning some surprisingly manual processes.

“What's broken in our process that we have to have a human overseeing a $50 quote?”

Elsewhere, large amounts of back-office capacity had accumulated around gaps in the system:

“The fact that we don't understand the gaps is why we have a 100 people sitting in Brazil doing back office work.”

The objective, therefore, was not simply to identify places to insert AI. It was to understand why the human intervention existed in the first place.

Workshop maps became specifications AI agents could use as briefs

This is where the work moved beyond facilitation. The outputs from the workshops were captured, digitised and organised so they could become usable assets rather than workshop artefacts. The VP had already identified that Event Storming could create the level of detail required for agent design:

“This is the level of detail you really need to then build a spec that you're going to give an agent to do the same job.”

One internal product team took that principle and moved quickly. By July, the process maps produced through the work had been converted into practical agent specifications.

“Every one of those things that we did in that workshop has now come back in terms of a bill of materials that they went and built out as an agentic prompt connected to our systems.”

Some of the first agents were subsequently built and deployed within weeks of the workshop, allowing the organisation to begin demonstrating measurable improvements against previously manual processes. This represented an important change in the AI conversation.

Instead of:

We should use agents here.

The organisation could work through:

This is the current process. This is the event or decision causing friction. This is the specification. This is what an agent could perform. And this is the measure that tells us whether the system improved.

The same methodology could shorten the distance between a sale and customer value

The internal agent work was only one side of the engagement. The bigger ambition was to apply the same outcome-led thinking to customers. The VP was clear that the work was not simply intended to fix internal collaboration:

“We're doing this to lead the customer through a rethink of how they use the platform.”

For a global SaaS platform vendor, that is an important commercial difference from selling a product. Selling a broader platform requires the organisation to become better at discovering the customer’s problem before designing the solution.

That means moving away from:

Here are the features available to you.

Towards:

What are you trying to change, which workflows contribute to it, and what would measurable value look like?

The workshops helped to start creating that common methodology. Pre-sales and post-sales teams could align around the use case earlier, reducing the risk of a customer reaching Customer Success with a platform licence but no clear implementation path. By September, the VP was already seeing movement:

“We're getting tighter alignment with the pre-sales with the SC team on what that handoff needs to look like to shorten the time period to get the project stood up with customers.”

From handoff to shared ownership

The old model treated different parts of the customer journey as separate stages.

1. Sales sold.
2. Pre-sales designed.
3. Customer Success supported adoption.
4. Product built.

Each team could optimise its own part of the process while the customer still experienced delays between them. The new approach encouraged teams to think of customer value as a shared system.

• Event Storming made the handovers visible.
• Impact mapping connected potential activity to the change the customer wanted to create.
• Outcome measures gave teams something more meaningful than simply tracking whether a platform had been implemented.

And Stellafai provided a virtual space where the resulting assets, decisions, initiatives and learning could remain connected after the workshop ended.

An Outcome Intelligence report also helped turn the workshop outputs into a leadership report: identifying the programmes of work emerging from the workshops, the use cases that had been explored and the decisions required to move them forward.

Workshops created momentum. The harder job was changing behaviour afterwards.

Four workshops did not instantly transform a 20-year-old organisation. The VP was open about the cultural challenge:

“We're a 20 year old company, and we act like it.”

Teams had spent years working within established boundaries. Some had never been expected to facilitate customer discovery in this way or challenge the way work moved across functions. During the Sydney engagement, he described the problem as one of permission as much as capability:

“They've never been given permission to think in this way.”

And, at times:

“Culturally they're stuck in this 'we don't know what we need to do next' paralysis.”

That meant the engagement couldn’t end with a workshop. Stellafai combined facilitation with ongoing coaching, digitised workshop assets and access to the operating system so teams could continue using the methods after the facilitators left. The longer-term ambition is for internal teams to run these conversations themselves, first internally and, eventually, with customers.

As confidence grows, the role of Stellafai will shift from running the workshops to enabling the organisation to develop its employees’ own capabilities.

A pilot is now testing whether the methodology can unlock platform value sooner

The biggest commercial question remains open:

Can bringing this methodology into a deal earlier help customers understand the platform opportunity sooner, and reach value faster?

The organisation is now testing that proposition through a small pilot team.

“This is a pilot effort. We're investing in a small squad to see if we insert this into the deal, does it unlock a platform deal sooner.”

The internal results are already tangible: previously disconnected teams have worked through shared processes, internal workflows have been translated into agent specifications, agents have begun to emerge from that work, and handovers between pre-sales and post-sales are becoming clearer.

The customer-facing model is still developing.

The organisation has not yet fully embedded the methodology across customer engagements, and the VP has been candid that teams need greater confidence before that becomes routine. But the direction is clear. The transition from an e-signature product to an agentic platform cannot be achieved by changing the technology alone.

It requires a corresponding change in how teams discover problems, design solutions, collaborate across functions and define customer value.

The agentic platform needs an agentic operating model behind it

For established technology companies, becoming an AI or agentic platform is not simply a product transformation.

The organisation behind the product has to evolve too. Old handovers become bottlenecks. Feature-led selling becomes insufficient. Manual processes become candidates for redesign. And teams that previously owned separate parts of the customer lifecycle need to understand the entire system.

For this organisation, Stellafai is helping to create that bridge: from internal process maps to agent specifications, and from fragmented customer handovers to a shared model focused on measurable value.

Because making the platform more intelligent only creates value if the organisation delivering it becomes more connected.

If your product is becoming a platform but your operating model is still built around the old product, Stellafai can help you map the gaps, redesign the system and connect cross-functional activity to the customer outcomes that matter.