Offering Linnworks AI integration as a service: a playbook for agencies and dev shops
If you already build on Linnworks for clients, AI integration is the rare new service line that fits your existing skills exactly and does not require you to become a different company.
The service, defined
Not “AI strategy”. Something you can scope and finish: deploy an MCP connector into the client’s own Cloudflare account, wired to their Linnworks credentials, so their team can ask questions of live order and stock data from the assistant they already use. A day of work, a defined outcome, a thing that either works or does not.
That specificity is what makes it sellable. Clients have been pitched AI in the abstract for two years and are tired of it. “Your ops manager will be able to ask about open orders in plain English by Thursday” is a different conversation.
What to actually charge for
Four separable things, and the first is the smallest:
- Deployment. Credentials, secrets, deploy, connect the client’s assistant, verify. Fixed fee.
- Scoping the tool surface. Which tools they get. Nearly always read-only first. This is the conversation that needs your judgement and it is worth billing.
- Enablement. A session with the ops team on how to ask, what it is good at, where to double-check. This is where clients find the value and where you prevent the project being written off in month two.
- Custom tools. The client’s own idiosyncratic questions, turned into purpose-built tools. The highest-margin work and the reason to hold the source.
What to refuse
Refuse write capability on a first engagement unless there is a specific, named reason for each write tool. You do not want your first AI project at a client to be the one where something got created that should not have been.
Refuse to be the data processor. Deploy into the client’s account, on their credentials, so you are not sitting in the data path. It is better for them and dramatically better for you.
And refuse the client who wants it because a board member read something. Without one named person who has questions they currently cannot answer, the deployment goes unused and becomes the AI project that did not work.
The licensing that makes it repeatable
The economics only work if one codebase serves every client. Building per client is weeks each. Reselling a hosted subscription means recurring revenue you collect for someone else and an architecture you cannot change when a DPO asks a hard question.
Buying source with unlimited client deployments is the pattern that scales: one purchase, deployed separately into each client’s own account, each instance isolated, each one modifiable for that client’s needs. Unlimited client deployments of the Linnworks connector come with a single £249 purchase, which stops being a line item somewhere around your second client.
The pitch that lands
Lead with the data boundary, not the AI. “This runs in your account, speaks only to your Linnworks, and we can deploy it unable to change anything” answers the three objections before they are raised. Then demo one real question against their own data. Nobody has ever been convinced by a slide about this and nearly everybody is convinced by thirty seconds of their own open orders.
Deployment mechanics and the multi-client setup are in self-hosting a Linnworks MCP server, and the GDPR framing for European clients is in connectors your clients’ DPOs will accept.
Questions, or want a tool we don't have yet? Email hello@grafto.co.uk — a real person replies.