What to Do When a Vendor Says “It’s Not Us” (Escalation Playbook)

Last updated
April 29, 2026

Reviewed by:
IT Service Delivery Lead

Speakable Summary

When a vendor says “it’s not us” you need evidence and a clear escalation path. This playbook keeps ownership clear and shortens downtime.

Opening

“It’s not us” usually means the vendor does not have enough evidence to own the problem. It can also mean the issue is shared across systems and each party is protecting their boundary.

Most SMB downtime stretches out because the office becomes the messenger between vendors. Calls get repeated, details get lost, and no one owns the timeline.

This playbook shows what to do in the first hour, what evidence to collect, what to say, and how to escalate without making the problem worse.

Direct Answer

When a vendor says “it’s not us” respond with timestamps, symptoms, and a clear request for next steps. Escalation works faster when one ticket tracks evidence and ownership.

‍

What’s included vs what’s usually extra

‍

●    Open one internal ticket and assign one owner

●    Capture evidence before making changes

●    Document the final root cause and prevention step

Included means running the escalation process and keeping the timeline clean. Extra means vendor replacement and large redesign work that needs a separate scope.

‍

Escalation playbook

Step 1: Confirm impact and open one ticket
Confirm who is impacted and what workflow is down. Create one internal ticket that becomes the system of record.

Step 2: Freeze random changes and capture evidence
Stop uncontrolled troubleshooting that destroys proof. Capture screenshots, error messages, and timestamps first.

Step 3: Identify the boundary and the likely owner
Decide whether the issue smells like ISP, firewall, DNS, Microsoft 365, VoIP, or the line of business vendor. Record the current best guess and why.

Step 4: Open the vendor case and demand a case number
Open the case with the correct vendor and record the case number. Ask for the current SLA target and the next update time.

Step 5: Provide proof and request a specification
Share the evidence and ask for one specific next step. Examples include checking outage dashboards, reviewing logs, or validating account status.

Step 6: Escalate with a clear request and deadline
If the vendor refuses ownership, request escalation to a supervisor. Ask for written confirmation of what they checked and what they need next.

Step 7: Close the loop and document prevention
Confirm resolution with users and log the fix. Document what caused the issue and what will prevent repeats.

‍

Who owns what

‍

Vendor escalation preparation for this week

●    Build a vendor map with contacts,portals, and escalation paths.

●    Confirm credential ownership and MFA for every vendor portal.

●    Require vendor incidents to betracked in tickets with closeout notes.

‍

Common failure points and fixes

●    Multiple people call the vendor and fix it by assigning one owner and one caller.

●    Evidence is missing and fix it by capturing timestamps and screenshots first.

●    Changes destroy proof and fix it by freezing changes until logs are captured.

●    Vendor refuses escalation and fixit by requesting supervisor review and written checks.

●    Portal access is missing and fix it by enforcing credential ownership and vaulting.

●    No closeout notes exist and fix it by requiring root cause and prevention notes.

‍

Common Questions

Do I need an escalation playbook if we have vendor support?

Yes because vendor support still needs evidence and ownership. A playbook keeps your timeline and requests clear.

Do I need one person to own vendor escalation?

Yes because shared ownership causes delays. One owner keeps updates and next steps consistent.

Do I need to call the vendor or can IT do it?

IT should usually call and manage the case. The office should confirm impact and priorities.

What’s the difference between an internal ticket and a vendor case?

An internal ticket tracks the whole incident. A vendor case tracks the vendor side only.

What’s the difference between escalation and troubleshooting?

Troubleshooting tests causes locally. Escalation forces vendor action with evidence and timelines.

What happens if the vendor refuses to escalate?

Ask for the escalation path and supervisor review. Request written confirmation of what they checked.

What happens if two vendors blame each other?

One owner runs parallel checks and shares evidence. The goal is to isolate the boundary and force a decision.

What happens if the issue is intermittent?

Intermittent issues require timestamps and patterns. Monitoring and logs make escalation easier.

What happens if the vendor asks us to change settings?

Change only with change control and documentation. Capture before and after evidence in the ticket.

What happens if we do not have portal access?

Resolution slows or stops. Credential ownership prevents lockouts and delays.

What happens if we keep having the same vendor issue?

Repeated incidents require a prevention plan. That can include standards work or a vendor change project.

What happens during a business down incident?

Open a high priority ticket and start escalation immediately. Provide timed updates and documented actions.

Can vendor escalation reduce downtime?

