Privacy Policy

SIMCOAI processes account, billing, support, usage, call/chat and website data to provide the service, secure it, bill for it, improve it and meet legal obligations. We avoid asking for unnecessary sensitive data and encourage customers to configure human handoff for risky topics.

Your business is usually the controller for data about its own customers. SIMCOAI is usually a processor for those customer workflows, and an independent controller for account, billing, website, security and business-contact data.

For dashboard users, billing contacts, website visitors, support requests and sales enquiries, SIMCOAI LTD normally acts as controller. For customer calls/chats handled on behalf of a business customer, SIMCOAI normally acts as processor and the business customer is the controller.

Some suppliers such as Stripe, Twilio or our AI and voice providers may act as processors or independent controllers depending on the specific processing activity and their own terms.

Account data: name, email, company, sign-in provider, user ID, role, legal acceptance and support history. Business profile data: business name, website, services, opening hours, policies, escalation contacts and configuration.

Customer workflow data: chat messages, call metadata, transcripts or summaries where enabled, bookings, refund/order details, escalation notes and audit logs. Customer records: where a business customer uses the customer database, one record per person containing the name, email address, phone number, company and any additional fields that business has chosen to record, together with the bookings, refunds, orders and escalations linked to it. Records are created from details a caller gives, and a caller is matched to an existing record using the number they are calling from. Billing/security data: Stripe references, invoices, plan status, IP-derived security data, device/browser metadata and request IDs.

If you write a review of SIMCOAI we process the words you wrote, the star rating, the name, role and business name you enter, the account the review came from where we know it, the date, and technical metadata about the submission (a one-way hash of the network address it came from and the browser user agent). We do not ask for and do not want any other personal data in a review.

Lawful basis. Publishing a review, and the name, role and business name alongside it, is done on the basis of your consent, given by the tick box on the submission form. Nothing is published without it. Holding the review internally and checking it before publication rests on our legitimate interests in running an honest, moderated review process and in preventing fraudulent or abusive submissions.

What is published and what is not. We publish the rating, the review text, the headline, and the name, role and business name you gave us, together with a “Verified customer” marker where the review came from the single-use link we emailed a paying customer. We never publish your email address, your account identifier, your network address or any other technical metadata, and we do not sell or license reviews to any third party.

Withdrawing consent. You can withdraw consent and have a published review removed at any time, for any reason and without giving one, by emailing [email protected]. We aim to unpublish within one working day; because pages are cached, a removed review can remain visible for a short period after that (currently up to about a minute for the review list itself). Withdrawal does not affect the lawfulness of publication before you withdrew.

Review requests. We email each customer once, about fourteen days after they start, to ask whether they would like to write a review. That email is sent on the basis of our legitimate interests in obtaining customer feedback about a service you already buy from us (the “soft opt-in” in regulation 22 of PECR). It carries a working unsubscribe link and a one-click list unsubscribe header, and opting out stops feedback requests without affecting service, billing or security emails, which you cannot unsubscribe from while you hold an account.

Retention. A published review is kept for as long as it is published. An unpublished, rejected or withdrawn review, and the record of the invitation that produced it, are kept for up to 24 months so that we can show how a review was obtained and moderated, and are then deleted. Review invitation links themselves expire after 90 days.

Data may come from you, authorised users, your customers, connected integrations, Stripe, Twilio, our own authentication system, support communications, website forms, logs and security tools.

Do not upload data you do not have rights to use or data that is not needed for customer support, booking, refund, order, analytics or compliance workflows.

We process data to create and secure accounts, provide AI chat and phone workflows, maintain knowledge bases, route customer tasks, produce analytics, manage subscriptions, provide support, prevent abuse, troubleshoot providers and keep legal acceptance records.

We may also process limited data to improve reliability, user experience, prompts, safeguards, documentation and fraud/security controls.

Depending on the context, lawful bases may include contract, legitimate interests, legal obligation and consent. Consent is especially relevant for non-essential cookies or marketing communications where required.

For customer workflow data, the business customer must determine and document the lawful basis it relies on. SIMCOAI processes that data under customer instructions unless another legal requirement applies.

SIMCOAI may send relevant prompts, business knowledge, conversation content or summaries to AI providers to generate responses, classifications or workflow suggestions. We configure the product to escalate sensitive or uncertain topics rather than making final regulated decisions.

