Decide Approve Fail / Reject Fail / Reverse as per SLA Guidelines

Purpose

To ensure consistent, fair, and SLA-compliant decisions on vendor-reported order failures, including Approve Fail, Reject Fail, and Reverse actions.

Scope

Applies to Ops Manager, Vendor Head, and SLA Handling Team for all orders where vendors have marked them as failed or where SLA violations are under review.

Frequency

• Daily: Process incoming failed order cases.

• Weekly: Review patterns of repeated vendor violations.

Responsibility

• Primary: SLA Manager / Ops Manager — decision-making on fail actions.

• Secondary: Vendor Management Team — vendor communication & documentation.

Definitions

• Approve Fail → Accept vendor’s failure reason; credits are deducted as per policy.

• Reject Fail → Disapprove vendor’s failure reason; credits are not deducted and vendor is held responsible under SLA.

• Reverse → Undo a fail action if it was approved/rejected incorrectly, restoring the order to the correct status.

---

Process Steps

Step 1: Gather Required Data

1. Open Admin Panel → Orders → Failed Orders List.

2. Check:

   • Order ID & Vendor ID

   • Failure reason selected by vendor

   • Time of status update

   • SLA timer (to check late or early failure reporting)

   • Photos, notes, or documents uploaded by vendor

Step 2: Cross-Check SLA Guidelines

Examples of SLA-based decisions:

Vendor Action / Scenario	SLA Decision	Action Type
Device locked / iCloud on, proof provided	Within SLA	Approve Fail
Device locked, no proof	SLA Violation	Reject Fail
Device not available at pickup (customer not reachable) with 3 call attempts recorded	Within SLA	Approve Fail
Vendor failed order late without proper reason	SLA Violation	Reject Fail
Vendor marked fail due to price mismatch without following requote process	SLA Violation	Reject Fail
Wrongly failed by vendor (ops error or miscommunication)	Correction	Reverse

Step 3: Decision Making

A. Approve Fail

(Vendor not at fault)

• SLA proof provided and verified

• Vendor followed all process steps (calls, photos, required documentation)

• Failure reason matches allowed SLA exceptions

Action in Admin Panel:

• Click Approve Fail → System deducts vendor credits as per fail policy

B. Reject Fail

(Vendor at fault)

• Missing or fake proof

• SLA timelines not followed

• Failure reason invalid under SLA rules

Action in Admin Panel:

• Click Reject Fail → No credit deduction; SLA violation logged against vendor

C. Reverse

(Ops correction needed)

• Incorrect action taken earlier (human error or misclassification)

• New proof received changing the decision outcome

Action in Admin Panel:

• Click Reverse → Order reverts to previous status, credits adjusted accordingly

Step 4: Documentation

• Every decision must have Notes in Admin Panel:

  • Reason for decision

  • SLA clause reference

  • Date & initials of reviewer

Step 5: Vendor Communication

• Approve Fail: Notify vendor reason was accepted; credits deducted.

• Reject Fail: Notify vendor of violation; credits not deducted and SLA warning issued.

• Reverse: Notify vendor of correction; status updated in system.

Step 6: Escalation Rules

• If vendor disputes the decision → Escalate to Ops Manager → Vendor Head.

• If more than 5 SLA violations per week for the same vendor → Follow SLA Violation Escalation SOP (may result in vendor hold or termination).

---

Quality Standards

• All decisions backed by SLA documentation and timestamped proof.

• No action taken without reviewing vendor-uploaded evidence.

• Decisions made within 24 hours of failure status update.