Workspaces stay separate, access is governed through authentication and setup, and conversations stay attached to controlled operational records that you can delete.
Last updated
Kasper is built around isolated workspaces. Data, setup state, knowledge, tickets and operating settings belong to the workspace they were created in, and one workspace does not cross into another.
That is a property of the schema rather than of the application’s good behaviour: every record carries the workspace it belongs to, every query is scoped by it, and the database enforces the same boundary independently through row-level security policies.
For the people who use Kasper: a name, an email address, and the record of what they did inside their workspace. For the people who call your business: whatever the conversation contains — the audio, its transcript, the summary, the phone number it came from, and anything the caller told the agent.
That last category is your data, not ours. You decide what the agent asks for, what it records, and how long any of it is kept. We process it to answer the call and to give you the transcript, the summary and the ticket afterwards.
We do not use your conversations or your knowledge to train models, and we do not sell anything to anybody.
People create an account, complete a setup flow, and reach the surface their role and workspace membership allow. Access is governed by authentication, an explicit role, and workspace-specific routing rather than one shared dashboard everybody lands on.
Every permission is checked on the server for every request. What an interface shows or hides is presentation and is never what stops an action.
Privileged actions are written to an append-only audit log with who performed them and when, which is readable by the workspace they happened in.
Calls, transcripts, summaries, tickets and follow-up records are tied to workspace operations and retained as part of the product’s workflow. They are operational records attached to workspace context, workflow history and controlled access — not decorative data points.
Where a conversation happens on a third party’s network — a phone call, a WhatsApp message — that provider necessarily carries it. Who those providers are is on the security page and in the sub-processor schedule we give you before you sign anything.
Recordings and transcripts have a retention period you configure, and they are deleted automatically when it expires. Recordings and transcripts can be set separately, because wanting to keep one and not the other is normal.
You can delete a conversation, a caller, or a caller’s entire history, and the deletion reaches the records attached to it. A full export of your workspace’s data is available on request.
If a caller asks you to remove what they said, you can do that yourself without contacting us.
The product is setup-first. A workspace is configured before it goes live, so channels, permissions and operating rules are reviewed deliberately rather than switched on by default.
That model exists to reduce uncontrolled launches and to make it clear who can reach what before anybody outside the business can reach anything at all.
Public contact and support routes exist for sales, rollout and product questions, and they do not replace the controls inside an authenticated workspace.
For anything privacy-specific — a request about your own data, a question about a sub-processor, or a data-protection assessment — the contact form reaches us and we will answer it properly rather than with a template.