White-label automation delivery without losing the client relationship.

The question agencies ask before subcontracting technical work is rarely about price or quality. It is about what happens to the client relationship. You introduce a specialist, the specialist turns out to be good, and eighteen months later the client has their number.

That risk is real, but it is a contractual and operational problem rather than a trust problem. It gets solved with arrangements you can write down, not with reassurance. This is what those arrangements look like.

Decide who is in front of the client, and be specific about it.

“White label” is used loosely enough to mean almost nothing. Before any work starts, four things need an explicit answer.

Who appears on client calls. Whether the specialist attends at all, and if so, under whose name and with which email address. Whose logo is on the documentation. And which party sends the invoice.

There are three workable models and they are not interchangeable.

Fully white-label means the implementation partner never appears. All communication goes through you, documentation carries your brand, and the client has no reason to know a third party exists. It is the safest model and the slowest, because every technical question makes a round trip through an account manager.

Co-branded means the partner is named as your implementation partner and can join calls with you present. It is faster and more honest, and it works well when the client already knows the agency does not have an in-house integration team.

Direct technical contact means the partner speaks to the client’s developer or IT provider without you relaying, while you keep commercial ownership. This is common in practice and worth deciding deliberately rather than drifting into it.

Pick one, write it into the agreement, and make sure the partner knows which one applies before the first call.

Split responsibility so nothing falls between you.

Ambiguity here is what causes projects to stall. The useful split is not by seniority. It is by which side owns the client outcome and which side owns the system behaviour.

Your agency owns	The implementation partner owns
The commercial relationship and the contract	Technical scoping and architecture
Requirements as the client stated them	Endpoint choice, auth and data flow
Approvals and sign-off	Build, testing and failure handling
Timeline commitments made to the client	Realistic build estimates given to you
Anything client-facing: design, campaigns, accounts	Documentation and handover material
Deciding when the client is told about a delay	Telling you about the delay immediately

The last row matters more than it looks. A partner who reports problems to you the day they appear is worth considerably more than one who reports them the week before delivery.

Handle credentials as an access problem, not a trust exercise.

Most disputes about subcontracted technical work come down to access that was granted casually and never withdrawn.

Separate accounts

Never share the client’s login. Create a distinct user or service account for the implementation partner in every system, with its own credentials. Shared logins make it impossible to tell who changed what, and impossible to revoke one party’s access without disrupting everyone.

Least privilege

An integration usually needs far less access than gets granted. Read on two objects and write on one is a common real requirement, against an offer of full administrator rights. Ask what the minimum is and grant that.

An expiry date

Decide at the start when access is revoked. The end of the warranty period is a sensible default. Put the date in the agreement so that removing access is a scheduled step rather than an awkward conversation.

A transfer path

If the workflow runs on infrastructure the partner controls, establish before the build how it moves to you or the client later. A system you cannot take possession of is a system you do not own, whatever the contract says.

Put the boundaries in the agreement, not in the conversation.

A short set of clauses covers almost all of the exposure. Non-solicitation of the client for a defined period. Confidentiality that covers the client’s data and the fact of the engagement itself. Clear assignment of intellectual property in the delivered workflow to you or your client, not the partner. And a stated position on whether the partner may reference the work publicly, including in anonymised form.

Sign the NDA before you send the requirement rather than after. If a partner hesitates at any of this, you have learned something useful cheaply.

The handover pack is the actual deliverable.

A running workflow is not a delivery. A workflow your agency can support after the partner is gone is a delivery. That difference is entirely made up of documentation, and it is the first thing cut when a project runs late.

Require these before final payment:

• An exported, importable version of the workflow, held somewhere you control
• A written description of what it does, in order, in plain language
• A list of every credential used, which system it belongs to and who owns it
• The failure cases that are handled, and what happens in each
• The failure cases that are deliberately not handled, and why
• How to tell whether it is currently working, without opening the builder
• What to check first when the client reports that it has stopped
• Named limits: volumes, rate caps and anything that will break at a larger scale

The two items about failure are the ones that separate a professional handover from a screenshot in a shared drive. An honest list of what is not handled is more valuable than an optimistic claim that everything is.

Run the first project small.

The sensible way to evaluate any implementation partner is a single, tightly scoped piece of work for one client, with a fixed price agreed in advance. Not a retainer, not a framework agreement, and not the largest thing on your roadmap.

You are testing specific things: whether the estimate held, whether problems were reported early, whether the documentation is usable by someone who did not build the system, and whether the client noticed anything about the arrangement that you did not intend them to notice.

That is enough signal to decide, and the downside is bounded to one project.

How we work inside this model.

Oniru builds the technical half of agency projects and stays behind the agency by default. Your agency keeps the client relationship, the commercial ownership and the credit. We handle scoping, implementation, testing and the handover documentation, and an NDA can be in place before you send us anything.

If a client is asking your agency for something involving APIs, a CRM or an AI step, send us the requirement as they described it. We will tell you how we would approach it and what it would involve. Start here, or read how the partnership works first.