How we handle data.

What the analysis reads

Only what is needed to answer one question, which is what customers are asking for.

• Contact records: when a contact started and ended, how long it took, which queue handled it and the wrap-up code the agent selected.
• Conversation text, where the platform already produces it, or audio where it does not and the client asks for it to be transcribed.
• Cases, tickets or emails attached to a contact, where these are supplied.
• No customer records, no account data, no payment details, and nothing from any system other than the sources the client connects.

What is removed before anything is stored

Redaction happens on the way in, not on the way out. Text is scrubbed before it reaches the store the analysis reads, so there is no copy of the original sitting behind a setting somebody could change later.

• Names, telephone numbers, email addresses, payment card numbers and national identifiers are removed from conversation text.
• Special category data is removed in the same pass.
• Customer and agent identifiers are replaced with a pseudonym derived using a secret unique to that engagement. The original values are never stored.

What it will not produce

These are not policies that rely on somebody remembering them. They are enforced in the software and in the database schema, and they cannot be switched on for one engagement.

• No output can be broken down by agent. The capability does not exist in the reporting model, so this analysis cannot be used to assess individual performance.
• No figure is published from fewer than thirty contacts, so no result describes an individual or a group small enough to identify one.
• Satisfaction scores are suppressed on the same floor, measured against the number of people who answered a survey rather than the number of contacts.

The documents a client signs

Generated from the engagement as it stands, in any of the six languages the product speaks, and filled in with what has already been recorded so nobody is asked to confirm something twice with two different answers.

• Data protection impact assessment. What the analysis does, what it reads, the limits it operates under, and space for the client's own conclusion. Completed with their privacy officer and kept with their processing records.
• Lawful basis and consultation record. Which basis the organisation relies on, whether the works council was informed, consulted or has approved, the impact assessment reference, and the date the data must be deleted by. No analysis starts before this exists.
• Engagement readiness checklist. The approvals, the data and the people that have to be settled before the first extraction, which is where most delays actually come from.

Deletion that proves itself

On request, or at the end of the retention period, the engagement and its pseudonymisation secret are deleted, and the deletion is evidenced with record counts before and after. Destroying the secret is what makes anything derived from it permanently unlinkable, which is a stronger guarantee than deleting rows alone.

Where it runs

In the client's own Azure subscription, in a region they choose, reached by a managed identity rather than a shared password. Credentials for connected source systems are held in Key Vault and never in the database. Nothing is sent to a third party for analysis.

What this website stores

One cookie, and only if you use the light and dark switch. It is named im-theme, it holds the word light or the word dark, and it exists so your choice survives moving between pages. There is no analytics, no advertising and no third party script on this site, so nothing here counts visitors or follows them anywhere else.