Yes when it is evidence driven and owned. Random calls without proof usually waste time.

Can vendor coordination reduce surprise invoices?

Yes because project work is separated from operations work. Clear approvals prevent surprise charges.

‍

Key terms, in plain English

Vendor boundary: The part of the system the vendor owns and supports.
Escalation: Raising priority with evidence and timelines.
Ticketing system: The record of work, ownership, and outcomes.
Closeout notes: The summary of what changed and why it worked.
Change control: Documented approval and tracking for changes.
SLA: Response targets tied to priority.
Credential ownership: The business controls admin accounts and passwords.
Business continuity: Keeping work moving during disruption.

‍

Choosing the next action for a vendor issue

‍

Vendor support and escalation approaches

Escalation with proof vs escalation by opinion

Proof driven escalation uses logs and timestamps. Opinion driven escalation creates blame and delays.

Vendor support vs managed escalation

Vendor support handles their system boundary. Managed escalation coordinates boundaries across vendors.

‍

Vendor escalation checklist

• Open one internal ticket and assign one owner
• Capture timestamps, symptoms, and screenshots
• Document last known good time and recent changes
• Identify the likely vendor boundary
• Open the vendor case and record the case number
• Ask for the next update time and escalation path
• Provide evidence and request one specific action
• Track every update and decision in the ticket
• Close with root cause and prevention step

Common mistakes

• Calling vendors without evidence and fix it by capturing timestamps and logs first.
• Letting many people troubleshoot and fix it by assigning one owner and change control.
• Accepting vague vendor answers and fix it by requesting written checks and next actions.
• Losing case numbers and fix it by tracking everything inside one ticket.
• Allowing vendors to own credentials and fix it by enforcing credential ownership and MFA.

Common objections

We do not want to be difficult. Clear escalation is professional and normal during downtime. Evidence keeps it respectful and fast.

The vendor never helps anyway. Vendors respond better when you provide proof and specific requests. Escalation paths exist for a reason.

We do not have time to document. Documentation saves time during the next incident. It also prevents repeats.

We worry changes will break things. Change control reduces that risk. Evidence before changes protects you.

We can just switch vendors. Switching can help but it is still a project. Escalation and trends should drive that decision.

‍

What affects vendor escalation

• It depends on how many vendors touch the workflow.
• It depends on whether you have portal access and credential ownership.
• It depends on monitoring and log availability.
• It depends on SLA terms and escalation paths.
• It depends on how standardized the environment is.
• It depends on how often the issue repeats and needs prevention work.

How we manage vendor escalations

We run escalations through one ticketing front door with a single owner and a clear update cadence. We capture evidence first and use change control so we do not destroy proof during an incident.

We reduce repeat vendor incidents through standards, patch management, and documented escalation paths. Practical controls align to NIST standards without heavy process.

If recovery is involved, we use backup monitoring and restore testing proof rather than assumptions. Business continuity improves when incidents are documented and trends are reviewed.

‍

How we measure vendor escalation performance

• Time to open vendor cases
• Vendor response time by priority
• Business down duration
• Repeat incident rate by vendor
• Documentation quality in closeout notes

‍

FAQs

What should we say when a vendor says “it’s not us”?

Ask what they checked and what evidence they need next. Provide your timestamps and request a specific action.

What is the first piece of evidence to capture?

Capture the time the issue started and who is impacted. That anchors the escalation timeline.

Should we change settings while the vendor investigates?

Only with change control and documentation. Uncontrolled changes can destroy evidence.

How do we handle two vendors blaming each other?

Run parallel checks and share proof. Force each vendor to state what they confirmed in writing.

What if the vendor will not escalate?

Request the escalation path and supervisor review. Ask for written confirmation of what they checked.

How do we prevent repeat vendor incidents?

Track trends and document root cause. Use that evidence to justify prevention work or vendor changes.

What should be documented in the closeout?

Document root cause, timeline, and what changed. Document the prevention step and the vendor case number.

Who should own portal access and credentials?

The business should own credentials and admin access. Use MFA and secure vaulting to control access.

Does this process work for Microsoft 365 issues?

Yes because Microsoft cases still require evidence and timelines. Good ticketing and clear requests speed action.

What is a Fit Check?

A Fit Check maps your vendors to clear ownership and escalation paths. It clarifies priorities and next steps.

‍‍

Call to action

If vendor issues keep turning into blame loops, book a Fit Check. You will get a vendor ownership map, an escalation playbook, and next steps you can act on.

‍

‍