So this page is written for the person who has to sign off on that — not for a badge wall. Here is exactly what Returnberry can see, what it can write, and what separates your workspace from everyone else’s.
Requests, orders, return authorizations (RMAs), uploaded and imported files, questionnaire transcripts and audit rows are all scoped to a workspace. There is no cross-workspace read path in the application, and no shared queue another tenant’s intake could land in.
Your helpdesk and order-system connections start read-only. Every write is a separately-toggled exception — creating an order, replying on a ticket, posting an update, resolving a ticket. Each ships switched off, and each is refused in code without an explicit authorization.
Each workspace holds its own helpdesk, mailbox and order-system credentials, encrypted at rest and never shared between workspaces. Revoke them on your side and the workspace stops reading immediately. What it already holds is covered by the retention periods below.
A model extracts fields from freeform requests, rephrases questionnaire questions, and answers a customer’s question from your own knowledge base. It is never the only path, never the decider on a duplicate, and never the source of a status your system didn’t send. Usage is metered per workspace.
Every order carries a timeline: who changed what, from what value to what value, machine or human, with how it was first read preserved through edits. Intake runs, sent batches and imports are all recorded.
[LIST YOUR CURRENT CERTIFICATIONS, AUDIT STATUS, RETENTION PERIODS, SUB-PROCESSORS AND DPA LINK HERE. Don’t claim a standard you don’t hold — an honest “in progress, here’s our timeline” survives procurement; a badge you can’t evidence does not.]
We’d rather answer it before you’re invested than after.