The request you always had to refuse
Every IT provider knows this conversation. At the end of a visit, a customer asks for “a small tool”: a portal where their own customers could follow their requests, a register of their equipment with inspection dates, an approval flow for purchases. Nothing complicated on the surface. And yet the answer was almost always no.
Custom development cost too much for a small account. It had to be scoped, developed, tested, then maintained for years, with the risk that the developer would leave or the customer would change their mind. So you suggested a spreadsheet, or one more tool to buy, with one more subscription, one more password, and one more piece of information that does not talk to the rest.
That refusal was not a lack of goodwill. It was a matter of economics: the need was real, but the cost of serving it exceeded what the customer could pay. That equation has changed.
From hours sold to results delivered
When AI assembles the screens, rules and automations on a shared foundation, the time needed to deliver a business tool is no longer the first factor. What counts is what the tool changes for the customer: requests handled faster, inspections that are no longer forgotten, information available without having to call someone.
The value of your offer therefore moves. It is no longer measured by the volume of hours, but by the result obtained, the level of service you guarantee and the continuous improvement you propose. A delivered tool is no longer the end of a project. It is the start of a service subscription.
Your role does not disappear in this shift, it concentrates. You keep the relationship with the customer, the knowledge of their context and the responsibility for what goes into production. The standard tasks, the ones you redid for every customer, are assembled by AI. You validate, you adjust, you answer.
The customer does not buy your hours. They buy a problem that stops coming back.
Reuse from one customer to the next
This is where the offer becomes profitable. A capability validated for one customer, an equipment register or an intervention portal, is not a one-off project. It is a model you can offer to your other customers in the same sector, with their data, their rules and their vocabulary.
Each vertical you serve makes the next one faster. The register designed for a maintenance company becomes the base for a rental company. An installer’s intervention portal transposes to an engineering office. You no longer write the same thing twice.
For that reuse to stay healthy, each capability must be treated as a product, not as a quick fix copied from one folder to the next.
- An owner: someone in your team who answers for the capability and its evolution.
- A version: what is installed at each customer is known, and an update is decided, never imposed.
- Permissions: who sees what, who changes what, defined once and applied everywhere.
- Tests: business rules are checked before every update, so that a fix for one customer does not break another customer’s tool.
That framework is the difference between a provider who sells an offer and a provider who accumulates exceptions.
One space per customer, rights under control
A custom application offer only holds if the customer agrees to entrust you with their data. That trust is not declared. It is built into the structure of the platform itself.
Each customer has their own space. You are invited into it, as a provider, only within the agreed scope: the applications you manage, the data you need, nothing more. The customer sees who has access to what and can revoke that access themselves, without going through you. Every consultation and every change leaves an entry in the access record.
This arrangement protects both parties. The customer keeps control of what belongs to them. You have proof of what you did and what you did not do. When a business owner asks “what about our data?”, the answer is no longer a promise, it is a setting they can check.
It is also what makes the offer acceptable to customers who, until now, refused to let an outside provider touch their management. Control stays with them. The service stays with you.
How to build the offer
You do not need a complete catalogue to begin. A solid offer is built in a few steps, starting from what your customers already ask you for.
- Pick two or three requests
Reread the year’s tickets and conversations. The requests that come back most often are your first capabilities.
- Assemble the first one with a pilot customer
A customer who has voiced the need and with whom the relationship is good. Describe the need in their words, assemble, show.
- Validate with them
Have them use the tool on their real cases, for as long as it takes. Note what is missing and what is superfluous. Correct, then freeze a version.
- Package the capability
A clear description, the rules it applies, what remains decided by a person. That document is what will let you offer it elsewhere.
- Offer it to similar customers
Same sector, same size, same need. The pilot becomes a reference for the method, without turning it into a testimonial.
- Publish when it is mature
A capability validated by several customers can be published on the marketplace and serve companies you would never have met.
The most frequent requests are known: we described them in Five applications SMEs assemble first. And if one of your capabilities deserves to become a product in its own right, the path is described in From the idea to the software you sell.
In Neoo
Neoo is designed for this model. Neoo Forge, the studio that assembles your applications with AI, lets you describe a business need in the customer’s words and obtain screens, rules and automations connected to their data. Each application has an owner, a version, permissions and tests.
Neoo MSP is the offer for providers: a control per customer, with a separate space for each one, rights by scope and an access record the customer can consult. The monitoring side follows the same rule, no silent action on a customer’s infrastructure, as we explain in See an incident before it becomes an emergency. You will find the details on the Neoo MSP page.
The Neoo partner network brings together the providers building this offer. You remain your customers’ partner of record, including when they become more autonomous. And when a capability is mature, Neoo Exchange, the Neoo marketplace, lets you publish it for other companies. The principles are described on the partners page and on the Neoo Exchange page.
Frequently asked questions
Do we need developers to offer this?
No. Neoo Forge assembles applications from a business description. If you have developers, they can extend what is assembled. And for complex requests, the Neoo team can support you.
Who owns what is built for a customer?
The customer keeps their business asset: their data, their rules, their screens. The platform keeps its engine. You keep your know-how and the packaging of your offer, which you can propose to other customers.
How is access to customer data controlled?
Through a separate space for each customer, rights limited to the agreed scope, an access record and a revocation the customer can decide themselves, at any time.