SIMCOAI manages all AI provider credentials centrally on SIMCOAI-managed infrastructure; customers do not add or manage their own provider keys. The approved managed AI provider is OpenAI, used subject to plan, add-on and pay-as-you-go controls. AI usage is metered and the available model options are shown in the dashboard.

SIMCOAI should not be used for solely automated legal, employment, credit, medical, housing, insurance, eligibility or similarly significant decisions without a separately reviewed contract and controls.

Phone features may process caller number, call time, duration, call status, routing events, recordings or transcripts where configured. Businesses must provide lawful disclosure and recording notices required for their use case and location.

Call logs and transcripts should be reviewed regularly. Payment card details, medical details and unnecessary sensitive information should be redirected to appropriate secure human or provider flows.

On phone-enabled plans, an authorised team member can select Take over by voice in Live Calls and use their browser microphone and speakers. The caller stays with the receptionist while the browser connects. Once the voice handoff connects, AI speech recognition, transcription and replies stop for the human conversation. The earlier transcript and handoff event remain in the call record. Configured call recording may continue; switching off the AI does not withdraw a recording notice or change your recording responsibilities.

We use essential cookies/storage for site and dashboard operation. Non-essential analytics or marketing technologies should only run where the user has been given appropriate information and choice.

Cookie choices may be stored on your device or in our legal acceptance records. See the Cookies page for categories, purpose, duration and preference controls.

We may share data with suppliers that help us operate the service, such as Stripe for billing, Twilio for communications, our managed AI model provider OpenAI for AI features, Deepgram for speech recognition and ElevenLabs for voice on phone-enabled plans, Cloudflare for security/delivery, and Fasthosts for hosting, domain services and transactional email. SIMCOAI manages all AI provider credentials centrally; customers do not add their own provider keys. AI requests for your account are handled by OpenAI, which is the only approved managed provider. Sign-in and account security are handled by SIMCOAI's own sign-in service, which runs on SIMCOAI-controlled infrastructure rather than a third party's; it is described in full in the “Identity provider processing” clause of our GDPR page. This service processes identity and login data: your email address and its verification state, sign‑in and sign‑out events, multi‑factor authentication and authenticator‑app enrolments, passkey and passwordless registrations, email sign‑in links and codes, and the account identifier returned by a Google, GitHub or Microsoft sign‑in. Each of these is available where enabled for your account rather than on every plan by default. Against your SIMCOAI account we keep a linked authentication record holding the user reference, the identity provider name, the provider‑issued subject identifier, the email address and its verification flag, basic profile metadata and the last sign‑in timestamp. That record exists so a sign‑in can be matched to the right account; it does not contain your password. Passwords are set and checked by the sign-in service, never by the SIMCOAI dashboard, so the dashboard does not receive your password when you sign in, reset it or change it — and the sign-in service itself does not expose a readable password back to us: it stores your password only as a one-way hash, and the only administrative capability it offers is to set a new one, never to read an existing one. The migration away from storing password hashes in the SIMCOAI dashboard's own database is complete and the legacy local password hashes have been removed: SIMCOAI holds no password record for any account, in any form. If you ask us to erase or correct authentication data we action it directly, because the sign-in service runs on our own infrastructure and there is no separate third party to instruct. Neither sign-in service receives your business operational data. SIMCOAI stores that operational data — your business profile, customer records, call and conversation logs and workflow history — in its own self-hosted Supabase instance on SIMCOAI-controlled infrastructure. Supabase Inc. is not a subprocessor and does not receive your data; the relevant processor for that storage is our hosting provider, Fasthosts.

We do not sell personal data. We may disclose data if required by law, to protect rights and security, to complete a corporate transaction, or with your instruction/consent.

Across the SIMCOAI product, the marketing site and the documentation, the parts of the service are referred to by SIMCOAI names — SIMCOAI Vocatio, SIMCOAI Voice, SIMCOAI Speech, SIMCOAI Intelligence — and the AI models, voices and speech engines have SIMCOAI names of their own. Those names describe configurations SIMCOAI builds, operates and can change; they are not a claim to have built the underlying engines, and they are not used here.

