Reference · built on requestOperator by FibricCustomer support

Reopen Guard

Before a ticket closes, checks that the promised refund, replacement, or shipment exists. Proposes holding the close or an update.

Request accessPricing ↗

About

A ticket is solved when the agent says the refund is on its way. It is reopened when the refund is not. Reopen Guard reads each ticket about to move from solved to closed, finds the promise in the last replies, and looks for the thing promised: a refund in the payment tool, a replacement order or a shipment in the store, a label in ShipStation.

If the promise has been kept, the close proceeds. If not, it proposes holding the ticket open and an update to the customer that says what is happening. A lead approves. The record shows the promise, what was found, and what was done.

This is a reference listing. It documents what Fibric would read from Reopen Guard and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Tickets in Zendesk with status solved, their solved_at, and the public comments in which the promise was made
  • Ticket counters in Zendesk: reopens, so a case that has already come back is watched more closely
  • Conversations in Kustomer and tickets in Gorgias in their closing state, when those are the help desk
  • Refunds in Stripe: status pending, requires_action, succeeded, failed, or canceled, with failure_reason when failed
  • Refunds and totalRefundedSet on the Shopify order, and displayFinancialStatus partially_refunded or refunded
  • Fulfillments on the order and their events, LABEL_PURCHASED through DELIVERED, and shipments in ShipStation with voided and voidDate
  • Your promise vocabulary: the phrases agents use for a refund, a replacement, or a reshipment

Proposed actions

  • Target capability: propose holding the ticket in pending or on-hold when the promised refund, order, or shipment cannot be found
  • Target capability: propose an update to the customer stating what was promised and when it will land, for the agent to send
  • Target capability: propose reopening the ticket when a Stripe refund has failed, with the failure_reason in the note
  • Target capability: propose an internal note with the refund id, order number, or tracking number that keeps the promise
  • Target capability: propose releasing the hold once the promised record appears

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Hold the close until the refund succeeds

    The agent wrote that a refund was issued. Stripe shows the refund as pending. The operator proposes keeping the Zendesk ticket in pending and a note with the refund id. The close waits for succeeded.

    With Zendesk, Stripe

  • Catch the replacement that was never ordered

    The last reply promises a replacement. No new order exists on the Shopify customer since solved_at. The operator proposes holding the Gorgias ticket and a draft update for the agent.

    With Gorgias, Shopify

  • Reopen on a failed refund

    Stripe reports the refund failed with expired_or_canceled_card. The operator proposes reopening the Kustomer conversation and an update asking the customer for another way to be paid.

    With Kustomer, Stripe

  • Check the label was not voided

    A reshipment was promised and a ShipStation label exists, but voided is true. The operator proposes holding the close and flagging the order for a new label.

    With ShipStation, Zendesk

Requirements

  • A support connector with ticket read and status update access: Zendesk, Kustomer, or Gorgias
  • A payments connector for refunds: Stripe or PayPal
  • A commerce connector for replacement orders and fulfillments: Shopify or Magento
  • ShipStation, when reshipment labels are bought outside the store
Authentication
Runs on the credentials of the help desk, payment, store, and shipping connectors you attach. It holds no key of its own and issues nothing.

Limits

  • It reads promises from what was written. A promise made by phone and not noted on the ticket is not seen
  • A Stripe refund that failed shows a failure_reason. Retrying it is a person's decision, not the operator's
  • ShipStation returns only shipments with labels bought there, and a voided label counts as no shipment
  • It does not issue the refund or create the replacement. It reports that they are missing

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Reopen Guard ↗

Questions and answers

What does a lead approve before a ticket closes?
Per ticket: hold or release, and the customer update if one is proposed. The lead can edit the update or release the close anyway. Approval changes the status once and posts the note. The customer message is sent by the agent.
What record is left?
An internal note on the ticket: the promise found and where, the refund id, order, or tracking number checked, its status at the time, the decision, who approved, and when. Zendesk comments cannot be edited, so the note stands.
Does it reopen or close tickets by itself?
No. It proposes a hold, a release, or a reopen, and a person approves. Your existing close automation still runs on tickets the operator does not hold. It never issues a refund, creates an order, or buys a label.
Ask about Reopen Guard

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy