Requests, address changes and returns

When a customer wants to change something about an order, the assistant first verifies the order, then checks whether the request fits your company’s support rules. If it does, it collects the details, reads them back to the customer in one sentence and opens a request after the customer confirms.

Request kinds

Kind	When it can be opened (default rule)	Can it be applied on the site automatically
Address change (adres_degisikligi)	pending, approved	Yes
Delivery change (teslimat_degisikligi)	per rules	No
Urgent shipping (acil_kargo)	pending, approved, invoiced	No
Cancellation (iptal)	pending, approved, invoiced	Yes
Return (iade)	completed, within 14 days	No
Invoice change (fatura_degisikligi)	per rules	Never
Other (diger)	always	No

If the rule does not allow it, the assistant gives the customer a short reason and an alternative and does not open a request. For marketplace orders it says cancellations and returns go through that marketplace.

Each kind has fields the assistant asks for (e.g. for an address change: province, district, neighbourhood, street, building and flat). If the customer says only part of the address changes, the unchanged parts are filled from the order’s current address and the resulting new address is read back. For details that should not be taken on the phone (e.g. bank details for a refund), the assistant points the customer to your support email address.

Automatic changes on your site

When Settings → Integrations → Order automation → Apply to order automatically (address, cancellation) is on, address changes and cancellations on orders that are not yet invoiced are applied to your WooCommerce store immediately and a note is added to the order. The order is re-read live from the store before applying.

• If applied, the request opens as Completed and the console shows “Applied on site”; the order.applied webhook event is sent.
• If not, the request stays Open and the reason (“Team will apply: …”) is shown on the request.
• A request is opened in every case.

For this switch to work, your store connection needs an order write key; otherwise the console says the store connection isn’t allowed to change orders. Some flagged orders (e.g. trade-ins or split payments) are never cancelled automatically.

Returns

On a return request the assistant tells the customer your return shipping agreement code (the Return code from setup) and, if set, the carrier and a package note; if the customer asks, it sends the code by SMS or email. Return rules may work differently for custom-made products.

Follow-up by your team

• Console → Requests: filter by kind and status; search by request number, order number or name. The request detail links to the call transcript, order flags and status history. Change the status Open → In progress → Completed / Rejected. Console: Requests →
• Notifications: on a new request, an SMS/email can go to the customer (with the return code on returns) and to your team. Templates are in Settings → Notifications.
• Webhooks: request.created, request.status_changed, talep.acildi, order.applied. Webhooks →
• API: incremental pull with GET /api/v1/requests. API →
• Call back: the Call back button on a request calls the customer with an outbound call request; the number is resolved on the server and the browser only sees it masked. Callbacks →

Privacy (KVKK)

The phone number on a request is stored encrypted and shown masked in lists and the API. If your company enables personal data for the Data API, the API and webhooks send the full number.