This page names the actual processor, because that is a legal requirement rather than a presentational choice. The table below is the map between the two, so you can tell exactly who processes what when you read a SIMCOAI name anywhere else.

Where a SIMCOAI name is used elsewhere, it always refers to the row above. If SIMCOAI changes the processor behind one of these, this page and the supplier table are updated and notice is given under the subprocessor clause; the SIMCOAI name may stay the same, which is precisely why this map exists.

Some suppliers may process data outside the UK or EEA. Where personal data is transferred internationally we ensure a lawful transfer mechanism is in place, such as a UK adequacy decision, the UK International Data Transfer Agreement or Addendum to the EU Standard Contractual Clauses, together with any supplementary measures needed.

Where we rely on the IDTA or the Addendum we also carry out a transfer risk assessment before the transfer begins. The mechanism relied on for an individual supplier is listed on our GDPR & Data Processing page and the underlying assessment is available on request. Business customers should assess whether their own use case requires additional transfer terms or a data processing agreement.

We keep personal data only as long as necessary for the purpose it was collected: account records for the life of the account plus up to 6 years after closure where needed for legal claims; billing and tax records for 6 years as required by UK tax law; security and audit logs typically for 12 months; and support correspondence for up to 3 years. If you cancel, your workspace content — business profile, knowledge, configured workflows and settings — is kept for 2 years after your subscription ends so you can reactivate later without rebuilding your setup, after which it is deleted. That is separate from the account, billing and legal-claim records described above, which follow their own periods. You can ask us to delete your workspace sooner by emailing [email protected], and we will do so except where we must keep specific records to meet a legal or tax obligation. A detailed retention schedule is available on request.

Customers should delete or export records they no longer need and avoid storing unnecessary sensitive data. Backup deletion can lag live deletion because backups are rotated for security and continuity.

Encrypted recovery snapshots are taken hourly and deleted after 30 days at the next scheduled backup run. A person or record erased from the live service may remain in an older encrypted snapshot until that snapshot expires. If a snapshot is restored, we will reapply deletions and other changes required after its recovery point before making restored data available.

Under UK GDPR you have the rights to be informed, of access, to rectification, to erasure, to restrict processing, to data portability, to object, and rights in relation to automated decision-making. We will respond to a valid request within one month (extendable by two further months for complex requests, in which case we will tell you). Where the business customer is controller for a record, we will pass your request to them without undue delay. You also have the right to complain to the Information Commissioner’s Office at ico.org.uk or on 0303 123 1113.

Contact [email protected] with the account/business involved, the right you want to exercise and enough information to locate the record safely.

SIMCOAI protects personal data with encryption in transit (HTTPS/TLS), role-based access controls, rate limiting, audit records, isolated supplier credentials and least-privilege administrative access. Where SIMCOAI stores a credential at rest — its own supplier credentials, or a secret held on a customer's behalf such as a webhook signing secret — it is encrypted with ChaCha20-Poly1305 (RFC 8439), a published, independently reviewed 256-bit authenticated encryption standard, rather than a private algorithm of our own. We review these measures regularly. No system is entirely risk-free, so customers must also use strong account hygiene and keep escalation processes available.

Service credentials and payment secrets must never be shared, embedded in your website or app, or pasted into chat, prompts or support tickets. Do not paste secrets, card numbers or unnecessary sensitive data into chat, voice prompts or support tickets.

Our current recovery copies cover the main workspace database, sign-in records, stored files and local uploads. They are encrypted before being written to backup storage, using a public encryption key; the matching decryption key is held separately. Copies currently remain on the same hosting server, so they do not protect against loss of that server. We intend to add separate-site backups when that service is ready.

SIMCOAI supports several ways to sign in, and each stores a little data so that the method works. We describe them here because they are account security data rather than general usage data.

Passwords are set and checked by SIMCOAI's own self-hosted sign-in service, rather than by the dashboard. It does not give SIMCOAI, including our own support team, a way to read an existing password: it stores it only as a one-way hash and offers, at most, a way to set a new one, never to view one already set. We will never ask you for your password. SIMCOAI holds no password record for your account, in any form. Passkeys store a public key and a credential identifier registered by your device. The private key never leaves your device and is never transmitted to us. Where you unlock a passkey with a fingerprint or face scan, that check happens entirely on your own device: neither SIMCOAI nor the sign-in service ever receives, processes or stores biometric data of any kind, and none is used to identify you. Two-step sign-in may add an authenticator app, a hardware security key or single-use recovery codes. Where used, the shared secret or key registration is held by the sign-in service as part of the account, not by the SIMCOAI dashboard. Magic links and password resets store a single-use, short-lived token tied to your email address. Google or GitHub sign-in stores the account identifier that provider returns so we can match you to your SIMCOAI account; we do not receive your Google or GitHub password. Connecting one of these to an account for the first time needs you to be signed in already and to confirm the connection yourself on the dashboard’s Security page — we do not link a new sign-in method to an existing account automatically just because its email address matches, and you can disconnect a method yourself at any time as long as at least one other way to sign in remains.

We also record sign-in events — time, approximate origin and method — to help detect unauthorised access and to give you an audit trail. This is processed on the basis of our legitimate interest in keeping accounts secure.

Adding a new sign-in method (an authenticator app, a security key or a passkey) is completed on the SIMCOAI sign-in service itself, because that is where the credential is created and verified. Choosing which methods your account offers, their order, switching two-step verification on or off, and removing a method you no longer use are all done directly from the dashboard's own Security page. Either way the change applies wherever you sign in and does not depend on one browser. Sessions can be ended from the dashboard, and signing out ends the session on this device and on the sign-in service. Removing every method except one may leave you unable to sign in, so keep a backup method configured.

SIMCOAI is not directed at children. Do not configure workflows intentionally targeting children or collecting children data unless your contract, notices and controls specifically permit it.

Special category data should be avoided unless necessary, lawful and covered by your own controller obligations and written arrangements.

Where a business enables proof uploads, it can send its own customer a secure one-off link to submit supporting evidence against a refund, order, booking or escalation. Using that link we process the uploaded file itself (typically a photograph, receipt or document), an optional barcode, tracking or reference value, an optional free-text note, and technical upload metadata such as file name, size, type, timestamp and the single-use link token. No SIMCOAI account is created for the person uploading.

Roles. The SIMCOAI customer (the business) decides what evidence to request and why, and is the controller for that evidence. SIMCOAI acts as processor on the business's instructions. The business is responsible for telling the person what is being collected and why, and for having a lawful basis to collect it. It should not request payment card details, passwords, or special category data it has no lawful basis to process.

Automated checks. Barcode, reference and document checks are assistive only. They help the business's staff review a request; they do not make the decision. No refund, booking or escalation outcome is decided solely by automated means — a person reviews and approves every outcome, as described in our AI Policy.

Access and retention. Uploaded files are retrieved through authenticated requests and are visible to the business's authorised dashboard users. SIMCOAI staff access them only where necessary for support, security or legal compliance. Evidence is retained alongside the related workflow record under the retention rules described above and in the business's own settings, and can be deleted on the business's instruction, subject to any record-keeping we are legally required to maintain.

Rights. Where evidence concerns a business's own customer, that person should exercise their data protection rights with the business as controller in the first instance; SIMCOAI will assist the business in responding. If you cannot reach the business, contact us at [email protected] and we will help route the request.

A business may add its own logo, an accent colour, a short footer note and a block of its own formatted content (mode: custom) to the emails SIMCOAI sends on its behalf to its own customers — verification codes and secure proof-upload links. These are the same emails described under Customer evidence and proof uploads above; this clause covers only their appearance. The visual editor and direct HTML editor change the same stored content; a preview in the dashboard is illustrative, while the sample email shows the saved message. Businesses should check their links, image descriptions and wording before saving.

Roles are unchanged. Adding branding does not change who processes what: the business remains the controller of its own customer’s contact details and the content it chooses to add, and SIMCOAI remains the processor sending the email on the business’s instruction.

Any HTML a business submits is sanitised before it is stored — scripts, forms, embedded frames, click-tracking attributes and non-http(s) links are removed automatically. This protects the business’s own customer from content that could otherwise be used to collect credentials or track them, and it protects the business from a mistake in markup pasted in from elsewhere.

The “Powered by SIMCOAI” line cannot be removed or edited. It is added by SIMCOAI’s own email system on a code path a business’s stored branding cannot reach, so the customer receiving the email can always tell which service actually sent it, whatever branding has been applied.

