How to Prove to a Client That the Delay Is on Their End

[#1]

When a deadline slips, the conversation often turns emotional fast:

• “You said it would be done last week.”
• “We’ve been waiting on your team.”
• “No, we replied — your side didn’t move.”

If you’ve ever delivered work through a client (approvals, reviews, access, sign-offs), you know the uncomfortable truth: a big part of delivery time can be “waiting time,” and it’s rarely tracked in a way that’s easy to show.

This article is about proving the delay is on the client’s end using objective workflow evidence—and doing it in a way that protects the relationship instead of escalating blame. We’ll start with the theory (what counts as “client-side delay” in Jira terms), then walk through a practical, repeatable workflow using Time Metrics Tracker | Time Between Statuses.

The main character: the person who gets blamed for delays they don’t control

Meet Alex (it could be you): Delivery Manager / Project Lead / Account Manager. Alex is accountable for timelines, but depends on the client for:

• clarifications and feedback
• approvals and sign-offs
• environment access and credentials
• data, content, legal/compliance review
• UAT and acceptance

Alex’s real job isn’t “proving someone wrong.” It’s maintaining trust while restoring predictability.

So the goal isn’t to “win the argument.” The goal is:

1. Make the timeline factual (where did the time go?)
2. Make responsibilities visible (who owned the next move?)
3. Create a forward plan (what has to happen next, by when?)
   
   

Practical workflow: how to prove client-side delay with Jira + TMT

Step 0: Make client handoffs visible in the workflow (15 minutes that saves you forever)

If you already have client-owned statuses, great—skip ahead.

If you don’t, add at least one. The minimum viable setup is:

• In Progress (your team)
• Client Review / Waiting for Customer (client)
• Done

Two rules that make this work:

1. Every time you ask the client for something that blocks progress, move the issue to the client-owned status.
2. Every time the client responds, move it back to a vendor-owned status.

Step 1: Apply a work schedule 

In Time Metrics Tracker | Time Between Statuses, set a Work schedule that matches your delivery reality:

• Business hours only (e.g., 9:00–18:00)
• Exclude weekends (if you don’t deliver on weekends)
• Exclude holidays

 

Why this matters:
Now your “Waiting for Customer = 2.3 days” means 2.3 business days, not “we counted Saturday to make you look slow.” It removes a whole category of arguments before they start.

Step 2: Configure TMT 

You don’t need 20 metrics. You need three that answer “where did the time go?”

Metric (TMT)	Why you need it	TMT configuration (how to set it)	What statuses to include
Metric A: End-to-end delivery time (for context)	Gives the headline timeline for the ticket	Start status: Request Received (or your first “work starts” status, e.g. To Do / Selected for Development) → End status: Done (or Delivered / Accepted)	All statuses between start and done (end-to-end span).
Metric B: Client wait time (the proof)	Shows how long the issue was waiting on the client (approvals, feedback, UAT). This is the key “delay is on their end” evidence.	Start status: Client Review (or Waiting for Customer / first client-owned status) → End status: the next vendor-owned status after client action (e.g. In Progress / Changes Requested / Implementation)	Client-owned statuses such as Client Review, Waiting for Customer, Awaiting Approval, UAT, Legal Review (Client).
Metric C: Vendor active time (your defense & improvement lever)	Shows your team’s actual working time (implementation + QA + internal review), so the conversation stays fair and factual.	Start status: first vendor-owned work status (e.g. In Progress / Implementation) → End status: Done OR the first client-owned status (e.g. Client Review) if you want “vendor effort before client handoff”	Vendor-owned statuses like In Progress, Implementation, QA, Ready for Review, Internal Review, etc.

Step 3: Add thresholds that flag “waiting on client” early (before it becomes an escalation)

This flips you from reactive proof to proactive control.

Example thresholds:

• Warning: Client Review > 2 business days
• Critical: Client Review > 5 business days

Instead of debating after a milestone is missed, you can point to a risk trend before the miss happens.

Step 4: Build a “Client Delivery Health” dashboard 

Your dashboard should answer, at a glance:

1. What’s in progress?
2. What’s waiting on the client?
3. Which items are aging abnormally?

A practical layout:

1. Jira Filter Results gadget – list of items in client-owned statuses (“Waiting for Customer”, “Client Review”, etc.)
2. TMT Agile Metrics gadget – show End-to-end, Client Wait, Vendor Active per issue
3. TMT Scatter Plot – highlight outliers (the few tickets causing most timeline pain)
4. TMT WIP Run Chart – trend of aging items / growing waiting queues

Common pitfalls (and how to avoid them)

Pitfall 1: Your team forgets to move issues into “Waiting for Customer.”

If people keep issues in “In Progress” while waiting on the client, your data will blame you.

Fix:

• Make “Waiting for Customer / Client Review” the default “blocked by client” move.
• Add a lightweight team rule: if you asked the client a blocking question, the issue cannot stay in a vendor-owned status.

Pitfall 2: The client says, “We responded, but you didn’t notice”

This is where workflow discipline matters.

Fix:

• When client feedback arrives, move the issue back to a vendor-owned status immediately.
  Keep feedback in Jira comments or linked artifacts so it’s part of the same record.

Why this works 

You can manually inspect Jira issue histories, but it doesn’t scale and it’s easy to argue about.

Time Metrics Tracker | Time Between Statuses value in this scenario is that it gives you:

• Jira-native evidence based on workflow transitions
• Clear separation of active vs waiting time (vendor vs client handoffs)
• Dashboards that keep everyone aligned (not just during escalations)
• Early warnings so you don’t wait for a missed deadline to have the conversation
• Work-schedule accuracy so nobody can dismiss the numbers as “calendar padding”

Done well, it doesn’t just “prove the delay.” It upgrades your delivery process into something both sides can trust.

Conclusion: prove it once, then prevent it forever

The best time to prove client-side delay is before it becomes a conflict.

If you:

1. make client handoffs explicit in the workflow,
2. apply a fair work schedule,
3. track client wait time as a first-class metric, and
4. share a simple dashboard regularly,
   
   

…then “who caused the delay?” stops being a debate. It becomes a shared view of reality—and a shared plan to improve it.

Want to try this in your Jira?

If you want to set up the same “vendor work vs. client waiting” proof in your Jira, Time Metrics Tracker can help.

• Book a demo
• Start a free trial