Cookie Policy

Cookies, local storage, session storage, pixels, SDK identifiers and similar technologies can remember choices, keep sessions working, protect accounts, measure site use or support embedded provider flows.

The same privacy expectations can apply even when the technology is not technically a cookie.

Essential technologies keep navigation, security, authentication, legal acceptance, billing redirects, cookie preference storage and dashboard operation working. These are needed to provide the service or a requested function.

Examples may include session cookies, CSRF or request identifiers, launch lock state, OAuth redirect state, Stripe/Twilio flow state, sign-in state and preference values.

Analytics technologies help us understand page performance, broken journeys, documentation gaps and product interest. They should be configured to respect consent requirements and minimise personal data.

If analytics is disabled or not consented to, core service access should still work.

Marketing or remarketing technologies are not essential. If used, they should only run with appropriate notice and consent where required.

SIMCOAI should not use marketing cookies to make hidden eligibility or pricing decisions.

We may store cookie choices locally or in legal acceptance records so the site and dashboard remember whether you chose essential-only or all available categories.

Clearing browser data, changing device or using private browsing may reset preferences.

The dashboard may use secure authentication and session storage used by SIMCOAI and its identity provider, plus related application state. These technologies protect accounts and keep the dashboard usable.

Do not disable all storage and expect login, checkout, OAuth or legal acceptance flows to work reliably.

Signing in also involves SIMCOAI’s own self-hosted sign-in service. When you sign in, a session is established for the hosted sign‑in domain and SIMCOAI sets its own session cookie for the dashboard. Both are strictly necessary: without them you cannot stay signed in, and neither is used for advertising, profiling or cross‑site tracking. They are exempt from the consent requirement under PECR regulation 6(4) as communications strictly necessary to provide a service you have requested. Signing out ends both. Blocking these in your browser will prevent sign‑in from working at all.

Stripe-hosted checkout and portal pages may use their own cookies or similar technologies for fraud prevention, payment processing, session continuity and billing security.

Card details are handled by Stripe-hosted surfaces, not by SIMCOAI chat or voice flows.

Twilio-powered voice, messaging or verification features may create provider-side events, identifiers or logs needed to route calls, diagnose delivery and comply with telecoms requirements.

Telecoms data can be subject to additional rules beyond ordinary web analytics.

The public AI assistant may use local state to remember UI mode, open/closed state, draft text or recent non-sensitive support context. Do not type secrets, card numbers or unnecessary sensitive personal data into the assistant.

The assistant should route account-specific or risky requests to support rather than guessing.

The categories above describe what each technology is for. This is the most concrete list we can give of what actually runs on this domain today. It is not exhaustive — as SIMCOAI changes, the exact names in use may change too — but every entry is real, not illustrative.

Use the SIMCOAI cookie banner or dashboard controls where available. You can also use browser settings to block or clear cookies, but doing so may break login, checkout, preference persistence or security features.

If the visible preference control is not available, email [email protected] with the page, browser and request.

SIMCOAI does not currently respond automatically to a Do Not Track or Global Privacy Control browser signal, because there is no single standard for what either should mean across the different technologies described above. Using the cookie banner and the essential-technology exemption described in each section is the reliable way to control what runs.

Session technologies may expire when the browser session ends. Preference and security technologies may last longer so choices and account protections persist. Provider technologies follow provider policies.

We review durations during product changes and aim to avoid keeping identifiers longer than necessary.

Essential technologies are generally used because they are needed for a requested service or security. Non-essential analytics or marketing technologies should rely on appropriate consent where required.

Cookie rules can apply alongside UK GDPR, so transparency and user choice both matter.

We update this policy when technology, providers, law or guidance changes. Material changes may be reflected in the dashboard legal acceptance versions.

Last updated dates are shown so customers can tell when a policy changed.

Questions about cookies or storage can be sent to [email protected]. Include the page, device, browser and what you expected to happen.

For data protection rights, see the Privacy and GDPR pages.

Essential storage enables sign-in, security, payment continuity and the operation of a feature a visitor asks to use. It is not treated as permission to run analytics or advertising technology. Where optional technologies are offered, the visitor should be able to understand their purpose and choose whether to allow them. An optional choice can be changed later; refusing it should not prevent access to core pages or account services that do not need it.