Email [email protected] for privacy questions. You may also complain to the UK Information Commissioner if you believe your data protection rights have not been handled properly.

We may update this policy as the service, providers, law or guidance changes. Material changes may require dashboard acknowledgement.

A business using SIMCOAI should tell callers, message recipients and website visitors when it uses an AI receptionist or assistant, what information may be collected, whether a call is recorded or transcribed, and how to reach a person. The business should identify itself as the controller for its own customer records and explain its lawful basis, retention periods and rights process. SIMCOAI provides tools and processor terms, but the business chooses its script, notices, content and purposes. A notice from SIMCOAI about our own account processing does not replace the business’s notice to its customers.

Where a caller refuses a recording or cannot use the automated route, the business should provide a lawful alternative that fits its service. The business should avoid sending special category or sensitive personal data into a general knowledge base. It should configure access so a staff member sees only what they need. These steps help the business meet its own duties and reduce the amount of data either party must handle.

We keep records needed to show who accepted a policy, changed a configuration, approved a sensitive action, purchased a service, requested a refund or connected an integration. Such records may contain account identifiers, timestamps, the type of action and limited technical context. We use them to administer the agreement, prevent repeated transactions, investigate disputes, secure accounts and meet legal obligations. We do not use an acceptance log as a substitute for the person’s actual choice, and an optional cookie preference is separate from accepting contract terms.

Access to these records is limited according to the task and retention need. A business can ask us what account information we hold and can challenge an inaccurate record. We may preserve a prior value and append a correction where rewriting the record would make a financial, security or consent audit misleading. If a legal hold or dispute requires longer retention, we will limit the record to what is reasonably relevant and release the hold when the need ends.

A business may connect its own calendar, communications or customer system, or may instruct SIMCOAI to receive information from a caller. The categories of data depend on that business’s configuration: contact details, booking requirements, order references, preferences, messages and evidence may be involved. We process these as the business instructs, subject to safety, security and legal limits. We do not decide the business’s reason for contacting an individual, whether a refund is due, or whether its marketing consent is valid.

If an integration sends fields that the business did not intend to collect, the business should narrow its permissions or mapping and contact us if it needs help removing the excess. We may reject or quarantine content that appears malicious, technically incompatible or outside the permitted use. This is a protective measure and does not turn us into the controller of the business’s underlying customer relationship.

A person asking about data held by their business should normally contact that business first. If the request reaches SIMCOAI and the business is the controller, we will direct it to the business or assist the business under the data processing terms. If SIMCOAI is the controller for account, billing or security data, we will assess the request ourselves. We may ask for information needed to verify identity and locate records, but should not demand more than is reasonably necessary. We will explain if an exception or another person’s rights limit what can be provided.

Deleting data from an active workflow can affect bookings, refunds or evidence. We will coordinate with the responsible controller and preserve information we are legally required to keep. A request to remove a business’s own account data does not automatically erase information another business lawfully holds about the same person. We aim to explain that distinction so the requester can reach the correct organisation.

We process sign-in events, device and network context, failed authentication attempts, access logs and similar signals to protect accounts and investigate suspected misuse. These records can be inaccurate or incomplete as indicators of a person’s identity: a shared device or network may represent several people. We use them with other evidence before taking a consequential action where practical. Security checks may temporarily delay access while identity is verified, and we give a support route when an account owner believes a block is mistaken.

We do not put passwords, full payment card numbers or secret API keys in ordinary customer activity reports. Where a security investigation requires information from a provider, we request only what is relevant and restrict access to the people handling the incident. We may keep a minimal record of a confirmed security event after routine logs expire if needed to defend accounts, document our response or meet a legal duty.

The location of a person’s device, the business’s own integration and the location of a service provider can all affect where data is processed. SIMCOAI’s transfer mechanisms for transfers we make are described in the GDPR & Data Processing Policy. A business that independently connects a provider is responsible for assessing that connection and its own transfer obligations. We will provide reasonably available information about our subprocessors and safeguards so the business can make its assessment; we cannot promise that every third-party system chosen by the business stores data in the UK.

