B2B / software
A multilingual application that collects profiles and product requests, keeps status and history, organises assessments, keeps outstanding work visible and prepares the commercial handover to Sales. The commercial layer sits entirely within the Ambassador Journey, but a request, an approval and a definitive handoff remain separate steps with separate authority.
The situation
An ambassador programme tends to live scattered across mailboxes, spreadsheets and conversations. Someone signs up, sends a profile, requests products, gets an answer from one colleague and a question from another. Anyone who wants to know the status has to go looking. Anyone who has to assess something doesn't always know it is waiting for them. And by the time a request finally lands with Sales, it isn't always possible to trace who approved what, and when.
The business question
The question was twofold. How do you get that flow into one place, with a status that is right. And which steps may an application take on its own within it, even when it technically can.
The choices made
The Ambassador Journey is a multilingual application developed within Simply Dom. An ambassador goes through a structured journey in it: submitting a profile, filing product requests, following progress. On the other side, the people who have to assess and approve see what is expected of them and what has already happened.
The commercial layer sits entirely in that same application. Assessment, product choices, approval and the definitive handover to Sales are not a separate circuit next to it; they are steps in the same journey, with the same status and the same history. That was a deliberate choice.
Within that journey, four transitions have been deliberately kept apart.
A request is the moment an ambassador submits something. The application records it, checks it for completeness and puts it in the queue. Nothing more.
An assessment is the moment someone who knows the relationship and the market looks at that request. The application shows that the assessment is needed and whose it is. It doesn't make the assessment.
An approval is a separate step, with a different owner from the assessment. A positive assessment doesn't mean the approval has been given. The application keeps the two apart, in the status as well.
And the definitive handover to Sales is something else again. It only comes into being when someone with the right authority explicitly takes that step. From that moment the handoff is fixed and the file continues along the commercial track. The journey prepares that handover. It doesn't carry it out.
So no request ever becomes an order, a contract or a commitment by itself. That isn't because the application couldn't do it. Technically, a status transition is a small operation. Being authorised to take a business decision is something else, and that was not given to the software.
My role
AI and agents had a large share in the development: research, architecture, code, testing, review and the preparation of the rollout.
They never set the business rules. Which statuses exist, who may set which transition and what an approval actually means was laid down by people who know the programme. AI helped to build that correctly and verifiably. The reliability of access and status transitions has been tested and documented. Ownership of the product, and of the decisions inside it, stayed where it belongs.
Execution
It collects profiles and product requests and checks that everything is present before anything can move on. It keeps status and history, so that at any moment you can see where a file stands. It organises the assessments: who has to act now, what is waiting, what has been dealt with. A daily operational overview makes outstanding work visible without anyone having to search for it. And once a step is completed it prepares the next one, up to and including getting an approved selection ready for handover.
Much of what used to be tracked, forwarded and chased by hand, the application now does itself.
What was deliberately not done
The temptation is there to let the last steps run as well. If the data is complete and the assessment positive, why wouldn't the application set the approval itself? Because in this programme an approval contains more than what is in the fields: the relationship with the ambassador, the commercial judgement of that moment, sometimes an exception nobody described in advance. That decision belongs with someone who can be held to it afterwards. That applies even more to the handover to Sales, which has a consequence outside the journey.
So the application may prepare everything and decide nothing that carries business weight. That distinction was in the design from the start.
Result / impact
There is one place where the programme lives, with a status that is right and a history that can be consulted. Assessors see what is waiting for them. Sales receives a handover that was prepared and approved by whoever is authorised to do so, and no longer has to reconstruct what came before it. And the ambassador knows where their request stands. What happens after the handover, the contract work itself, is a different tool and a different story.
This journey is also the reason I wrote about it in An AI system can be right and still lack the authority to decide. An application can technically assign a next status perfectly. Whether it may is a different question, and here it was answered deliberately by leaving it with people.