A gifting program is not finished when an invitation is sent. It is finished when recipients can redeem, receive, decline, replace, or resolve a problem through a support path with clear ownership and evidence. This 2026 template turns that obligation into measurable service levels, an escalation matrix, a case log, and an operating rhythm that procurement, people, finance, privacy, security, and fulfillment teams can use together.
A support operator links recipient questions, fulfillment evidence, and escalation ownership without exposing unnecessary personal data.
Download the localized 2026 template: Excel workbook · CSV service matrix. Version 2026-09-23 v1. The workbook contains editable targets, an escalation directory, a formula-driven incident log, calculated metrics, and four clearly labeled hypothetical cases.
Define the service promise before choosing targets
A recipient support service-level agreement, or SLA, is a documented promise about how cases are acknowledged, owned, worked, escalated, and closed. It is not a guarantee that a carrier, merchant, customs authority, payment network, or recipient will act within the same clock. The useful promise is narrower: the team will respond, make the next owner visible, preserve the right evidence, communicate on a defined cadence, and recover within boundaries it can control.
Start by separating four clocks. First response measures when a human or approved automated message confirms receipt and gives a case identifier. Triage measures when severity, owner, affected population, and immediate containment are recorded. Update cadence measures how often the recipient receives a meaningful status message while the case remains open. Resolution measures when the recipient receives the agreed remedy or the case is routed to an authorized decision owner with evidence. A single “resolution time” column hides these different obligations.
Do not let support agents make decisions outside their authority. They can verify an order identifier, check a carrier event, issue an approved replacement, or collect the minimum facts for escalation. They should not decide whether a gift is taxable, whether a recipient is eligible, whether an incentive is lawful, whether a privacy request is valid, or whether a security incident is reportable. Those decisions belong to the buyer's tax, payroll, legal, compliance, privacy, security, or employment owners.
The downloadable template follows complaint-handling principles in ISO 10002:2018, which covers planning, design, operation, maintenance, and improvement of a complaints process. It also uses data-minimization and risk-management concepts consistent with the NIST Privacy Framework. These sources guide process design; they do not certify this template or replace a contract, local law, or professional advice.
Before setting numbers, agree on the service promise:
-
Every case receives a stable identifier, severity, accountable owner, and next action.
-
First response, triage, update, and resolution clocks are defined separately.
-
Business-hours and elapsed-hours rules are explicit for every severity.
-
Privacy, security, tax, payroll, legal, and employment decisions route to authorized owners.
-
Replacement, refund, resend, substitution, and decline remedies have value limits.
-
Recipient communications avoid blame, expose no internal notes, and offer an accessible channel.
-
Closure requires evidence, recipient-facing confirmation, financial reconciliation, and a reopen rule.
Use a four-level severity model
Severity should reflect impact and urgency, not how loudly a requester writes. Use the same questions for every case: Is anyone unsafe? Is personal data or account access at risk? How many recipients are affected? Is the delivery date still recoverable? Is money or cash-like value exposed? Can the issue spread? Is an executive, regulated, or vulnerable population involved? Is a workaround available?
The template proposes four levels. Severity 1 is a critical incident: suspected privacy or security exposure, fraud with active loss, an unsafe product, a mass duplicate send, or a widespread system failure blocking a time-sensitive campaign. Severity 2 is high impact: several recipients affected, a high-value or executive shipment at risk, a material customs hold, or a failed batch with no quick workaround. Severity 3 is a normal operational exception: one damaged parcel, a missing item, an address correction before dispatch, or a redemption question. Severity 4 is a low-impact request: a receipt copy, preference question, delivery guidance, or general how-to request.
Targets must be credible. A five-minute first response is meaningless if nobody is staffed to receive the alert. An aggressive resolution target is misleading when the remedy depends on a carrier trace. Establish a response target the support team can own and a recovery target that includes explicit dependency states. When a dependency takes over, the case remains owned; it does not disappear from the queue. The next update time should still be visible.
| Severity | Example trigger | First response | Update cadence | Target outcome | Required escalation |
|---|---|---|---|---|---|
| 1 — Critical | Possible data exposure, unsafe item, active fraud, mass duplicate send | 15 minutes, elapsed | Every 30 minutes until contained; then hourly | Contain or route to incident command within 2 hours | Support lead, security/privacy or safety owner, program owner, executive duty owner |
| 2 — High | Batch failure, high-value loss, material customs hold, important event at risk | 1 hour, elapsed during coverage window | Every 4 hours | Workaround or approved recovery plan within 8 hours | Support lead, fulfillment owner, program owner, finance when value is exposed |
| 3 — Standard | Single damaged, missing, late, or incorrectly addressed order | 4 business hours | Each business day | Approved remedy or dependency plan within 3 business days | Queue owner; specialist after one missed milestone |
| 4 — Guidance | How-to question, copy of receipt, preference or delivery information | 1 business day | At each material change | Answer or route within 5 business days | Queue owner; knowledge owner for recurring gaps |
Treat these numbers as a starting hypothesis. Test them against case volume, time zones, carrier coverage, inventory, language capacity, and on-call cost. If ninety percent of cases are Severity 3 but the team is measured only on the average, a few slow critical cases can hide. Report attainment by severity, locale, program, remedy, and dependency type.
Build an escalation matrix with named decision rights
An escalation matrix is more than a contact list. It specifies who owns the next action, who may approve money or risk, who must be informed, and what evidence travels with the case. Titles survive staffing changes better than personal names, but each title needs a current primary and backup contact. Test the directory quarterly and after organizational changes.
The minimum roles are intake owner, support lead, program owner, fulfillment or vendor owner, finance approver, privacy owner, security incident owner, legal or compliance owner, and executive duty owner. Some organizations combine roles; the decision rights must still be explicit. For example, support may approve a replacement below a documented value, while finance approves a refund above that amount. Privacy decides whether a request is a formal rights request. Security decides incident classification and containment. The program owner decides whether a campaign should pause.
Use event-based escalation, not only elapsed time. A case escalates immediately when it suggests harm, repeated fraud, a vulnerable recipient, a politically exposed context, a prohibited item, a sanctioned destination, a data mismatch, or a systemic pattern. A standard case also escalates after one missed milestone, two failed remedies, or a reopen. Automatic alerts should include the case identifier, severity, affected count, next deadline, and a link to controlled evidence—not the full recipient record in chat or email.
Create three boundaries. The support boundary lists remedies agents may execute without approval. The program boundary lists eligibility, value, country, catalog, and message decisions controlled by the business owner. The specialist boundary lists issues that only privacy, security, tax, payroll, legal, compliance, human resources, or safety owners may decide. This prevents urgency from becoming informal authority.
The workbook's Escalation Contacts sheet records role, primary, backup, channel, coverage hours, decision scope, and test date. Do not place personal phone numbers in a broadly shared workbook unless access is controlled and the use is approved. A durable team alias, on-call service, or case-routing queue is usually safer than a static personal contact.
Capture the minimum case evidence
Good evidence allows another trained operator to reconstruct what happened without collecting an entire employee, customer, or claimant record. The incident log therefore starts with an internal case identifier, received time, severity, program, locale, category, current owner, affected count, first-response time, resolution time, status, remedy, dependency, next update, and evidence-complete flag.
Use a separate order or invitation reference rather than pasting a home address, full email, telephone number, birth date, tax identifier, claim narrative, medical fact, employee-relations note, or security credential. If sensitive data is essential to a specialist investigation, store it in the approved system and link the controlled record. Restrict exports and decide how long support evidence remains necessary after financial reconciliation and dispute windows close.
Case notes should distinguish observation from inference. “Carrier event shows delivery at 14:10; recipient reports no parcel” is evidence. “Recipient lost the parcel” is an unsupported conclusion. Record every status change with actor and timestamp. If an agent changes severity, preserve the prior value and reason. If the team pauses a clock while awaiting recipient information, identify the policy that permits the pause and set a follow-up date; never stop the clock silently.
Evidence completeness should be binary and reviewable. A closed case is complete when it includes the approved outcome, recipient-facing confirmation, relevant shipment or redemption event, financial action, escalation decision, and next preventive action when required. The workbook calculates response elapsed time, response breach, resolution elapsed time, resolution breach, reopen status, backlog age, evidence completeness, attainment rates, and severity mix. Formulas support review; they do not replace judgment.
Follow the NIST Privacy Framework idea of managing privacy risk throughout systems and processes. In practice, define the purpose for every field, avoid copying sensitive content into free text, limit access by role, log exports, and delete evidence on schedule. If a recipient invokes a legal privacy right, route the request to the authorized privacy owner instead of promising an outcome from the support queue.
Run the case from intake to verified closure
The workflow begins before a recipient writes. Publish a localized support path in the invitation or redemption experience. State operating hours, accessible alternatives, the information needed to locate a case, and how urgent safety or security issues are handled. Avoid demanding an order number if the recipient can reasonably identify the invitation another way.
At intake, acknowledge the case and create the identifier. Validate only the information necessary to locate the transaction. Classify severity using the decision questions, assign an accountable owner, set the next update time, and identify any immediate containment. If the case may affect multiple recipients, open a parent incident and link individual cases rather than duplicating a full investigation in every record.
During triage, identify what the team knows, what remains unknown, which clock applies, and who can authorize the likely remedy. Preserve the original request. For delivery cases, review order creation, address confirmation, handoff, carrier events, and proof of delivery. For redemption cases, review invitation status, expiration, authentication, catalog availability, and duplicate controls. For value cases, review authorization, funding, issuance, redemption, reversal, and reconciliation without exposing payment credentials.
Choose the smallest effective remedy. Options include guidance, address correction before dispatch, resend, replacement, alternate item, digital substitute, delayed delivery, refund to the buyer, reissue, or respectful decline. The recipient should know what will happen, who must act, the expected time, and when the next update arrives. Never promise a carrier result or customs decision the team cannot control.
Close only after verifying the outcome. Confirm delivery, redemption, replacement, refund, or authorized routing; reconcile cost; send a final recipient message; mark evidence completeness; and set the reopen window. A closed code such as “carrier issue” is too broad for learning. Use cause categories such as bad source address, recipient-changed address, inventory mismatch, packing defect, carrier exception, customs documentation, fraud control, platform defect, configuration error, or unclear communication.
After closure, sample cases for quality. Check whether severity was correct, the response was meaningful, the remedy was authorized, personal data was minimized, updates met cadence, and the cause supports a preventive action. Feed recurring issues into catalog, integration, carrier, message, packaging, or training changes. Support is an observability system for the gifting program, not merely a cost center.
Hypothetical worked case 1: a time-sensitive welcome kit stalls in customs
Assume a new executive in another country expects a welcome kit before a public start date. Tracking shows a customs hold, and the recipient asks the people team for help. This is a hypothetical case, not Giftpack customer evidence.
Intake and severity. The agent opens one case, records the internal order reference and locale, and classifies it Severity 2 because the event date is near and the shipment has visible organizational impact. There is no safety, fraud, or data-exposure signal, so Severity 1 is not justified. The one-hour response clock begins. The agent confirms ownership and promises the next update within four hours.
Triage. The carrier event says documentation is incomplete but does not reveal which field is missing. The fulfillment owner checks the commercial invoice, item descriptions, declared values, recipient-importer requirements, and country restrictions. The agent does not ask the recipient for a passport or tax identifier in ordinary email. If an importer identifier is legally necessary, an authorized broker collects it through the approved secure path with a stated purpose.
Decision. The program owner decides that the business objective is a timely welcome, not preserving the original parcel at any cost. The team compares three recoveries: correct the documentation and continue; send a locally sourced replacement; or issue a digital welcome choice while the parcel resolves. Finance approves the permitted combined value. The recipient chooses the digital option now and the physical kit later, avoiding a surprise cancellation.
Communication. The first update explains that the shipment is under customs review, identifies the actions underway, avoids blaming the recipient, and gives the next update time. The four-hour update confirms the digital invitation and the broker's document request. The case remains owned while customs controls the release decision.
Closure evidence. The team records the digital redemption, eventual physical delivery, added freight or duty cost, approval, and recipient confirmation. The resolution clock stops when the agreed recovery is delivered, not when a carrier ticket is opened. Root cause is “customs data mapping—item description,” and the preventive action updates the country-specific invoice template. Acceptance requires no unsupported sensitive data in the support log, full financial reconciliation, and a tested change before the next shipment.
If the shipment remains blocked, the case moves to a documented dependency state with daily updates. It does not vanish from attainment reporting. A separate metric shows dependency-adjusted resolution, but the unadjusted recipient experience remains visible.
Hypothetical worked case 2: duplicate digital rewards reach a cohort
Assume an integration timeout causes an operator to retry a batch, and twenty recipients receive duplicate digital rewards. Several values remain unredeemed, but two have been used. This is a hypothetical incident designed to test containment and evidence.
Detection and severity. Monitoring flags duplicate invitation identifiers within minutes. Because value is exposed and the pattern can spread, the support lead opens a parent Severity 1 incident and links recipient cases. The integration job pauses. Security and fraud owners receive the minimum event data. The team does not accuse recipients; the failure originated in an idempotency or retry control.
Containment. Engineers stop the retry path and prevent further issuance. The value provider identifies which rewards are unredeemed, redeemed, expired, or reversible. Any revocation follows the contract and recipient-communication policy; the team does not remove value silently if the recipient reasonably relied on it. Finance reserves the possible loss. The program owner decides whether unaffected sends may continue.
Communication. Affected recipients receive a clear message appropriate to their state. Someone with two unredeemed links is told which invitation remains valid. A recipient who redeemed both is not asked to send money to an unofficial account; the case routes to the authorized finance and legal decision owners. Messages contain no other recipient's data and no internal security speculation.
Investigation. Evidence includes request identifiers, timestamps, response codes, retry policy, operator action, batch definition, affected count, issuance state, value, reversals, communications, and approvals. The technical cause may be a missing idempotency key, but process controls also matter: Did the operator dashboard distinguish “accepted” from “failed”? Did the runbook require status retrieval before a retry? Could a batch-level duplicate guard have stopped it?
Closure and prevention. Closure requires containment, recipient-state reconciliation, financial treatment, approved communication, code or workflow repair, and a controlled replay test. Acceptance evidence includes a uniqueness check on event identifiers, a simulation in which the initial request times out after acceptance, and confirmation that the second request returns the original result. The team tracks exposed value separately from final loss and reviews whether the initial Severity 1 classification was appropriate.
The case illustrates why support, engineering, finance, and program ownership need one escalation model. Fast response without financial authority leaves recipients waiting; financial action without technical containment allows the problem to repeat.
Measure performance without gaming the queue
Report the median and the 90th percentile for first response and resolution, because averages can hide a slow tail. Show target attainment by severity. Add open backlog, oldest case, reopened rate, repeat-contact rate, evidence completeness, remedy mix, dependency age, and cases per thousand invitations or orders. Segment by locale, country, program, item type, carrier, and cause only where volume protects privacy and supports action.
Define the denominator. Response attainment should include all eligible cases received during the period, including cases later merged into a parent incident. Resolution attainment should show both cases closed in the period and cohorts received in the period, so teams cannot improve the number by postponing difficult cases. Exclude spam or test cases under a documented rule, and report exclusions.
Use control limits for systemic signals. A sudden rise in address corrections may indicate a broken import. Repeated damage for one item may require a packaging test. A locale with longer resolution may lack coverage or translated carrier guidance. Multiple privacy-related contacts may indicate that invitation language is unclear. Each insight should have an owner, due date, test, and acceptance evidence.
The workbook's Metrics sheet provides a compact starting dashboard. Review it weekly during active campaigns and monthly for the portfolio. Quarterly, revisit targets, coverage, escalation contacts, remedy limits, vendors, and the knowledge base. The purpose is not to make every chart green. It is to surface recipient harm and operational debt early enough to act.
Procure and test the support model
Put the operating model in procurement evidence and contract schedules. Ask each provider to map its support hours, languages, channels, severity definitions, response targets, dependency rules, status page, incident communications, carrier escalation, replacement authority, refund flow, evidence export, retention, subprocessors, and business-continuity arrangements. Public promises are useful, but the signed service description and tested workflow control the relationship.
Run scenario demonstrations rather than accepting “24/7 support” as an answer. Submit a damaged parcel, a missing invitation, an address change after dispatch, a customs hold, a duplicate digital reward, an unsafe-product report, and a privacy request. Observe routing, authentication, communication, evidence, and approval. Test at least one non-English locale and one after-hours critical case. Record gaps and contract remedies.
Before launch, complete a tabletop exercise. Give the team a mass duplicate scenario and an unsafe-item report. Require participants to classify severity, identify decision owners, draft the first recipient message, choose containment, calculate deadlines, and list closure evidence. The exercise passes only when backups respond, evidence remains within approved systems, and unresolved questions become assigned actions.
Use this acceptance checklist:
-
Targets are staffed and tested across time zones and languages.
-
Every role has a primary, backup, decision scope, and last test date.
-
Critical cases page the right specialist without exposing recipient details in alerts.
-
Case, order, shipment, value, replacement, and refund records can be reconciled.
-
The team can recover a timeout without issuing a duplicate.
-
Localized messages cover acknowledgment, delay, replacement, decline, and closure.
-
Accessible support alternatives are published.
-
Retention, export, and deletion controls are documented.
-
Metrics include slow-tail performance, reopen, evidence, and unadjusted dependency time.
-
Release owners retain production-renderer, CMS, and runtime retrieval verification.
Adapt the template and keep ownership visible
Copy the workbook, replace the sample targets with values your staffing and providers can meet, and assign each escalation role. Preserve the formulas and sample rows until users can explain them. Then run a tabletop exercise, correct the matrix, and publish a controlled version. Log changes to targets, definitions, owners, and formulas so month-to-month results remain comparable.
The template is intentionally operational. It does not determine eligibility, tax treatment, employment consequences, legal rights, privacy outcomes, or reportable security events. Those decisions remain with authorized owners. Its job is to make intake, timing, responsibility, evidence, communication, recovery, and learning visible.
When a program needs an execution layer across invitations, recipient choice, fulfillment, and recovery, Giftpack can be evaluated against this same SLA and escalation matrix. Keep governance decisions with your legal, tax, payroll, privacy, security, and employment teams; use the gifting layer to execute approved actions and return reliable status evidence.