A signed agreement is a success for sales. For the customer, it is a promise that the agreed work will begin. I am particularly interested in the space between those two events. Does the next person know what to do, or is the customer waiting while we assemble the information?
We have been building this stage for ResaHost clients inside Resappi. We wanted to connect accepting an offer with starting delivery, so that the agreed opening tasks are created consistently. A salesperson remembering to follow up cannot be the only way the work gets started.
In August 2026, we created an editable project template for this. We called it Client Setup. It brought together the opening tasks for the hosting service and connected them to the workflow after signature. The people responsible for delivery need to be able to maintain it in the same place where they manage other project templates.
That last detail sounds small, but it mattered to us. If the controls for an automated process sit somewhere the user would not expect, routine changes start going through a developer. An ordinary service improvement then becomes a software task. I want the team to be able to improve the agreed sequence of work themselves.
Creating tasks is still only a beginning. Each task needs a clear meaning of done. A task related to moving a service is not finished because somebody sent a message about it. Someone needs information from the client, someone carries out the change and someone verifies the result. Those responsibilities have to fit together.
The customer also needs to know what is expected of them. If we need access details or a decision, we have to explain that clearly. An internal task list does little for the customer if nobody tells them what happens next. Starting delivery involves communication as much as task management.
As a CEO, I also look at this through profitability. The service agreed during sales defines what the team has to deliver. If the agreement leaves room for interpretation, that uncertainty surfaces during the work. People spend time resolving it, and expectations can diverge in either direction. A good start helps us identify the difference early.
It was important to keep the implementation specific to the service. ResaHost's opening tasks do not automatically belong in every Resaco client relationship. Moving hosting and starting a marketing engagement require different steps. A shared system should accommodate those differences while remaining understandable to the people using it.
That is why I would not begin automation planning by drawing the longest possible workflow. I would choose one service and describe its ordinary starting process. What has already been agreed? What do we still need from the customer? Who takes the next step? Once the answers are clear, they can be translated into software.
Using Resappi ourselves makes these situations visible. Its product stage also matters: in September 2026, we are preparing the public launch for November. The work described here was done to meet a practical need in our own service. It gives us experience to build on as we develop the wider product.
After signing, the customer should feel that things are moving. Our job is to organise the work so that there is substance behind that feeling.
This was one of the reasons we started building Resappi in our own day-to-day business.
