Justifying Consulting Work When Two Clients Share an Ecosystem
How to document scope, prove value, and respond when stakeholders think they're being billed twice.
A finance stakeholder once asked me a question every consultant dreads: Are we paying for the same work twice?
I had two active engagements in the same event-technology ecosystem — one with the event operator, one with the platform company that powers their digital products. The work was related. The systems touched each other. From a distance, it looked like one consultant doing one job and sending two invoices.
It wasn’t. But “it wasn’t” is not a billing strategy. You need a story stakeholders can verify.
Why overlap happens (and why it looks suspicious)
In mature ecosystems, boundaries blur. Two organizations might share vendors, infrastructure patterns, incident response channels, and sometimes the same external advisor. That advisor — often a technical lead or consultant — becomes the person who understands how the pieces connect.
That connectivity is valuable. It is also dangerous for trust.
Stakeholders don’t see your calendar. They see invoices, milestones, and a vague sense that “someone already fixed that.” When both organizations operate in the same domain — say, large-scale sporting events and the software that runs them — the suspicion is rational. The question isn’t an attack. It’s a request for clarity.
The mistake consultants make is responding defensively. The better move is to treat the question as an invitation to document what you should have been documenting all along.
What actually differed in my case
The two engagements ran on parallel tracks with different sponsors, different contracts, and different definitions of done.
Engagement A — the event operator
This work centered on organizational infrastructure and compliance obligations tied to the event itself:
- Migrating cloud resources into an account owned by the event organization
- Standing up product analytics for their stakeholder reporting needs
- Recovering from a payment webhook incident that affected their revenue operations
- Producing regulatory and governance deliverables required by their jurisdiction
None of this was about rebuilding a consumer-facing photo platform. It was about the event entity operating safely, observably, and in compliance with its own obligations.
Engagement B — the platform company
This work was a platform modernization effort:
- Infrastructure-as-code for a photo processing pipeline that had grown organically
- Migrating face recognition from a managed cloud API to a self-hosted model on serverless compute
- Introducing a distributed cache layer for vector search at scale
- Hardening production resilience after memory pressure and authentication failures in the cache tier
The platform serves many events. The event operator is one customer among several. The technical depth, codebase ownership, and operational surface area were entirely different.
There was thematic overlap — both touched AWS, both cared about production stability — but thematic overlap is not duplicate work. Your cardiologist and your physical therapist both care about your heart. You don’t ask for a refund on one because the other exists.
The playbook: how to respond without sounding defensive
When the question lands, you need artifacts, not arguments. Here is what I use.
1. Build a scope matrix before anyone asks
Maintain a living document that maps work to outcomes across engagements. I use four columns:
| Dimension | Engagement A | Engagement B |
|---|---|---|
| Sponsor | Event org leadership | Platform company leadership |
| Primary outcome | Compliance, migration, incident recovery | Platform rebuild, ML pipeline, cache architecture |
| Systems touched | Org-owned cloud accounts, analytics, payment flows | Photo pipeline, face search, orchestration layer |
| Contract reference | Retainer + milestone schedule (approved date on file) | Phased stabilization contract with explicit carve-out |
Update it weekly. When the awkward email arrives, you don’t scramble — you forward a link.
2. Get carve-outs in writing early
If you know two engagements will coexist in the same ecosystem, name the boundary in both contracts before overlap begins. Our platform contract explicitly excluded work already covered under the event operator’s engagement. That single clause turned a confrontational audit into a contractual clarification.
Carve-outs are not adversarial. They protect everyone: the consultant from accusations of double billing, and the clients from genuinely duplicated spend.
3. Lead with deliverables, not hours
Hours are ambiguous. Deliverables are not.
“We spent 40 hours on infrastructure” means nothing to a finance reviewer. “We migrated the production database to an account owned by the event organization, completed on [date], verified by [person]” is verifiable. Stack your evidence as completed outcomes with dates and acceptance, not as time logs that require trust in your judgment.
4. Know when to say no
The fastest way to confirm someone’s suspicion is to do the same work twice and bill both sides. When a request from Engagement B looks like it belongs to Engagement A’s scope — or vice versa — stop and route it through the sponsor. “This falls under your existing contract with [other org]. I can do it, but it should be a change request to that engagement, not this one.”
Saying no to a quick favor is uncomfortable. Doing the favor and creating a billing dispute is worse.
5. Separate your post-mortems
After a production incident that spans shared infrastructure, both clients will want a report. Write two, scoped to each client’s responsibilities and action items. A single shared document that reads like a billable deliverable for both sides is exactly what triggers the duplicate-work question.
One incident can have one root cause and two different remediation paths. Document them separately.
What I learned
Consulting runs on trust, and trust runs on legibility. When your work is invisible — when stakeholders only see you in meetings and on invoices — overlap looks like fraud even when it isn’t.
The consultant’s job is not just to solve technical problems. It is to make the value of that work legible to people who will never read a pull request. A scope matrix, written carve-outs, deliverable-based reporting, and the discipline to refuse duplicated asks — these are not administrative overhead. They are the product.
That finance stakeholder’s question was fair. I had a good answer because I had been building the evidence before I needed it. If you’re operating across related organizations today, start the matrix this week. The awkward email is coming eventually. Be ready with a link, not a lecture.