If a transfer arrangement changes materially, we will update the relevant disclosure and give the notice required by our agreements and law. We will not describe an adequacy decision, contractual safeguard or supplementary measure as guaranteeing that no foreign authority could ever request data. Questions about a particular workflow can be sent to the privacy contact on this page.

Businesses can improve accuracy by keeping their service descriptions, hours and customer records current and removing old copies they no longer need. An AI-generated summary should be checked against the underlying conversation before a person relies on it for a high-impact decision. SIMCOAI may maintain technical copies for resilience or recovery, but the ordinary retention rules and legal exceptions still apply. A deleted item may remain for a limited period in backups before its scheduled expiry, where restoration controls prevent ordinary use.

We encourage businesses to use the smallest amount of personal data that will perform the task, especially in prompts, uploaded proof and free-text notes. They should not use a general note field to store passwords, card details or sensitive facts just because it is available. If a business has a retention requirement shorter than the default, it should review the product controls and contact us about whether the configuration can support it before collecting the data.

A privacy question can concern SIMCOAI’s own account processing, the processing we perform for a business, or a connected provider. We will identify the relevant role and explain the next contact where possible. A person may complain to the Information Commissioner without first contacting us. We do not require someone to waive a privacy right to receive support or to continue an existing lawful service. We may need to keep enough information to answer a complaint and demonstrate the steps taken.

When we change the purposes for which we act as controller, we will update the notice and, where required, tell affected people before the new processing starts. A material change to the data processing terms or a business’s instructions is handled under the agreement. Historic policy versions and acceptance records are kept so the parties can establish which terms applied at a particular time.

We determine why and how we process information needed to run our own business relationship with an account holder. This includes account registration, authentication, billing, fraud prevention, service notices, support, legal acceptance, product security and compliance with law. The categories may include a name, business role, work contact details, account identifiers, payment references, communications with support and technical logs. We do not need a full payment card number to issue an invoice or investigate most payment questions; the payment provider handles card details under its own notice. We should ask for the smallest amount of information that lets us perform the task.

For account administration and delivery, our lawful basis may be performance of a contract with the individual where applicable, or legitimate interests in providing and securing a business service. For tax records and binding legal demands, a legal obligation may apply. Where optional marketing or analytics requires consent, we should obtain and honour that choice rather than relabel it as a contract necessity. A single event may support more than one purpose, but we should explain the purpose and relevant basis and should not keep the information indefinitely just because another use might later arise.

A business user can ask us about the account data we control and can correct a wrong contact or challenge an inaccurate security record. We may need to preserve a limited history of a prior value to explain a charge or access decision. We will assess that need against the individual’s rights and explain it where possible.

A Customer may instruct SIMCOAI to answer a call, receive a message, create a booking request, store a customer record or route a refund query. For the personal data in those workflows, the business normally decides the purpose and is the controller, while SIMCOAI processes on its behalf. The business should provide its own notice, choose a lawful basis, decide retention and respond to the person’s rights request. Our GDPR & Data Processing Policy sets out our processor duties, including instructions, security, subprocessors, assistance and end-of-service handling.

The same person may appear in both roles. For example, a caller’s booking details may be Customer-controlled data, while an account owner’s support email to us may be SIMCOAI-controlled data. We should not merge the purposes merely because the records share an email address. We may need limited technical logs for security and troubleshooting in our own role. When a request arrives, we should identify which organisation controls the data before deciding who responds.

A Customer cannot make SIMCOAI its controller merely by putting its own marketing list in the product. We do not choose whether the Customer may contact those people. If an instruction appears unlawful or exposes another customer’s data, we may pause it and ask for clarification while keeping the relevant processor and security obligations.

A caller may provide a name, number, preferred appointment time, order reference or description of a problem. A connected calendar may return availability or a staff member’s name. An uploaded proof item may show a receipt or product image. A conversation may create a transcript or summary depending on the enabled feature. These examples are not a requirement to collect every field. The Customer should configure the minimum fields needed and tell people when a recording, transcription or AI assistant is used. We should not ask for a password or complete payment card number through a general conversation.

A caller ID, email address or order number may be used to find a possible matching record, but a match is not always proof of identity. The business should set verification rules suited to the information it plans to disclose or change. SIMCOAI may support those checks and may stop an action if the required fact is absent. We should not present an unverified match as a confirmed identity simply because a database returned one result.

