Built-in support and return requests

What a built-in request records#

Choose Create a support request or Request a return from the task starters. These providers record an operation in Reesponder rather than calling an external help desk. A support request collects the issue details; a return request also collects the order number.

The successful result includes “Recorded”, a reference and the request type. A return request is a request for review, not approval under your policy. It does not change an order, refund a payment, issue a label or email an external inbox. Connect a custom HTTP Action when those operations belong in another business system.

Use a request when the next step is a team's review, and name it accordingly. If customers expect an immediate booking or payment change, the built-in recording provider cannot make that promise.

Configure and test the request#

Use Scale and an owner or admin account. Select the website, give the request a clear customer-facing name and explain when the assistant should offer it. Email verification and confirmed-write mode are required for this provider; they cannot be disabled.

Save the draft and run a test with sample details and a test email. The write-test acknowledgement is still required because the test records a real request in Reesponder. Review the recorded type and reference, then enable the current revision. Tests are labeled in activity and are removed after 24 hours.

Choose collection fields your team will actually use to investigate. A vague request containing only “help” is difficult to handle; an unnecessary copy of credentials or payment details should never be requested.

The customer submission#

A customer can ask for help or a return in chat. Reesponder collects the configured fields, shows the email verification controls and displays the final details for confirmation. The customer selects Confirm & submit or cancels the pending operation.

After successful execution, the request starts in the open state with the verified email attached. The recorded contact address comes from the verification flow, not an unverified email the assistant happened to collect in ordinary chat. If the proposal expires before confirmation, ask for a fresh request and review its details again.

The success reference identifies the recorded run. It is a useful correlation value for the customer and team, but it does not become an external help-desk ticket number unless your separate integration created one.

Review and resolve in the workspace#

Open Actions → Activity & requests, select Refresh and expand the recorded run. Check the request details and verified email. Use Email customer to open your email client, then follow your own policy and process.

Select Mark resolved after the team has handled the request. A resolved request can be reopened. This team status does not execute a refund or update a provider order; it tracks your handling of the recorded request. The execution status remains the result of recording it.

The activity page shows the latest sixty runs across the workspace, including tests. Build a real review routine rather than assuming that a request remains prominently visible forever or that a notification has been sent automatically.

Distinguish requests from human handoff#

The widget’s Talk to the team form is a separate human-handoff feature. It asks for email, phone and permission to share the conversation, then follows the configured escalation-delivery process. A built-in Action request remains in Actions activity and does not inherit that email delivery automatically.

Choose the feature that matches the promise you want to make. If you need an external ticket, use an endpoint that creates that ticket and returns its real reference. If you need a team to review a stored request, the built-in provider is suitable. Ensure someone checks incoming activity before enabling it for customers.

Make the destination clear in Knowledge and customer-facing descriptions. A team inbox handoff and a workspace request may both be useful, but their delivery and review responsibilities are different.

Keep the review window in mind#

Visitor request inputs, results and contact follow the associated conversation’s retention. When that conversation is invalidated, its Action inputs and contact are scrubbed, and outstanding operations are cancelled or reconciled to their recorded state. Do not use an expiring chat record as your permanent returns ledger.

Move any information you need for a long-running business process into your own appropriately controlled system before expiry. Deleting an Action definition preserves its existing activity subject to retention; it does not extend the record’s lifetime.

The selected workspace retention may be shorter than the plan's maximum. Design your review window around the actual setting, and transfer a continuing case to your controlled business system before the associated conversation expires.

Worked example: a return request that needs review#

Your policy allows eligible customers to request a return within a defined period. Put those public conditions in Knowledge. Configure a built-in Request a return Action to collect the order number and reason, with a customer-facing description that says the team will review the request.

The visitor verifies their email and confirms the prepared details. Successful execution records an open request with its reference and verified contact. It does not inspect every eligibility condition in the order system, approve a refund, issue a shipping label or email an external returns inbox.

A staff member opens Activity & requests, checks the recorded details and investigates in the store's authorized tools. Email customer opens the staff member's email client; it is not evidence that Reesponder already sent a response. After handling the case according to policy, the staff member marks the request resolved.

If the process continues beyond the chat retention window, copy the necessary case data into your controlled returns system before expiry. Keep the customer's expectation accurate throughout: the request was recorded for review, and any refund or label comes from the owning business process.

Check both submission and team handling#

Use sample details and your own email to complete the live verification and confirmation flow. Confirm the request reference and open state in activity, then test Email customer, Mark resolved and Reopen as staff controls. Those controls manage handling; they do not change the execution result or update an order.

Confirm who reviews new activity, what the customer is told about next steps and where long-running cases are retained. Test cancellation before submission and distinguish built-in recording from the separate human-handoff delivery path.

Design the request around a real review process#

Before enabling, choose the person or team who checks workspace activity and the information they need to decide the next step. A useful support request might contain the affected product or service and a short description. A return request needs the order reference and reason, but collecting them does not by itself establish refund eligibility.

Set a customer-facing promise that your team can fulfill. The built-in result confirms recording, not a guaranteed response time, approved outcome or external notification. If you describe a review timeframe in Knowledge, make sure the team actually operates that process.

Decide how staff will communicate and where they will keep an ongoing case. The Email customer control opens their configured email client. If you require automatic delivery into a help desk or case-management system, create a custom HTTP Action whose endpoint performs that delivery and returns its real reference.

Keep request fields small and purposeful. The configured Action can collect at most eight input strings, each within its limit. Avoid asking customers for passwords, payment credentials or full documents in a short request field. Direct complex evidence exchange through your established secure support process.

Read the two states and preserve the case deliberately#

A built-in request has an execution state and a team-handling state. Execution succeeded means the request was recorded. Open means staff still have a handling task. Resolved means someone marked that task handled. Reopening changes the handling state without replaying the submission or changing a provider order.

For example, a return request can be successfully recorded and later declined under your policy. Marking the review resolved can be appropriate after communicating that decision, but it should not be presented as a refund approval. Keep the decision in the business case record and use factual wording with the customer.

Visitor request details, results and contact are tied to conversation retention. When that conversation expires or is invalidated, linked Action content is scrubbed and outstanding operations are cancelled or recorded as uncertain as applicable. Deleting the Action definition does not extend historical content retention.

Move only the information needed for an ongoing case into your controlled system before expiry. Tests are labeled separately and removed after twenty-four hours; do not let test requests become unattended real support work. Review the latest-runs view frequently enough to find customer requests promptly and maintain your own case ledger where required.