Security and privacy
What we hold, who can read it, and what we have not settled yet
A phone agent hears things. This page says what happens to them. Where a question is still open it says that instead of rounding it up to a reassurance.
Three things are not settled, and they are the three you would ask about
Where things run
Residency, honestly
TurnTaker is built for Australian businesses and we intend Australian processing. We do not claim it, because we cannot yet prove it.
What we know
Calls arrive on an Australian carrier number and the media path is pinned to an Australian region. The database and the dashboard run in a region we choose.
What we do not know
Our carrier does not publish where the speech and language models behind its endpoint actually run. Until they answer, we record that leg as unverified rather than as onshore, and you should read it that way.
If a model or carrier we use fails mid-call, we can fall back to a second supplier. In production that fallback is switched off, and it stays off until the legal review and the carrier’s answer are in — because a fallback would send a caller’s audio somewhere the notice they heard did not mention. [REVIEW: confirm this paragraph still holds at launch]
What is collected
From a caller, and from you
Every caller hears that they have reached an AI and hears a collection notice, on every call, before anything else happens.
The caller's number
As the carrier presents it, with a history of their previous calls to the same business so a repeat caller is not asked everything twice.
What was said
A transcript with the timing of each turn, so the call can be read back and the call wall drawn from it.
The recording
Where the line is set to record. What the caller is told at the start of the call follows that setting exactly.
What was taken
A message or a callback request: a name, a number and what it is about, plus whether it met your criteria for urgent.
What the agent did
Every tool call with its timestamp — a lookup, a text sent, a transfer attempted — the outcome of the call, and which of your rules decided it.
Your account
The people you have given access to, what they changed and when. Every change by us is in the same log with our name on it.
How long
Retention
Four classes, each with its own clock, and each able to be shortened for your business. The figures below are our working defaults and are not final.
| What | Working default | Status |
|---|---|---|
| Recordings | 90 days | Working default, not yet reviewed |
| Transcripts | 12 months | Working default, not yet reviewed |
| Call records and totals | Indefinite | The row without the words in it |
| Anything you delete | On request | Per business, shorter than the above if you ask |
Recording is a per-line setting rather than a product-wide one, and what a caller is told changes with it: the opening notice is built from that setting at the moment the call is answered, so a line that is not recording never tells anybody it is. [REVIEW: whether recording is on by default for new clients]
Who can read it
Access
Separation between businesses is enforced by the database, not by the code that queries it.
One business cannot read another
Every table carries the business it belongs to and every read is filtered by the database itself, on the session doing the reading. A query that forgot to filter returns nothing rather than somebody else's calls.
We are not you
Our staff accounts are a separate table on a separate path from your team's, and we do not impersonate anybody. When we change something on your account it is recorded as us.
Your team, by role
An owner runs the account and manages who else is on it. A manager runs one location. A member reads, and works the queue. Roles are rows in the database, so a change takes effect on the next query rather than the next sign-in.
Sign-in is a link, not a password
We email you a link. There is no password to reuse, leak or rotate, and nothing for us to store badly.
Who else touches it
Suppliers in the path
Telephony, speech, language models, email, hosting and error monitoring. Each is named, with what it sees.
How we build
Practices, not certifications
We hold no security certification and we are not going to imply one. Here is what we actually do.
The key that reads everything never reaches a browser
The dashboard holds a publishable key and the database decides what it can see. The privileged key lives only in the worker that answers calls, and a test fails the build if it appears anywhere else.
Secrets live in one place
A secrets manager, per environment, never in the repository. A scanner runs over the build output looking for a value that should not be there, and it reports the name rather than the value.
Nothing publishes itself
A change to what your agent says reaches a caller only when a person publishes it, and the database has no path that could do it without one.
Faults become a queue, not a page at 3am
A transfer number that cannot be reached, a notification we could not deliver, a call that fell over — each becomes an item we work, with the call attached.
Ask us the awkward one
If there is a question here we have not answered, it is because it is still open. Ask it and you will get the state of it rather than a brochure.