What should be in writing before anything else?
A zero-competition clause with a real duration, not a verbal assurance. Ask exactly what stops the partner from approaching your client directly once they’ve done the work and have the contact details, and ask how long that restriction survives after the engagement ends, not just during it. A clause that expires the day the project ships isn’t much of a clause. If you’re still deciding between referring the work out and white-labelling it, that decision comes first.
An NDA that’s actually signed before any client data moves, not one that’s “standard” but somehow never quite gets to signature before the first brief goes over. If a partner is comfortable receiving client information before the paperwork exists, that’s informative about how they’ll treat the paperwork generally.
What should you verify about how the work actually gets done?
Who specifically does the work, and whether that’s the same named team across engagements. A rotating, unnamed bench is the single most common way white-label quality degrades silently, because the partner you evaluated isn’t necessarily the one doing your third project.
Whether the partner will work inside your tools, your reporting templates and your voice, or whether you’re expected to translate their output into your brand’s format after the fact. The second is a hidden tax on every deliverable that erodes the margin the arrangement was supposed to protect.
What quality review happens before the work reaches you, not after. If your team is the first checkpoint that catches errors, you’ve become the partner’s QA department for free, and the margin you’re paying for has quietly disappeared into your own rework hours.
What should you verify about pricing before you need it?
Whether there’s an actual rate card available in advance, or whether pricing is negotiated fresh per project. A partner who prices “on request” every time makes same-week client quoting impossible, which defeats one of the main reasons to have a white-label bench in the first place: speed.
What happens to pricing at volume, and what happens when a project runs over its original estimate. Both are common friction points, and a partner who hasn’t thought through the answer in advance will improvise one under pressure, on your client’s timeline.
What’s the actual proof to ask for, beyond a client logo list?
Not logos: mechanics. A logo tells you the partner has done business with someone; it tells you nothing about how they handle a missed deadline, a backlog, or a moment where the partner’s own capacity is the thing under strain. Ask directly for an example of exactly that: a time capacity was tight, and what happened to the client on the other end of it. Our own answer is published, and the capacity problem itself is worth understanding before you ask.
Ask specifically who else has access to your client’s information once it’s inside the partner’s systems, and what happens to that access when the engagement ends. It’s a question most agencies forget to ask because it feels adversarial to ask it of a company you’re about to trust, which is exactly why it’s worth asking anyway, of anyone, including us.
What does a genuinely good answer to the proof question actually sound like?
A weak answer to “tell me about a time capacity was tight” is a version of “we’ve never really had that problem.” That’s either untrue, or true only because the partner hasn’t taken on enough volume yet to be tested. Capacity strain is a normal, expected feature of any delivery business operating at real scale; a partner who claims to have never experienced it is either inexperienced or not being straight with you.
A strong answer names the specific moment, what caused it, and, critically, what changed in the client-facing experience versus what changed behind the scenes. “A client’s project overlapped with two others booked for the same week; we brought in a second reviewer and shifted internal sequencing, and the client’s deadline held with no visible disruption” is a genuinely useful answer, because it shows the partner has a real mechanism for absorbing strain rather than just hoping it doesn’t happen.
What should raise a flag is any answer that describes the client absorbing the strain instead: a deadline that quietly slipped, a deliverable that shipped thinner than scoped. That’s not necessarily disqualifying on its own, but it should change what you ask next: specifically, what’s changed operationally since then to stop it recurring, and whether that change has actually been tested.