A business customer may use SIMCOAI tools on its own website and choose separate tracking there. That customer is responsible for its own website notice and consent controls. SIMCOAI’s choice panel governs technologies we place or read on our own sites and dashboard. A browser setting or privacy extension may block a technology regardless of a saved preference, and some features may ask the visitor to make a new choice if their browser has cleared storage.

A preference may be stored in the browser so the site can honour it on later visits. Clearing browser data, switching device or using a private window can remove that remembered choice. If the choice is unavailable, we may ask again before enabling optional technology. A saved preference is not proof that a different person using the same device made the choice, and we do not treat it as blanket consent for a new purpose.

We may keep limited server-side records that a signed-in account owner accepted contract terms or selected a cookie option, where needed to administer the agreement and demonstrate the choice made. We do not use a cookie choice to infer agreement to marketing emails, call recording or a customer’s own use of personal data. Those matters have separate rules and, where necessary, separate choices.

An external payment page, video, map or connected service may use its own storage after a visitor chooses to open it. Its provider is responsible for explaining technologies it controls. We try to avoid loading an optional embed before the visitor asks for it or makes an applicable choice. Returning from a payment provider may require a short-lived state value so the correct account can be matched to the transaction and a duplicate payment can be avoided.

The presence of a third-party name in a reference table does not mean it runs on every page or for every visitor. Availability depends on the feature, device, region and current provider arrangement. Visitors should inspect a provider’s own notice when leaving our site. If a third-party integration is enabled by a business customer on that customer’s property, its storage practices are outside the choice panel for our public website.

Some temporary values help defend sign-in, stop forged requests, limit repeated attempts and remember a step-up verification during a sensitive action. These values may be essential even where a visitor has rejected optional analytics. They are designed to support the requested account service and protect its users. A security value is not a licence to follow the visitor for unrelated advertising or to retain a browsing history indefinitely.

If a security control fails because storage is blocked, the site should explain the problem and offer a way to retry where practical. The visitor can contact support if a legitimate account action remains unavailable. We may use server-side rate limits and logs as well as browser storage; deleting a cookie does not necessarily clear a security restriction that protects other users from repeated abuse.

Where optional analytics are permitted, we may measure broad page and feature use to improve navigation, identify broken flows and understand which help material is useful. We should not collect the content of private customer records merely to measure a page view. If analytics are not permitted, we may still use necessary operational information, such as aggregate error counts and security logs, to keep the requested service working. The exact data and retention of each technology should be described in the reference table or linked notice.

We will review optional tags when a provider or feature changes. A new tag with a materially different purpose should be explained before it is enabled under an old preference. We may remove a technology that no longer serves a clear purpose. A visitor can report an unexpected tracker to the privacy contact with the page and approximate time so we can investigate.

A cookie preference does not determine whether a business may call, email or message its own customer. Communications rules depend on the purpose, relationship, consent where required and applicable electronic marketing law. A SIMCOAI customer must make those decisions for its own campaign and keep its own evidence. Likewise, opening a chat or phone assistant does not itself give the business permission to add the visitor to a marketing list.

If a business embeds a SIMCOAI-powered feature on its site, it should explain both the feature and any storage that its implementation uses. We will provide reasonable information about our component so the business can prepare its notice. We do not approve the business’s whole website or determine whether its other tags comply with law.

A visitor who believes a cookie or local storage item was set contrary to a choice can send the page, approximate time, browser and the name of the item if known to our privacy contact. They need not send a screenshot containing a password or account token. We will check the purpose, provider and consent state, correct a confirmed misconfiguration and update this table if its description is inaccurate. A visitor may also complain to the Information Commissioner. A browser extension can create or block storage outside our control, so we may ask for enough detail to distinguish that from our own tag.

The choice panel should work with keyboard navigation and readable labels, and the essential and optional purposes should be distinguishable. A visitor should not have to accept optional storage to read the policy or contact us. If a control fails on a particular device, the visitor can contact our privacy team and can also use browser controls while we investigate. We should test a material change to the panel before release and correct a confirmed fault. The policy table and actual tags should be reviewed together so that a clear label is supported by the technology in use.