Reference · built on requestOperator by FibricCustomer support

Survey Timing

Holds the satisfaction survey until the order is delivered or the reply has landed. Proposes when to send it and when not to.

About

A survey sent the hour a ticket is solved asks the customer to rate a package that has not arrived. Survey Timing sits between solved and sent. It reads the solved ticket, the order it concerns, and the shipment's events, then decides whether the case is finished from the customer's side: the parcel delivered, the refund landed, the reply not bounced.

It proposes a send time for each ticket, or a skip with the reason. Your help desk's own survey is what goes out; the operator only says when. A lead approves the day's list. The record shows what the operator waited for, when it was seen, and when the survey went.

This is a reference listing. It documents what Fibric would read from Survey Timing 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 and solved_at, and whether the rating was offered or unoffered
  • Tickets in Gorgias with their satisfaction_survey, and closed conversations in Kustomer
  • Fulfillment events in Shopify: DELIVERED, OUT_FOR_DELIVERY, ATTEMPTED_DELIVERY, and FAILURE, each with happenedAt
  • The estimatedDeliveryAt on the fulfillment, so a wait has an end
  • Shipments in ShipStation by order number: shipDate, trackingNumber, and whether the label was voided
  • Reopens on the ticket, so a survey is not sent on a case that came back

Proposed actions

  • Target capability: propose sending the survey now, with the delivery event or the reply that closes the case
  • Target capability: propose holding the survey until the fulfillment reaches DELIVERED, with the estimated date as the check-in
  • Target capability: propose skipping the survey when the shipment shows FAILURE or the ticket was reopened, with the reason
  • Target capability: propose a fixed send date when nothing shipped, so a hold does not become a never

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

What you can build

  • Wait for the parcel, then ask

    A Zendesk ticket is solved but the Shopify fulfillment is IN_TRANSIT. The operator proposes holding the survey and checks the events daily. On DELIVERED it proposes the send; a lead approves the list.

    With Zendesk, Shopify

  • Skip the survey on a failed delivery

    The fulfillment shows FAILURE. The operator proposes skipping the survey and tagging the Gorgias ticket, so the customer is not asked to rate a delivery that did not happen.

    With Gorgias, Shopify

  • Follow a ShipStation label to delivery

    The label was bought in ShipStation, not the store. The operator reads shipDate and trackingNumber there, waits the transit window you set, and proposes the send with the tracking number noted on the Kustomer conversation.

    With ShipStation, Kustomer

  • Send on a date when nothing shipped

    The ticket was a question with no order. The operator proposes sending the survey on the day after solved_at, so tickets without a parcel are not held forever.

    With Zendesk

Requirements

  • A support connector whose survey the operator can hold and release: Zendesk, Gorgias, or Kustomer
  • A commerce connector with fulfillment events: Shopify or Magento
  • A shipping connector when labels are bought outside the store: ShipStation
  • Your own survey automation turned off or delayed, so the operator's send is the only one
Authentication
Runs on the credentials of the help desk, store, and shipping connectors you attach. It holds no key of its own and sends no survey unapproved.

Limits

  • Zendesk accepts a rating only on a ticket that is solved or was solved and reopened. An open ticket cannot be surveyed
  • ShipStation lists only shipments with labels bought in ShipStation. Other labels are followed through the store's fulfillment events
  • A shipment with no DELIVERED event and a passed estimatedDeliveryAt is held and raised, not assumed delivered
  • It does not write the survey or change its questions. Timing is the only thing it proposes

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 Survey Timing ↗

Questions and answers

What does a lead approve each day?
A daily list: tickets to survey now, tickets on hold with the event being waited for, and tickets to skip with the reason. The lead can move any ticket between the three. Approval releases the sends for that day only.
What record is left?
Per ticket: solved_at, the order and fulfillment watched, the event that released the send or the reason for the skip, the send time, who approved, and the rating once it arrives, so timing can be compared with score later.
Does it send surveys on its own?
No. It proposes send, hold, or skip, and a person approves. The survey that goes out is your help desk's own. If your existing automation still fires, two surveys go out, which is why that automation is turned off or delayed first.
Ask about Survey Timing

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.