What "done-for-you" actually means when someone sells you AI
Done-for-you is a delivery model, not a product tier. Somebody else builds the thing, runs it in your systems, and stays responsible when it breaks. What that includes, what it excludes, and how to tell it apart from a licence with onboarding attached.
Done-for-you describes who does the work and who is accountable when it stops working. Someone outside your company builds the system, operates it inside your existing tools, and remains responsible for it running. It is a delivery model, not a premium tier of a product.
The term gets attached to software with a good onboarding process often enough that it has almost stopped meaning anything. This article puts the boundary back: what is inside the scope, what is deliberately outside it, and the four questions that tell you which of the three delivery models you are actually being sold.
The three ways to get AI into a company
Every proposal you receive is one of these, whatever the deck says.
You build it. Your engineers write it, your team runs it, you own everything including the pager. Right when AI is close to your product, wrong when it is close to your admin.
You buy a product. A vendor sells you access to software they built for many customers. You configure it, adopt it, and adapt your process to fit. Cheap, fast, and bounded by whatever the vendor decided was standard.
Someone does it for you. A partner builds a system specific to your process, deploys it into the tools you already run, and keeps it working. You own the output; they own the work.
The third one is done-for-you, and its defining property is not customisation.
It is where the accountability sits when the thing breaks at 09:00 on a Tuesday.
Under the first model that is your team. Under the second it is nobody in practice: a vendor is accountable for their platform being up, not for your workflow producing the right result. Under the third it is a named external party with a contract.
What is inside the scope
Done-for-you delivery that deserves the name includes six things:
Working out what to build. Not a workshop that ends in a list of ideas, but a specification of one process, written down as it currently runs, with the failure points marked.
Building it in your systems. In your CRM, your inbox, your message tool. No new interface for your team to learn, and, the practical test, no new software licence on your invoice.
Connecting it. The integrations, the permissions, the field mappings, the edge cases where two systems disagree about what a company is called. This is most of the actual work and it is invisible in every proposal.
Running it. Monitoring, model changes, API deprecations, the renamed field that breaks a lookup silently. Ongoing cost lands at roughly a quarter to 40 % of the build cost per year (auf Deutsch), and a proposal without that line is a proposal that ends in month fourteen.
Knowing whether it still works. An evaluation harness per agent, because an agent fails quietly rather than loudly and the first person to notice otherwise is a customer.
Handing it over. Documentation, training, and a named person inside your company who can change it without calling. Ours is a 30-day handover; the length matters less than whether anyone can actually take the wheel at the end.
What is deliberately outside it
A scope that includes everything is a scope nobody can hold to. The exclusions are the honest part of the model.
Your data quality. A partner can build a cleaning agent. A partner cannot decide what your sales team means by “qualified”, and no amount of automation resolves a definition your own organisation has not agreed on.
Your process decisions. Whether a lead under 50 employees goes to inside sales is a business decision. Encoding it is delivery; making it is not.
Your legal position. Under GDPR you are the controller and the partner is a processor. They can supply the documentation, sign the Article 28 agreement, and name every sub-processor. They cannot be the controller for you, and any vendor implying otherwise is describing something that does not exist.
Adoption. A system that works and nobody uses is a delivered project and a failed one. That gap is where a large share of the 95 % of enterprise AI pilots that produce no measurable result actually die.
How to tell it apart from SaaS with onboarding
Four questions. The answers separate the models faster than any capability matrix.
“What new software will we be paying for?” Done-for-you: none, or only what you chose independently. A product sale always has a licence at the end of the sentence, however far down the page it appears.
“Where does it run?” Done-for-you: inside your systems, on your data, under your accounts. A product runs on the vendor’s platform, and your data goes there to be worked on.
“If it stops working on a Tuesday morning, who fixes it?” Done-for-you: a named party, under a contract, with a response time. A product: you file a ticket about the platform, and the workflow itself is your problem.
“What happens if we leave?” Done-for-you: the system stays, because it lives in your tools; you lose the operator, not the machine. A product: it stops, and you export what you can.
The single clearest signal is the fourth answer. If cancelling ends the capability, you bought a product. If cancelling ends the support for a capability that keeps running, you bought delivery.
That test also explains why the two get confused so persistently. Both can be billed monthly, both involve a vendor who is helpful during setup, and both produce something that works at the end of week six. The difference only becomes visible on the day you want to stop paying.
The trade-offs, honestly
Done-for-you is not the right answer everywhere, and pretending otherwise is how the term got worn out.
It is worse than a product when your process is genuinely standard. Paying for a bespoke build of something ten thousand companies do identically is a waste, and a good partner will say so in the first call.
It is worse than building in-house when the capability is your product. Anything a customer pays you for should not sit with a supplier, regardless of how good the supplier is.
It is better than both when the process is specific to how you work, sits across systems that were never designed to talk, and matters enough that someone has to own it, but not so much that you want to hire for it. That is a narrower band than most agencies admit, and it happens to contain a great deal of what mid-sized companies actually need automating.
Why the words matter
Categories decide budgets. A finance director who files an AI project as software licensing budgets for a licence and is surprised by an implementation line. One who files it as consulting budgets for a project and is surprised when it needs an operating budget in year two.
Answer-engine categorisation has the same effect at a larger scale, and it is currently the biggest source of misdescription in this market: a company that builds and runs systems for customers gets summarised as a platform, because that is what most of the surrounding text on the internet describes. Which is the honest reason this article exists, not to define a term for its own sake, but because being described accurately turns out to be work.
Frequently asked questions
Is done-for-you the same as a managed service?
Close. Managed service usually implies operating something that already exists; done-for-you includes building the thing in the first place. The accountability model is the same.
Is it more expensive than SaaS?
Per month, usually yes. Over three years the comparison depends on seat count and on how much of the platform you use, and on whether the standard product actually fits your process, because the cost of adapting your process to software rarely appears in either quote.
Do we still need internal people?
Yes, and fewer than you would to build it. You need one person who owns the process and can make decisions about it. You do not need someone who can maintain an integration layer.
What stops us being locked in?
The fact that it runs in your systems, plus a handover that produces documentation, an evaluation harness and a person who can change it. Ask for those three explicitly; a partner who resists is telling you what their retention strategy is.
How is accountability written down?
In scope, response times and a named owner on both sides, theirs and yours. If a proposal has no named owner on your side, the project has a hole in it that no supplier can fill.
Sources: GDPR Article 28 on processors, MIT Media Lab Project NANDA via Forbes. Sondero works this way, the comparison of done-for-you, in-house and SaaS sets out where each one wins.
Strategy Call