An Intercom conversation can flag a possible service-recovery gift, but it should not authorize one. Treat the webhook as an invitation to review a documented incident. A human owner decides whether a remedy is appropriate, checks whether a gift would complement rather than replace the actual fix, and approves a limited offer only after the customer has a clear choice about contact and delivery details. The resulting system needs a stable case key, a permissioned approval queue, an explicit refusal path, and a record of what happened after dispatch.
This guide is for support-operations managers and integration engineers designing that boundary. It addresses event selection, signature verification, suppression, privacy, approval, replay, fulfillment, and reconciliation. The examples are hypothetical operating decisions, not customer results or claims of a built-in connection between Intercom and any gifting platform. The Intercom webhook documentation explains how apps subscribe to events; the topic reference defines notification behavior. Confirm the API version, scopes, and exact payload in your own app before deployment.
Start with the remedy, not the trigger
A gift can acknowledge inconvenience, but it cannot repair a missing shipment, fix access, reverse an incorrect charge, or settle a complaint by itself. Define the primary remedy first. For each eligible incident category, specify the operational owner, the service action, the customer's preferred follow-up channel, and the conditions under which an additional gesture might be considered. If the customer has asked not to be contacted, if the issue is disputed, or if the proposed gift could create a conflict of interest, the gift path stays closed.
Do not use a low rating or emotional wording as an automatic entitlement. Ratings are context, not a complete account of harm. A delayed reply and a prolonged outage may both produce frustration but require different remedies. Conversely, a customer who is polite may have experienced serious loss. The review should use a small set of recorded facts: incident category, service impact, status of the actual resolution, prior remedy, proposed budget band, recipient eligibility, and documented reason for the decision. Keep free-text transcripts out of the gifting handoff unless a specific reviewed need justifies them.
Write a policy with three outcomes: no gift with the service fix alone; review pending while the incident is investigated; or an approved, optional gesture after the service fix. The policy should let an agent explain a refusal without blaming the customer or presenting the gift as compensation for legal rights. A supervisor should be able to compare similar cases and see why their outcomes differed. Exceptions need a named approver and an expiry, not an invisible override.
Choose an Intercom event that opens review, not dispatch
The official Intercom topic reference lists conversation events including customer replies, admin replies, assignment, closure, priority changes, and ratings. A conversation.user.replied notification can indicate that a customer responded; conversation.rating.added can indicate a rating; an admin closure can indicate a workflow change. None proves that a remedy succeeded, that a customer wants a gift, or that the sender may process shipping data. Choose the smallest event set that provides a useful review signal. A support team may begin with a reviewed tag or case classification inside its own process rather than subscribing to every incoming message.
Intercom subscriptions belong to an app and can deliver notifications from workspaces where that app is installed. Public apps may need approved permission scopes; a private app's access is different. The topic reference associates conversation topics with conversation-read permission. Record the app, workspace, subscribed topics, version, scope owner, endpoint owner, and secret custodian before enabling a production endpoint. A change to a topic or version should be treated as a schema change, not a routine content update.
The receiver should verify the X-Hub-Signature against the unmodified request body using the app secret, following Intercom's documented HMAC-SHA1 format. Compare the computed value in constant time, reject invalid signatures, and rotate the secret through a controlled process. Do not log the secret or the complete customer message. After verification, validate the notification's app and topic and map it to a minimal internal event. Keep the raw payload in a restricted retention area only if a defined diagnostic purpose requires it; otherwise retain only the reference and processing outcome.
Intercom's current reference describes a five-second response deadline, a limited retry after most failures, and different handling for 429 and 410. That makes a fast durable intake important. A receiver can acknowledge only after it has recorded the verified event in a reliable queue; the slow policy review and gift decision happen later. If intake storage is down, fail visibly and reconcile the gap rather than pretend that a successful HTTP response means a case was reviewed. Monitor subscription health and dropped events. Do not rely on provider retries as the only recovery mechanism.
Build a narrow state machine and durable case key
Use a state model that distinguishes a notification from a decision. A practical sequence is received → verified → candidate → suppressed or review pending → approved or declined → invited → accepted or declined by recipient → dispatched → delivered or exception → reconciled. A service issue may return to investigation after any stage; a gift must never erase that service status. Every transition records actor, time, reason, source reference, and version. An approval applies to a specified offer and budget, not an open-ended permission to resend.
Use the provider notification ID to deduplicate transport retries. Then use a separate business key, such as tenant, conversation ID, incident category, and recovery episode, to prevent two distinct notifications about the same underlying incident from opening two offers. Those keys solve different problems. If a customer replies three times in one episode, there may be three valid notifications and only one candidate. If the case is reopened weeks later after a new incident, the policy owner must define whether the episode changes. Store a supersession link so a later approved offer does not duplicate an earlier dispatched one.
The case ledger should hold the Intercom workspace and conversation references, topic, notification ID, episode key, event time, service owner, current remedy status, decision reason, permitted budget, approval identity, offer version, invitation status, fulfillment reference, exception status, and reconciliation time. It does not need the full conversation transcript, sentiment score, or postal address to decide whether review should open. Separate the contact record from shipment details and grant access only to the people who need each stage. A deletion or correction request must be routed to the designated privacy owner across both systems.
State and owner matrix: the following rows show the minimum evidence required before each transition.
| State | Owner | Required evidence | Allowed next action |
|---|---|---|---|
| Candidate | Support lead | Verified event, incident category, stable episode key | Review or suppress; never dispatch |
| Review pending | Case owner | Primary remedy status, prior offers, eligibility | Approve a bounded offer or decline with reason |
| Approved | Budget approver | Named approver, value band, expiry, recipient channel | Send an optional invitation |
| Accepted | Recipient operations | Recipient choice and only required fulfillment data | Hand approved details to the fulfillment path |
| Reconciled | Support and finance | Offer outcome, spend, exception and service outcome | Close or investigate a mismatch |
The table is an implementation template, not a claim that Intercom or a gifting platform exposes these exact states. Map each state to your own access controls, logs, and service terms. If an integration is not separately verified and contracted, use a reviewed export or manual approved handoff instead of inventing an API call.
Make the privacy handoff deliberately small
Support conversations are collected to handle a service matter. Gifting may be a related but distinct use, depending on the original notice, relationship, market, and program design. Ask a privacy owner to decide the appropriate basis and notice before moving customer information to another system. A customer who accepts help has not automatically agreed to receive a physical gift or share a delivery address. Make the invitation optional and keep a no-gift alternative where appropriate.
For a review candidate, send only a pseudonymous case reference, country if needed for eligibility, allowed value band, approved remedy category, and an expiry. When the person accepts, obtain shipping details through an appropriate recipient flow rather than copying an address from a support transcript. Do not pass ticket notes, allegations, payment details, health information, or the entire conversation to a fulfillment provider. Set deletion and retention rules for abandoned invitations and returned parcels. Make a clear controller/processor and access-responsibility map for each market instead of assuming the support and gifting systems share a single legal role.
The European Data Protection Board's basic principles describe purpose limitation, minimization, storage limitation, and accountability. Taiwan's Personal Data Protection Act, Article 5 states that collection and use should stay within what is necessary for a specific purpose. Japan's Personal Information Protection Commission guidance is a primary reference for handling and outsourcing personal data. Korea's Personal Information Protection Commission guidance emphasizes minimum collection, purpose-limited processing, safeguards, and disposal after purpose completion. These sources support a cautious design; they do not turn this article into legal advice or determine the lawful basis for a particular company's program.
For cross-border service recovery, maintain a market matrix: sender entity, recipient country, notice language, fulfillment path, data fields, access owner, retention rule, and any local review. If a country cannot be supported under the approved program, offer a non-shipping alternative or decline the gift path while still completing the service remedy. A failed address validation should not cause the team to reopen transcript access broadly; send a narrowly scoped correction request through the approved channel.
Worked decision one: a delayed replacement after a defective order
Hypothetical case: a customer reports that a replacement item promised for an event arrived after the event. A reply webhook reaches the receiver twice because the first delivery was not acknowledged. The support record has a product issue, a replacement order in transit, and a prior shipping-credit offer. The customer has not requested a gift. The goal is to resolve the purchase problem first, then decide whether an optional gesture adds value.
The intake owner validates the signature, records the notification ID once, and links both attempts to one conversation episode. The support lead checks the replacement and credit status. If the replacement is still missing, the case stays in service-remedy work, not gifting approval. When delivery is confirmed, the lead considers the additional inconvenience, checks that no gift was already sent for the same episode, and proposes a modest choice within the policy band. A budget approver sees only the case summary and prior-offer indicator. The customer then receives a message that makes the gift optional and does not suggest it extinguishes any remedy.
The alternative is no gift: a clear apology, correct replacement, and confirmed credit may be the better response if the customer prefers closure. A physical parcel could be inappropriate if the customer is traveling or does not want to share an address. A limited recipient-choice invitation can reduce assumptions about taste, but it requires an approved catalog and expiry. The decision log records why the selected path fits this incident, not a generic rule that every late shipment earns an item.
Failure path: the second webhook opens another candidate because a downstream worker used notification ID alone and did not check the episode key. The queue detects an existing pending offer, suppresses the duplicate, and links the new event to the first case. If an invitation was already sent, a supervisor reviews whether the second message is a legitimate new incident before any further offer. Acceptance evidence is one remedy record, one decision, no duplicate dispatch, customer choice or refusal recorded, and a reconciliation entry linking the service resolution and any gift spend. A dashboard that only counts invitations would miss the error.
Worked decision two: a severe complaint with no consent to a gift
Hypothetical case: a customer gives a low conversation rating after repeated outages and writes that they do not want promotional contact. The rating event is a valid signal for a support-quality review, but it is not consent for a gift. The account team also reports an unresolved billing dispute. The service owner assigns an incident manager to fix access and billing and marks the gifting candidate suppressed. A supervisor reviews whether a separate apology should be offered through the existing support channel, without using the gift workflow.
The tradeoff is uncomfortable: a gift can feel responsive to the sender but coercive or distracting to the recipient. A tailored credit, documented remediation, or executive explanation may be more appropriate. An automated “sorry” parcel would require an address and might contradict the customer's stated preference. The team should not treat gift refusal as a negative customer-success metric or penalize an agent for respecting it. If the customer later expressly requests a gesture, the team can open a new review with fresh notice, eligibility, and approval rather than retroactively reclassifying the earlier rating event.
Failure path: a broad rule sends all low ratings into a gift queue, and an operator starts composing an invitation before noticing the no-contact preference. The review gate halts the invitation, records a suppression reason without duplicating the full complaint, and alerts the service owner to the underlying outage. If a message escaped, the incident owner follows the communication-error process and prevents another send; the gift ledger is not silently erased. Acceptance evidence is a resolved or actively managed service matter, a documented no-gift decision, no unnecessary address collection, and a correction of the broad rule. This is a successful controlled workflow even though the gifting count is zero.
Replays, reconciliation, and acceptance tests
Plan recovery before launch. Keep a restricted queue of verified event references and processing outcomes. If an intake process fails after acknowledging a webhook, an operator needs a documented way to identify the missing interval and reconcile it against the source system. If an event is replayed, rerun signature and schema validation on the stored original or obtain a fresh authorized source read; do not alter the business episode key to force another offer. Mark replay actor, cause, original notification ID, and resulting transition. A replay should be safe when the gift has already been dispatched.
Test at least these cases: identical notification delivered twice; two different notification IDs for one conversation; a reopened conversation in a new episode; invalid signature; unexpected app or workspace; unsupported topic; old API-version payload; missing consent or notice; approval expiry; rejected budget; declined invitation; failed address correction; fulfillment timeout; and a manual refund already issued. Check both the support system and the spend ledger after each test. A green HTTP response is only evidence of accepted intake, not evidence of policy approval or gift delivery.
Set simple measures with denominators: eligible incidents reviewed, candidates suppressed, approvals by reason, invitations accepted or declined, duplicate attempts blocked, approval-to-dispatch time, unresolved fulfillment exceptions, and service outcomes. Review whether certain customer groups or geographies are receiving systematically different offers. Investigate differences with context before concluding bias or effectiveness. Do not claim that gifts caused higher satisfaction from a before/after chart without a defensible study design. Use the recipient data operations guide for a broader data-control framework and the gifting measurement framework for measurement design.
Minimum replay and exception checklist
Confirm the original notification ID and verified signature; inspect app, workspace, topic, API version, conversation and episode key; read the current service remedy and prior-offer ledger; preserve the original approval version and expiry; replay only the missing transition; check whether an invitation or shipment already exists; record operator, reason and resulting state; reconcile support and spend records before closing the exception.
Where a gifting platform fits, and where it does not
A support team can operate this policy with a manual approved fulfillment queue, an internal store, or a gifting platform. Compare each option on the same questions: how the approved budget is enforced, what recipient choice is available, whether the country is supported, how addresses are gathered, how exceptions are surfaced, and what evidence returns to the case ledger. A manual queue may be best for rare, sensitive cases because it is easy to keep human judgment central, though it needs careful reconciliation. An internal store may be efficient where catalog and shipping are narrow, but requires its own inventory and privacy controls. A platform can help when approved offers span countries or catalogs, but only if the exact integration and reporting scope are verified in a pilot.
Giftpack's public FAQ describes configurable budgets, eligible countries, recipient choice, and fulfillment paths. Those capabilities make it a possible execution layer after the employer or service team has decided the remedy and approved the offer. They do not prove a native Intercom connector, automatic eligibility decision, regulatory compliance for a particular program, or a guaranteed item in every market. Validate contract terms, privacy roles, country coverage, available catalog, pricing, exception exports, and the handoff method with a live test. If the intended route is manual, state that explicitly to operators and do not disguise a spreadsheet transfer as a supported API integration.
A useful pilot starts with a small set of resolved cases and an explicit no-gift control path. Before launch, support, finance, privacy, and fulfillment owners approve the policy, data map, budget, and exception response. During the pilot, reconcile every candidate and every approved dispatch rather than sampling only successes. Stop the gift path if duplicate prevention fails, a privacy notice is inadequate, or a vendor cannot return the status evidence needed to close the loop. The service remedy continues regardless.
Conclusion: make the gift a reviewed consequence, not an automatic reaction
The safest Intercom-to-gifting workflow converts a verified conversation event into a narrow review candidate. It does not infer entitlement from a complaint, move an entire transcript to fulfillment, or assume that delivery proves service recovery. Stable episode keys, separate approval, optional recipient choice, and reconciled exception records let support teams be thoughtful without losing control. For the underlying operating architecture, see the global corporate gifting operations hub. If an approved program needs multi-market choice and fulfillment, Giftpack can be evaluated as the execution layer after the support, finance, and privacy owners set the rules; it does not replace their decisions.