A business may add free-text notes. Those fields can inadvertently contain sensitive data, so access and retention should be reviewed. A Customer should remove irrelevant detail and contact us about accidental uploads that it cannot delete with available controls.

Providing the requested service, preventing abuse, improving reliability and sending marketing are different purposes. Operational troubleshooting may use a limited example of a failure, but it should not become a reason to read a business’s entire customer database. We may use aggregate statistics to understand errors, capacity and feature adoption, with access controls and minimisation. A Customer’s content should not be used to train a general model unless an applicable agreement and lawful basis permit that use, as further explained in the AI Policy.

We should not infer consent to marketing from a person calling a business, visiting a policy page or accepting account terms. If we invite an account contact to receive optional product news, we should make the choice clear and honour withdrawal. Necessary service notices about security, billing and changes may still be sent to the verified account contact when needed to perform or administer the agreement. The content of such a notice should stay within that purpose.

If we propose a new purpose that people would not reasonably expect, we will assess compatibility, update the notice and obtain consent or another lawful basis where required before starting it. A new feature’s technical feasibility is not itself a lawful basis for broader processing.

Different records have different retention needs. A business customer should set its own retention policy for calls, transcripts, bookings and customer records and should use available product controls or contact us where a shorter period is required. SIMCOAI keeps account, billing, acceptance and security records for the periods needed to administer the relationship, defend a claim, prevent abuse or meet a legal obligation, as described elsewhere in this notice. We should not treat the longest legal possibility as the default period for every copy.

Deletion may take place in stages. A current record may leave normal product views first, while protected recovery copies expire on their normal schedule. A legal hold, live dispute or tax obligation may require a limited subset to remain longer. We should restrict that subset to the reason for the hold and review it when the reason ends. A restore should not permanently resurrect data that was already due for deletion; we should reapply deletion where feasible.

An export is a way to give a Customer its records, not a guarantee that SIMCOAI may immediately delete every financial or security fact connected to the account. We will explain a lawful retention exception when responding to a request. The Customer should also delete copies it exports when its own purpose ends.

We share information with a provider when it is needed for an enabled feature, such as hosting a record, delivering a message, processing a payment or operating an identity check. The provider should receive the fields required for that function, not the entire account by default. A Customer may independently connect its own calendar, CRM or communications service; that connection can send data to a provider selected by the Customer. We should make the connection and permissions reasonably understandable before it is enabled.

We may also disclose limited information to professional advisers, auditors, an insurer or an authority where a legitimate legal need exists. We should assess the request and protect confidentiality. A valid court order or legal obligation may require disclosure; where permitted, we will inform the affected Customer and avoid disclosing unrelated information. We do not sell a Customer’s private records as a data broker.

A list of common providers is a snapshot, not a promise that every provider processes every person’s data. The actual path depends on the feature used and the Customer’s choices. Material changes to subprocessors used for Customer-controlled data are addressed under the GDPR & Data Processing Policy.

A person may have rights to access, correct, erase, restrict or object to certain processing, and in some cases to receive portable data or withdraw consent. The right that applies depends on the role, lawful basis and facts. Withdrawal of an optional choice does not undo processing that was lawful before withdrawal, but we should stop the processing that depended on that choice. A business should not require someone to accept marketing as a condition of asking about a booking or complaint.

We may need to verify a requester’s identity before disclosing account or customer information. We should use proportionate checks and avoid asking for an identity document if a less intrusive method will do. We will explain where a request concerns data held for a Customer business and, where appropriate, forward it or guide the person to that business. We will not reveal another individual’s private information merely because it appears in the same call or record.

If we refuse or limit a request, we should explain the reason and the available complaint route unless law prevents that explanation. A person can contact the UK Information Commissioner. We will not penalise a person for making a good-faith rights request.

An AI assistant can summarise a conversation, suggest an answer or help classify a request. These operations may involve personal data from the Customer’s knowledge and the person’s words. The Customer should explain the use of AI in its own notice and review a suggested outcome where the matter is consequential. SIMCOAI’s AI Policy describes limits and human controls. We should not tell a person that a human approved an action if the system only generated a proposal.

