Direct answer
Two people at the client company give opposite instructions: which one counts?
Your contact says build it one way. Their colleague, sometimes their boss, sometimes someone in another team, says the opposite, often in a different thread, often after the work has started. If you pick the wrong voice, you did the work twice and may get paid once. The fix is not to guess who is senior. It is to name one instruction source in writing before the next task starts, keep a decision record of everything both people say, and let that record settle any collision. Here is the pattern, step by step.
Updated October 26, 2026.
Why opposite instructions are a payment risk, not a communication quirk
Conflicting instructions feel like a people problem, so most freelancers treat them as one: they try to keep both contacts happy and quietly absorb the confusion. That is how the money leaks. Work built on instruction A gets rejected by the person who gave instruction B, the redo lands on your hours, and at invoice time each contact points at the other as the one who approved what you actually delivered. Nobody has to be dishonest for this to happen. Two busy people, two partial views of the project, and no shared record will produce opposite instructions on their own. The risk is structural, and the fix has to be structural too: one named source, one record, agreed before the next task, not argued after the delivery.
Name one instruction source in writing before the next task starts
Before the next task begins, get one short written agreement: instructions for this project come from one named person, and anything from anyone else is input, not direction, until that person confirms it. This is not a power play and it does not insult the second contact. It protects both of them: the named source knows their word is the one being built on, and the other contact knows their suggestions need one confirmation before they become billable direction. Send the message below, or your version of it, and keep the reply. If nobody at the client will name a source, that is real information about the project, and it is better learned before the next task than at the next invoice.
The decision record: every instruction, who gave it, what was accepted
From that point, keep a decision record with three fields for every instruction: the instruction itself, who gave it and when, and what was accepted. Accepted is the load-bearing word. An instruction from the named source is accepted when it lands. An instruction from anyone else is recorded as proposed, and it becomes accepted only when the named source confirms it. When the work runs through Zambo, each stage closes as a handover the client opens, and every call carries a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, so the instruction, the work it produced, and the acceptance sit on one dated record instead of scattered across two chat threads and a call. A receipt proves the saved result was not changed since it was saved; it does not prove an instruction was wise, and it does not replace the naming agreement. Together, though, the agreement says whose word counts and the record shows what that word produced. New users get 20 free calls per day, then they upgrade when the job needs more.
When the two instructions collide on delivered work: the record settles it
Sooner or later the collision arrives on work already delivered: the second contact sees it and says this is not what they asked for. Without a record, that moment becomes a negotiation about memory, seniority, and goodwill, and the freelancer usually pays for the redo to end it. With the record, the conversation is short and factual: here is the instruction, here is who gave it, here is the confirmation that made it the accepted one, and here is the delivered work matching it. Changing the work to the other instruction is then plainly new direction, priced and scheduled as new work, not a defect in what was delivered. Send the record, not a defense of yourself. Most collisions end there, because the record was never really in dispute; it simply did not exist before.
Copy-paste: the message that names the source
Quick setup so nothing gets built twice: can we agree that project instructions come through you, and anything suggested elsewhere comes to you first for a yes before I build it? I will keep a simple decision record of each instruction, who gave it, and what we accepted, and share it with every delivery. That way, if two directions ever collide, we settle it from the record in minutes instead of rebuilding from memory.
What a record does not settle
A verifiable receipt proves the saved result was not changed since it was saved; it does not decide who at a client company holds authority, does not make an instruction binding on anyone, and cannot make a client pay. The written naming agreement, the dated decision record, and the acceptance on that record are what the conversation stands on. This page is general information, not legal advice.
Frequently asked questions
Two people at the client company give opposite instructions: which one counts?
The one from the instruction source you named in writing counts. Agree before the next task starts that direction for the project comes from one named person, and that instructions from anyone else are proposals until that person confirms them. Record every instruction with who gave it and what was accepted. Without that agreement, there is no reliable answer, because seniority, memory, and confidence all point in different directions once delivered work is in dispute.
The boss overruled the instruction I already built on. Who pays for the redo?
The record decides the framing. If you built on the named source's accepted instruction, the delivered work is correct against the direction you were given, and the overrule is new direction: priced, accepted, and scheduled before it starts. If you built on an unconfirmed instruction from the second contact, the naming agreement was the protection you skipped. Either way, send the decision record first: the instruction, the giver, and the acceptance settle whose change this is.
Will naming one source offend the other contact?
Handled plainly, no. The agreement routes their input through one confirmation, it does not silence them, and it protects them too: nobody gets blamed later for an instruction they gave casually in a side thread. Frame it as build discipline, one record and one source so nothing gets built twice, and most contacts are relieved someone finally said it.