A vendor escalation ageing report for small teams

Question and scope

This study asks how long each vendor escalation has been open and which part of the wait is under the company's control. The unit is one escalation case, and the population is the cases opened or active during a declared quarter. The result describes the current queue and its history, not the quality of the vendor's product. Freeze the vendor list and the quarter before collecting data.

Include cases raised through a support portal, email, phone, and a partner account manager. Exclude ordinary licence questions and pre-sales conversations unless they blocked a live service. Record the source of each case so a reviewer can find the original thread. A case that exists only in someone's inbox is still a case, but it needs to be entered into the system before the study starts.

Define the clock and the start event

Start the clock when the company has enough information to make a valid report, not when someone first thought about the problem. A vendor cannot act on a vague description, and counting that time as vendor delay is unfair and misleading. Record the moment the initial package was complete: the account, the environment, the symptom, the time, and the evidence. The gap before that moment belongs to internal preparation.

Pause the clock only for a defined reason, such as a scheduled maintenance window requested by the vendor or a customer who cannot provide access. Every pause needs a start time, an end time, and an approver. Do not pause for internal meetings or for a queue that the vendor has not acknowledged. A pause that cannot be audited should not exist in the report.

Build the escalation frame

Export the case identifier, vendor, product, severity, open time, last vendor response, next promised update, and current owner. Link each case to the ticket or incident that caused it. Add the customer or business service affected, because a long wait on a low-impact tool is different from a long wait on payroll. Save the export with the date and the query used to produce it.

Reconcile the case count with the vendor portal and the internal ticket system. A case that appears in one but not the other is an ownership gap. Record the difference instead of silently choosing one source. If the vendor portal only shows open cases, ask for a closed-case export so the study can compare resolution times. A report built only on open cases will overstate the age of the queue.

Age by severity, not only days

Report the age distribution for each severity level rather than one average across all cases. A critical case open for two days can matter more than a low-priority case open for sixty. Use buckets that match the service promise, such as under one day, one to three days, four to seven days, and over a week. Show the count and the oldest case in each bucket.

Add the business calendar to the calculation if the service promise is expressed in business hours. A weekend should not make a Friday case look older than it is, unless the vendor supports weekends. State the rule in the report. The reader should be able to recalculate a case from the dates without guessing which calendar was used.

Grade the evidence

Grade each case as verified, partial, or unsupported based on the record. Verified means the case has a complete initial report, a vendor acknowledgement, and a dated status for each stage. Partial means one of those is missing but the sequence is clear. Unsupported means the only evidence is a forwarded email with no case number. Report the grades beside the ageing figures.

Treat a vendor's automated acknowledgement as a receipt, not as progress. A case can be acknowledged for two weeks without a human review. Record the first substantive response separately and show it in the report. If the vendor cannot provide one, say so. The distinction prevents a dashboard from looking healthier than the customer's experience.

Separate vendor delay from internal delay

Calculate the time the case spent waiting for the company as well as the time it spent waiting for the vendor. Internal delay includes missing information, an unapproved change, or an owner who did not forward the vendor's question. Put both numbers in the report. A case that looks like vendor delay may be waiting on an internal decision that nobody has made.

Name the internal owner for each blocked step and the action required. If the owner is unavailable, name the backup. Do not use a shared mailbox as the owner unless someone is assigned to monitor it. The report should make the next action obvious to a reader who was not involved in the case. That is more useful than a general request to follow up.

Design the owner report

Lead with the cases that affect a customer, a payment, or a regulated deadline. Add the oldest case and the number of cases past their promised update date. Use a compact table with the vendor, the age, the severity, the blocked party, and the next action. Keep the technical detail in an appendix for the person who will make the call.

Ask the owner for one of three decisions per case: continue, escalate to a manager, or change the workaround. A report that does not ask for a decision will be read and archived. Record the decision and the date in the case file. The next report should start from those decisions rather than rediscovering the same stalled cases.

Make the report part of the weekly rhythm

Add the ageing report to an existing weekly operations meeting instead of creating a new review. Spend the first five minutes on cases that crossed a promised update date and the next five on the decisions required. Do not read every case aloud, because the table already carries the detail. The meeting should end with named actions and dates.

Give the vendor a short, factual summary of the oldest cases before the call with their account manager. A clear list of case numbers and promised dates is harder to ignore than a general complaint. Ask for a named engineer and a written next update for each case. Record what the vendor commits to so the next report can test it.

Review the report after a quarter and remove any field that nobody uses. A dashboard that grows without pruning becomes a reporting task rather than a management tool. Keep the fields that support a decision and move the rest to the case file. The report should get shorter as the process matures, not longer.

Limits and next use

The report measures the cases that were recorded and the dates the systems captured. It does not measure the vendor's internal effort or the customer's lost productivity. A well-managed case can still have a long wait because the fix is genuinely difficult. State that limit so the age of a case is not read as a performance score for an individual.

Use the result to fix one internal handoff and one vendor relationship. Then repeat the report at the same cadence and compare the same severity buckets. If the oldest cases are always waiting on the same internal approval, the problem is the approval design. The next study should test a shorter decision path rather than adding another reminder email.

Store the quarterly reports with the vendor contracts so a renewal conversation can use the same evidence. If a case is closed, keep the resolution date and the vendor reference in the history. A vendor review that starts from memory will repeat the same complaints. The report gives the account manager a concrete list instead of a general impression.