A person may ask for a human route where the automated channel cannot safely resolve the matter. The Customer decides how to staff that route and must meet any duty to provide meaningful human involvement in a significant decision. Technical routing and logs may record that a handoff was attempted or completed. A failed transfer should not be represented as a conversation with a person.

We may test aggregate quality and investigate a reported failure, using the minimum identifiable data reasonably needed. A business should not upload highly sensitive data merely to improve an assistant’s answer. If a model or provider arrangement materially changes how personal data is processed, we will update the relevant disclosures and safeguards before using the new arrangement where law requires.

We use access controls, account verification, logging, encryption and operational procedures appropriate to the data and risk as described in our security and data processing materials. No internet service can promise that a device, network or third-party provider will never fail. We therefore also limit access, monitor for abuse, investigate anomalies and support account owners in changing credentials or restricting an integration. The Customer should secure its own devices, staff access and connected systems.

A security log can help establish what happened but may not prove who physically used a shared device or compromised credential. We should consider other evidence before attributing a consequential action to a person. If an incident affects Customer-controlled personal data, we will follow the processor notification and assistance duties in the GDPR & Data Processing Policy. If it affects information we control, we will assess our own legal notification duties.

A person can report a suspected exposure through the support or privacy contact without posting secrets in a public form. We may ask for a limited example to investigate. We should provide a meaningful response and correct a confirmed weakness within our control, while avoiding detail that would expose other accounts.

Before a feature starts processing personal data in a new way, we should identify the purpose, controller role, categories of people and data, providers, location, retention and practical risks. We should ask whether the same result can be achieved with less data or a shorter period. Where the Customer chooses the purpose, we should give it information it reasonably needs to assess the feature; the Customer should decide whether its own notice, lawful basis, impact assessment or staff training needs updating. We should not assume that a general service description tells a person about an unexpected new use.

A trial or preview label does not relax privacy law. Test data should be synthetic or minimised where possible. If a feature is withdrawn, the data it created remains subject to the stated export, retention and deletion rules. A material change to a provider or transfer should be assessed before launch and reflected in the relevant policy and contractual notice.

The opening summary gives the main points. The later sections explain individual processing situations in more detail; the GDPR & Data Processing Policy explains our processor duties to business customers. A person should not have to understand every technical provider to learn who controls their data, why it is used and whom to contact. If a section seems to conflict with a specific notice shown when information is collected, we will investigate and correct the inconsistency; a just-in-time notice should explain the immediate context rather than quietly remove a right stated here.

We may link directly to a relevant section from a form, call script or account setting. We should keep those links working and make the information available before or at collection where required. A business using the Service should likewise place its own notice where its callers and visitors can find it. Contact us if the role or route for a particular request is unclear.

SIMCOAI may use automation to route a request, identify a possible record match or flag an account risk. A flag can be wrong, and a proposed outcome may need human assessment. Where a decision has a legal or similarly significant effect on a person, the responsible controller must assess the applicable safeguards and provide meaningful human involvement where required. It should not describe a rubber-stamp approval as human review. A person should have a way to question an adverse outcome and provide missing facts.

We may use automated security checks to temporarily protect an account. The account owner can contact support if it believes a check is mistaken. We should evaluate relevant evidence before a lasting adverse action where practical. We do not claim that all automation is profiling or that every routine routing decision has a significant legal effect; the purpose, data and effect matter.

A business account contact may choose whether to receive optional product news where that choice is offered. We should record and honour the choice and provide an easy way to change it. A necessary security warning, billing notice, policy reacceptance request or incident update serves a different purpose and may still be sent to the verified contact when required to administer or protect the account. We should keep such a message focused on that purpose. A Customer sending messages to its own contacts must manage its own marketing preferences and suppression records. SIMCOAI’s account preference does not automatically update the Customer’s lists, and the Customer’s lists do not determine whether we may send a necessary account notice.

We review this notice when a product, provider or legal requirement changes. A date at the top tells readers when the wording changed; an effective version shows which contractual policy an account accepted. Those dates can differ because a clarification may be published without changing an existing agreement. Where a material new purpose or processor term requires a fresh choice, we will present that choice rather than treating silence as acceptance. Historic records are kept to establish which notice and terms applied. A person who sees an inconsistency can contact the privacy address, and we will investigate and correct a confirmed error.