Privacy Policy

1. Who we are

AutomateIT is a trading name of AutomateIT Online Ltd, a private company limited by shares incorporated in England and Wales (company number 17096237), with its registered office at 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ. In this notice, "we", "us", "our" and "AutomateIT" all refer to AutomateIT Online Ltd.

We are registered with the UK Information Commissioner's Office (ICO) under registration number ZC129488 (Tier 1 fee payer). The director responsible for data protection matters is Ivan Aguilar Mari.

AutomateIT is an AI phone agent built for UK tradespeople. Plumbers, electricians, gas engineers and similar small business owners sign up, complete a short setup, and get a UK phone number. From then on, an AI receptionist answers their calls, books jobs, sends payment links, and escalates emergencies.

You can contact us about anything in this notice in one of three ways:

• Email Ivan directly: ivan@automateitonline.co.uk
• Email our customer inbox: hello@automateitonline.co.uk
• Write to us at the registered office address above, marked for the attention of the Director.

For data protection matters specifically you can also email privacy@automateitonline.co.uk. This is a function alias forwarded to the accountable person at the time.

We aim to acknowledge data protection enquiries within 5 working days and give you a full reply within 30 days. (This is the timeline UK GDPR sets in Article 12.)

AutomateIT is currently operated by a single director. We do not have a separate compliance team. The response time targets in this notice reflect that, and the Director is personally accountable for every commitment in it.

Our company name, place of registration, registered number and registered office are also displayed in the footer of every page on https://automateitonline.co.uk in line with the Companies (Trading Disclosures) Regulations 2008 (SI 2008/495), made under sections 82 to 85 of the Companies Act 2006.

1.1 Data Protection Officer

AutomateIT has assessed whether a Data Protection Officer is required under UK GDPR Article 37. We do not meet the mandatory thresholds: we are not a public authority; the volume of end-caller data we currently process is not "large scale" in the ICO sense at the present number of customer accounts; and we do not process special category data on a large scale by design. The Director, Ivan Aguilar Mari, is the accountable person. We will reassess this position annually, on any material change to the volume or nature of processing, and immediately on either of the following thresholds being crossed: (a) 50 active customer accounts on the platform, OR (b) 5,000 inbound end-caller calls processed in any rolling 30-day window. The reassessment outcome is recorded in this notice's change log. We will appoint a DPO (internal or contracted) before reaching the relevant Article 37 threshold.

2. Scope of this notice

AutomateIT wears two legal hats and this notice covers both. (1) For tradespeople who sign up as our customers, and for visitors to the marketing site, AutomateIT is the data controller: we decide what data we collect and why. (2) For members of the public who phone a tradesperson's AutomateIT number, AutomateIT is a processor acting on the tradesperson's instructions; the tradesperson is the controller of those calls. Section 3 covers each group separately.

This notice does not cover external websites you reach by following a link from ours. Each of those will have its own privacy notice.

3. The personal information we collect, and why

We have grouped this section by the relationship you have with us. Each subsection lists the categories of data, the source, why we use it and where it is stored. Section 5 maps each purpose to a UK GDPR lawful basis.

3.1 Marketing-site visitors

If you simply browse the marketing site, we collect very little. The hosting and content delivery layers handle some technical data automatically:

If you fill in our contact form to request a demo, we collect the following directly from you and store it in our contact_submissions table in our application database:

• Your name
• Your email address
• Your business name and the trade you operate in
• A phone number we can call you back on
• Optional: your business website URL or Google Place identifier
• Your typical weekly call volume (a rough banding you choose from a dropdown)
• The frustration that prompted you to contact us (a short choice from a list)
• Any free-text message you choose to add

We use this to call you back, run a personalised demo and follow up. When you submit the form we generate a unique signup token tied to your submission so we can pre-fill your account if you decide to sign up.

If you accept a demo call, we then create a row in our demo_bookings table covering:

• The booking type (immediate or scheduled), the scheduled time, and a reschedule token for the public reschedule link we email you
• Attempt count and the latest call status (whether we reached you, were sent to voicemail, etc.)
• A copy of the call transcript, summary, outcome and duration that our AI demo agent ("Lucy") returns after the conversation
• Whether and when we sent you a signup link by SMS or email

If you accept a demo call, your end of the conversation is recorded by Retell on the same basis as live calls. The recording is held at Retell for up to 6 months and the transcript on demo_bookings for up to 12 months.

PECR Regulation 19. PECR Regulation 19 requires specific prior consent for unsolicited automated calls. The AutomateIT contact form records explicit consent at submission, including the version of the consent text the customer agreed to and the timestamp. Automated demo calls are placed only where this consent is on file. Consent can be withdrawn at any time by emailing privacy@automateitonline.co.uk. AutomateIT demo calls are solicited (the prospect submitted the contact form to request the callback), so Regulation 19 may not strictly apply; the explicit consent is captured nonetheless as a defensive overlay and as the UK GDPR Article 6(1)(a) basis for the recording.

Caller-identification opener. Lucy's very first utterance on every demo call is a warm greeting that identifies her and the brand, verbatim: "Hi! This is Lucy from Automate I.T. How are you doing today?" (the brand "AutomateIT" is spoken as "Automate I.T." with dots so the text-to-speech reads each letter individually; the controller is AutomateIT Online Ltd). She then waits for the recipient to reply. In her very next turn, immediately after the recipient replies and before any substantive discussion of their business, Lucy discloses that the call is recorded for quality and that the recipient is welcome to hang up at any time, and confirms with one question that this is the demo call they requested via the website form. If the recipient does not recall requesting it, Lucy briefly reminds them who Automate I.T. is (AI phone agents for tradespeople) and that a demo request came through from their number; if it is genuinely not them, a wrong number, or they are not interested, she apologises and ends the call. So caller identity is given in the greeting, and the purpose of the call, the recording disclosure and an immediate verbal opt-out all follow in the immediately-following turn, within the opening seconds. The greeting is set as the Retell begin_message in scripts/setup-retell-demo-agent.mjs and pinned in Lucy's system prompt at src/lib/lucy-prompt.mjs, so it is always Lucy's first words and cannot be skipped. The recording disclosure, opt-out, purpose and demo-call confirmation are pinned as mandatory call-flow steps in that same system prompt at src/lib/lucy-prompt.mjs that Lucy is required to complete in her next turn, before any substantive discussion of the recipient's business. The demo is openly acknowledged: the prospect requested a demo call, and near the end of the call Lucy explicitly explains that she is an AI agent and that the call demonstrates exactly what the prospect's own customers would experience. Separately, if at any point a caller sincerely asks whether they are speaking to a person or a machine, Lucy is required by her system prompt to confirm honestly and immediately that she is an AI. If a caller asks where to find this notice or how to contact us during the call, Lucy directs them to automateitonline.co.uk/privacy or to ivan@automateitonline.co.uk.

PECR Regulation 24's caller-identification information requirements (postal address or freephone number) apply to unsolicited calls. As above, AutomateIT demo calls are solicited (the prospect submitted the contact form to request the callback) and Regulation 24 does not strictly engage. The call nonetheless meets the underlying transparency goal Regulation 24 protects: the greeting identifies the caller (Lucy, calling for AutomateIT Online Ltd, with the brand "AutomateIT" spoken as "Automate I.T."), and the immediately-following turn states the purpose of the call (the demo the prospect requested via the website form), discloses recording, and gives an immediate verbal opt-out, all within the opening seconds and before any substantive discussion of the recipient's business. A caller can be directed to this notice at automateitonline.co.uk/privacy or to ivan@automateitonline.co.uk on request.

When you use our chat widget on the marketing site, your messages and the bot's replies pass through our chat provider, ElevenLabs Conversational AI. We do not currently store transcripts of those chats in our own systems. ElevenLabs may hold them for a short period for service operation; their privacy policy applies to that processing.

3.2 Customer accounts

Once you sign up to AutomateIT we collect more, because we need it to run the product. The categories below are split into three sub-tables for readability.

3.2.1 Account and login

3.2.2 Business profile and configuration

3.2.3 Integrations, billing, files and feedback

We do not collect special-category data (health, race, religion, political opinions, biometric or genetic data) for customer accounts. If you tell us such information voluntarily in feedback or a support email, we treat it as ordinary personal data and do not use it for anything other than responding to you.

We do not collect or store payment card data. Customer billing payments to AutomateIT itself, when self-serve billing is added, will run through Stripe Checkout; we will only store the Stripe Customer ID and the metadata Stripe returns to us.

All of the customer-account fields above are necessary for AutomateIT to operate. If you do not provide them you will not be able to complete onboarding or use the service. Optional fields are clearly marked in the form.

3.3 End-caller data (AutomateIT acts as a processor)

When someone phones your AutomateIT number, the information from that call belongs to your business, not to us. In data protection terms, you are the "controller" (you decide what the information is used for) and we are your "processor" (we handle it for you on your instructions). In practice that means:

• You decide why the data is collected (to take a booking, take a payment, escalate to you, etc.).
• You set the retention period within the limits we make available to you.
• We process the data only on your documented instructions, which are the configuration choices you make during onboarding and in Settings.

The categories we process on your behalf include:

• The caller's phone number (as supplied by Twilio in the call signalling)
• Their name, where they say it
• Their address or postcode, where they share it for routing or service-area validation
• The full audio recording of the call, the speech-to-text transcript, and the AI's post-call summary, outcome label and sentiment classification
• Job details captured during the call (service requested, scheduled date and time, deposit status)
• Outbound SMS we send on your instructions (booking confirmation, payment link, etc.)
• A one-off deposit-payment receipt email we send to the caller on your instructions, where the caller shared an email address, after they pay a deposit through a Stripe payment link
• Cost and duration metadata for billing and analytics

The AI agent plays a short call-recording disclosure at the start of every call so callers know the call is being recorded. The disclosure currently says: "One quick thing, calls are recorded for quality." This is delivered in the agent's first spoken message before the agent takes any details from the caller. You as the controller are responsible for any further notice obligations to your callers, for example a written privacy notice on your own website that explains how you use the recording, transcript and any onward processing.

We sign or commit to UK GDPR Article 28 processor terms with you as part of our customer agreement. Those terms include sub-processor disclosure (section 6 of this notice), security obligations (section 11), assistance with data subject requests (section 9), and breach notification.

Joint-controller note (Article 26). For most aspects of the call (recording, transcription, routing, job creation, post-call analytics) AutomateIT acts as the customer's processor and the customer is the controller. There is one specific element where the design choice is AutomateIT's own and materially affects callers' rights: the auto-injected pre-call recording disclosure ("One quick thing, calls are recorded for quality.") is determined by AutomateIT, not the customer, and the customer cannot remove it. For that one element AutomateIT and the customer are joint controllers. The essence of the arrangement is that AutomateIT determines the disclosure wording (to satisfy UK GDPR Article 13 and PECR transparency), while the customer determines who is called, when, and what the call is about. Either party can be approached for a data subject rights request and the parties cooperate to respond.

3.3.1 Special category data in calls

Live phone conversations sometimes capture information that falls within Article 9 of the UK GDPR, most commonly health information shared by a caller during an emergency. We do not solicit such information and the AI agent is not configured to ask for it. Where it is volunteered we process it only to the extent necessary to (a) help the AI agent route the call appropriately and (b) provide the customer with the recording and transcript they need to do their job. To the limited extent AutomateIT itself processes special category data as a controller (for example, when an admin reviews a call transcript to support a customer or to investigate a service incident), we rely on Article 9(2)(c) of the UK GDPR for vital interests in emergencies involving risk to life, Article 9(2)(f) for the establishment, exercise or defence of legal claims, and Article 9(2)(g) substantial public interest read with paragraph 10 of Schedule 1 to the Data Protection Act 2018 (preventing or detecting unlawful acts) and, for any criminal-offence content under Article 10 of the UK GDPR, paragraph 33 of Schedule 1 (legal claims). An Appropriate Policy Document is maintained as required when relying on the Schedule 1 substantive paragraphs above (DPA 2018 Schedule 1 paragraph 39 sets the required content). Customers (acting as controllers) are responsible for ensuring they have a corresponding Article 9(2) condition for any onward use of the recording or transcript and for telling their callers what they will do with the information.

3.3.2 Member-of-the-public requests

If you are a member of the public who has called a tradesperson using AutomateIT and you have a question about your data, you can either contact the tradesperson directly or email us at ivan@automateitonline.co.uk. Where we hold your data only as the tradesperson's processor, we will route your request to them within 5 working days and copy you on the routing. We will help the tradesperson respond and, where they fail to respond within a reasonable period, we will respond ourselves to the extent permitted under our processor obligations.

3.3.3 No direct relationship with end-callers

End-callers have no contractual or commercial relationship with AutomateIT. They dialled the tradesperson's published number and reached our infrastructure as a consequence. This is why our role is processor-only, why the recording disclosure is mandatory and auto-injected by our backend, and why we publish this notice in language that is meaningful to a member of the public who has just had their voice recorded.

3.3.4 Recording disclosure as a built-in control

Unlike many call-recording setups where the disclosure depends on the customer remembering to read it, AutomateIT injects the disclosure into every customer's begin_message server-side at call start, by way of applyRecordingDisclosure() in src/lib/retell-recording-disclosure.ts. The customer cannot accidentally remove it from their saved greeting; the helper re-applies it on every call. This is a deliberate compliance-by-design control under UK GDPR Article 25.

3.3.5 Vulnerable callers

We recognise that emergency callers may include vulnerable adults, callers in distress, callers with hearing or cognitive impairments, and (occasionally) minors using a parent's phone. The recording disclosure played at the start of every call is short and clear by design. The customer (tradesperson) remains the controller and is responsible for any further accessibility-of-notice obligations under the Equality Act 2010. We do not perform automated profiling of caller vulnerability and we do not sell or share end-caller data with anyone outside the sub-processors listed in section 6.

3.3.6 Stripe Checkout payment-link flow

When the agent sends a payment link during a call, AutomateIT also creates a Stripe Checkout Session on the customer's connected Stripe account containing the deposit amount, a reference to the job, and (depending on session config) the caller's phone or email so they can be sent a receipt. AutomateIT does not store any card data.

When the caller completes that payment, Stripe notifies AutomateIT through a signature-verified webhook. On a confirmed payment, AutomateIT marks the job's deposit as paid and, where the caller gave an email address during the call, sends the caller a one-off deposit-payment receipt by email through our transactional email provider, Resend (section 6). The purpose is simply to confirm to the caller that their deposit reached the business. The receipt contains the business name, the service (where captured), the date and the deposit amount; it contains no card data. It is a best-effort courtesy, so if the caller gave no email, or email delivery is not configured, no receipt is sent. AutomateIT sends this receipt as the customer's processor, on the customer's instructions, so the customer's own lawful basis for the call applies (see section 5.2) rather than a separate AutomateIT basis. AutomateIT also emails the business owner that the deposit has landed and, subject to the business's SMS preferences, texts them. If the business later refunds the deposit in full from their own Stripe account, the same webhook marks the job's deposit as refunded; no email is sent to the caller for a refund, because the caller's bank notifies them. This deposit webhook is built but dormant at the time of this version.

3.3.7 Where the call audio lives

Call audio is held at Retell. AutomateIT proxies the audio on demand from Retell to the authenticated customer's browser via /api/calls/[id]/recording. The proxy streams the bytes through; AutomateIT does not write the audio to disk or to any persistent store.

3.3.8 Job rows

Each booked job is stored on the jobs row with customer_name, customer_phone, customer_email, service, description, postcode, scheduled_at, deposit_amount, deposit_status, stripe_session_id, stripe_payment_intent_id and google_event_id. The stripe_payment_intent_id is a nullable Stripe reference written only when a deposit is actually paid; it lets a later full refund be matched back to the right job (it is empty for any deposit taken before the deposit webhook shipped). The deposit_status records the deposit lifecycle and can read paid, failed or refunded. We retain those rows for 6 years from job completion to align with HMRC accounting record requirements (see retention policy section 4.7).

3.3.9 International transfers of end-caller data

Where end-caller data is transferred outside the UK to a sub-processor (currently Retell AI in the United States, and onward to Retell's own infrastructure provider), we transfer it under the UK-US Data Bridge (where the sub-processor is DPF/UK-Extension certified) or under the UK Addendum to the EU SCCs (where it is not), in each case as the customer's authorised sub-processor under their processor agreement with us. Where you connect a CRM, end-caller job and client data would additionally reach ServiceM8 (Australia) or Jobber (operated from Canada with hosting that includes the United States); those connectors are not yet enabled for customers and the Article 46 safeguard each needs is not yet in place (see sections 6 and 7), so no customer end-caller data is transferred to a CRM in the interim. The customer is the controller of those onward transfers and our processor agreement records the customer's general authorisation under UK GDPR Article 28(2) for us to engage the sub-processors listed in section 6.

3.3.10 CRM push (optional)

If you connect a field-service CRM (currently ServiceM8 or Jobber), AutomateIT pushes the booked job and the caller's contact details into your own CRM account on your instruction. This is push-only: we write the job and client record to your CRM and do not read your CRM data back into AutomateIT, save that one connector (ServiceM8) makes a minimal lookup by client name at the moment of writing so it can match an existing client rather than create a duplicate; we do not import or store any CRM data from that lookup. The fields pushed are the booked-job fields already described above: the caller's name, phone and email, the full street address (or the postcode where no street address was captured), the postcode, the service, any free-text booking notes, the scheduled time and its duration, and a derived price line item. We never push the call audio or the transcript to a CRM. The connector is not designed to send special-category information, but, as with any free-text field, it may be incidentally present where a caller has volunteered it in the free-text booking notes that are pushed. Once the record is in your CRM it lives there under your own account and your own relationship with that provider, and you manage it with them.

The push does not run during the live call. It runs afterwards on a separate scheduled job, so a slow CRM can never hold up answering a caller. The CRM connection tokens are stored in our database (encrypted at rest by our database provider) and written only by a server-side database function; they never reach your browser.

This connector is not yet enabled for customers. ServiceM8 sends data to Australia and Jobber's hosting realistically includes the United States, and neither provider yet gives us an adequate international-transfer safeguard, so the CRM connection is currently restricted to the Director's own account for controlled testing while those safeguards are put in place. See section 6 (sub-processors) and section 7 (international transfers) for the detail.

3.4 Where we got your data from (Article 14)

Most of the data we hold about you comes directly from you. The exceptions are:

• Your business name, address, business phone, opening hours and Google Place identifier may be pre-filled from the public Google Places record you confirm during onboarding. The source is the public Google Places API.
• A candidate list of services and service areas may be extracted from the public homepage of the business website you give us. The source is your own public website. We perform this extraction once at onboarding using Anthropic Claude as described in section 4. The fetched HTML is not retained after the extraction completes.
• A 128px favicon may be fetched from your Google Places record if you have not uploaded a logo.
• During onboarding, your typed company-name search is sent to the public Companies House API for a register lookup.

For end-callers (people who dial your AutomateIT number), the caller's phone number is supplied by Twilio in the call signalling. We do not look up the caller in any external database. All other end-caller data is supplied by the caller themselves during the conversation.

4. How we use AI and automated processing

Several parts of the product are powered by third-party AI services. The table below summarises each one. None of these systems make decisions that produce a legal effect on you or anything similarly significant within the meaning of UK GDPR Article 22.

When you generate an agent avatar we send Gemini (a) your typed description (after sanitising by Claude Haiku to remove crude language and content-policy violations), (b) your uploaded business logo as a reference image, and (c) the gender you selected. Gemini returns a generated image that we resize and store. We never send Gemini your customer or call data.

The auto-classifier on feedback has a manual override built in. If the classifier picks the wrong category, our admin can change it from a dropdown. The classifier output is metadata only and does not change what we send to you.

4.1 Article 22 and significant decisions

None of the AI features in AutomateIT currently produces a "significant decision" within the meaning of Articles 22A to 22D of the UK GDPR (as inserted by Section 80 of the Data (Use and Access) Act 2025). They suggest, polish, summarise, transcribe or classify, and a human or the customer's own pre-configured rules drive the customer-facing outcome. The Retell agent makes automated routing decisions during a live call (whether to treat a call as an emergency, whether to escalate to a human, whether to send a payment link). We treat these as decisions with potentially similar significance and apply the following safeguards: a human (the tradesperson or their nominated escalation contact) is always reachable as a fallback; the agent does not finalise a payment without explicit caller confirmation; a caller who is unhappy with how the agent handled their call can ask for human review by contacting the tradesperson or AutomateIT directly. If we ever introduce a feature that would amount to a significant decision based solely on automated processing, we will tell the affected data subject, give them a route to make representations and to contest the decision, and enable meaningful human intervention.

4.2 No training on your data

None of our AI sub-processors are permitted to use your customer or call data to train or improve their general models. Anthropic's Commercial Terms exclude commercial API inputs and outputs from training. Google's paid Gemini API does not use prompts to improve products. Retell does not train on customer data. We monitor each provider's training-default position and will switch off any flag or stop using the provider for the affected workflow if a change would put customer or end-caller data into training without an opt-in.

5. Lawful bases for processing

In plain English: most of what we do with your data is to provide the service you signed up for. Where that's not the legal hook, the table below shows what is.

5.1 Special category and criminal-offence data

To the limited extent AutomateIT processes special category data as a controller (see section 3.3.1), we rely on Article 9(2)(c) of the UK GDPR for vital interests in emergencies, Article 9(2)(f) for legal claims, and Article 9(2)(g) substantial public interest read with paragraph 10 of Schedule 1 to the Data Protection Act 2018 (preventing or detecting unlawful acts). For criminal offence data under Article 10 of the UK GDPR (for example where a call recording happens to capture an allegation of an unlawful act), we rely on paragraph 33 of Schedule 1 (legal claims) and paragraph 36 read with paragraph 10 of Schedule 1 (preventing or detecting unlawful acts), and only to the extent strictly necessary. An Appropriate Policy Document is maintained as required when relying on the Schedule 1 substantive paragraphs above (DPA 2018 Schedule 1 paragraph 39 sets the required content).

5.2 Article 6 lawful bases

All SMS sent by AutomateIT, both to prospects and to customers, are transactional under PECR. We do not send SMS marketing. If we ever introduce SMS marketing in future, we will obtain prior consent under PECR Regulation 22 and update this notice and our forms before doing so.

PECR Regulation 22 boundary for prospect follow-up emails. Regulation 22 governs unsolicited commercial email. AutomateIT sends two types of email to prospects who have submitted the contact form but not yet signed up:

(a) Transactional follow-up of a demo the prospect explicitly requested. Examples: the signup link sent after Lucy successfully demos; the rescheduling email sent if Lucy could not reach the prospect; the "we missed you, here is your signup link" email sent after the third failed call attempt. These are continuations of the demo the prospect actively requested. They contain no promotional content beyond the link to complete the signup the prospect already initiated. Lawful basis: Article 6(1)(b) UK GDPR (steps at the prospect's request prior to entering into a contract). PECR Regulation 22 does not engage because these are not unsolicited marketing communications.

(b) Marketing emails to prospects (e.g. promotional newsletters, product update announcements, re-engagement campaigns). AutomateIT does not currently send these. If we ever did, Regulation 22 would require prior consent (the soft opt-in only covers existing customers, not prospects). The contact form would need an additional, unbundled consent checkbox before any such marketing could be sent.

AutomateIT operates on the strict (a) basis only. Any future move to (b) requires a privacy notice update, a contact-form consent change, and a written scope decision recorded in section 13.

The lawful-basis row above ("Sending you transactional emails ... Article 6(1)(f) legitimate interests for prospects") should be read together with this boundary paragraph: the legitimate-interests language reflects an operator-side balancing test for the residual logging and abuse-prevention layer around the email send, while the customer-facing communication itself rests on the Article 6(1)(b) pre-contractual basis described in (a) above.

6. Sharing and sub-processors

We never sell personal information. We do share it with carefully chosen sub-processors who run parts of the platform on our behalf. Each one is contractually bound to use the data only for the purpose we set, to keep it secure, and to delete it when we ask. The two optional CRM connectors (ServiceM8 and Jobber) are the exception while they remain restricted to the Director's own account and are not yet enabled for customers: ServiceM8's published agreement does not yet include the transfer terms we need and Jobber publishes no data agreement at all, so we will put an appropriate written contract in place with each before that connector is offered to any customer. Our error-monitoring provider (Sentry) is listed below for transparency but is currently dormant: the integration is switched off (no DSN is configured), so it processes no data yet, and we will counter-sign Sentry's data processing agreement and create its EU data region project before we switch it on.

The list below is current at the effective date of this notice. We will update it when it changes.

For clarity, the categories of recipients of your personal data are: (a) the sub-processors listed above; (b) our professional advisers (accountants, solicitors, insurers) under professional confidentiality; (c) regulators, courts and law-enforcement bodies where we are legally required to disclose; (d) a buyer of our business in the event of a sale, on terms at least as protective as these. Other AutomateIT customers do not see your data; the application enforces row-level security on every customer-facing table so each customer can only see their own rows.

We will notify customers at least 30 days before adding or changing a sub-processor that processes their personal data, and customers may object on reasonable data-protection grounds during that window.

Several sub-processors above use their own infrastructure providers (typically Amazon Web Services, Google Cloud Platform or Microsoft Azure). Each sub-processor publishes its own sub-processor list and is contractually required to flow our transfer protections down to those onward recipients. Links to the relevant sub-processor lists are available on request.

7. International data transfers

In short: data we send abroad goes to the EEA (covered by UK adequacy) or to the US (covered by the UK-US Data Bridge where our provider is certified, otherwise by a contractual safeguard). Where you connect a CRM, data may also go to Australia (ServiceM8) or Canada and the US (Jobber), under the contractual safeguards described below. The CRM connections are not yet enabled for customers.

The UK has made adequacy regulations for the European Economic Area (the Data Protection (Adequacy) (European Union) Regulations 2021 and the Data Protection (Adequacy) (European Economic Area) Regulations 2021). Transfers to providers in Ireland, Germany or any other EEA state therefore do not need additional safeguards. We will update this policy if the EEA adequacy regulations are not extended beyond their current sunset date.

The UK Government has made adequacy regulations (in force from 12 October 2023) covering transfers to US organisations that are self-certified under the EU-US Data Privacy Framework and have opted into the UK Extension. Where a US sub-processor is so certified, we rely on the UK-US Data Bridge.

For transfers to US providers where we rely on the UK IDTA or the UK Addendum to the EU SCCs (rather than on the UK-US Data Bridge), we will complete and document a Transfer Risk Assessment in line with ICO guidance, considering the laws of the destination country, the supplementary measures in place, and the practical likelihood of access by foreign public authorities. The current TRA register is held by the Director and available to the ICO on request.

CRM connections (optional, not yet enabled). If you connect a field-service CRM, the booked-job and client details you push reach the CRM provider abroad. Jobber is operated from Canada (Octopusapp Inc.). The UK recognises Canada as providing an adequate level of protection, but only for data that is subject to Canada's PIPEDA, and we have a positive duty to confirm PIPEDA applies before relying on that adequacy; in any case Jobber's hosting realistically includes the United States and Jobber is not certified under the UK-US Data Bridge, so we cannot rely on adequacy alone. ServiceM8 is an Australian company (ServiceM8 Pty Ltd); the UK has no adequacy decision for Australia. For both providers, the transfer therefore needs an Article 46 safeguard (a UK IDTA, or the UK Addendum to the EU SCCs) backed by a Transfer Risk Assessment. Those safeguards are not yet in place: ServiceM8's published data agreement does not include them, and Jobber publishes no data agreement at all. That is why the CRM connections are restricted to the Director's own account for now, and are not offered to customers, until the Director has put the necessary safeguards in place. The detail of each assessment is recorded in our TRA register.

We do not rely on the Article 49 derogations as a routine transfer mechanism. They are reserved for occasional, non-systematic transfers where neither adequacy nor an Article 46 safeguard is available.

The UK Addendum we use is the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses, Version B1.0, in force from 21 March 2022.

If you would like a copy of the relevant transfer mechanism for any sub-processor, ask using the contact details in section 1.

8. How long we keep information

Detailed retention periods, trigger events and disposal methods are in the AutomateIT Data Retention Policy at docs/legal/data-retention-policy.md.

9. Your rights under UK GDPR

If you're a tradesperson who has signed up: these rights apply to your account data. If you're a member of the public who phoned a tradesperson on an AutomateIT number and want a copy of the call: ask the tradesperson, they're the controller. We will help them respond.

To exercise any of these rights, email ivan@automateitonline.co.uk or write to the registered office. We may need to verify your identity before we act, particularly for access and erasure requests. We will respond within one calendar month, and we will tell you within that period if we need to extend by a further two months because the request is complex.

There is no fee for exercising your rights, except in the rare cases UK GDPR allows (for example if a request is "manifestly unfounded or excessive").

Some of these rights are subject to exemptions in Schedule 2 to the Data Protection Act 2018. We do not routinely rely on any Schedule 2 exemption. We may, on a case-by-case basis, rely on paragraph 2 of Part 1 (prevention or detection of crime) when responding to a lawful police or HMRC request, and on paragraph 5 (legal proceedings) to the extent strictly necessary to defend a legal claim. We will record our reasoning whenever we do so. We do not rely on the immigration exemption in section 23 of the DPA 2018 in any context.

AI assistant memory access and erasure. Customers can view their AI assistant memory facts and request deletion of any individual fact at any time from /settings/agent/memory in their dashboard. Deletion requests soft-delete the row immediately (so the assistant stops using the fact on the next turn) and a daily retention cron hard-deletes within 24 hours. Subject access requests covering the wider AI assistant chat history can be made by emailing ivan@automateitonline.co.uk.

10. Cookies and similar technologies

We try to keep cookies to the minimum necessary to run the site. The current set is:

We do not currently set advertising, analytics or third-party tracking cookies. If we ever do, we will do so only with your prior consent through a clear cookie banner.

11. Security

Phone calls and customer data need real protection. Here is what we do:

• Live call audio is carried over encrypted SIP between Twilio and Retell; the recording is stored at Retell, encrypted at rest, and only fetched on demand by our backend (never the customer's browser) when a tradesperson plays it back through /api/calls/[id]/recording.
• Transcripts, AI summaries, business profile data and feedback rows live in Supabase (Dublin), encrypted at rest by Supabase. Logos and generated avatars sit in Supabase Storage with the same encryption.
• All transport between browser, our app on Railway, and every sub-processor is TLS 1.2 or higher.
• Row-level security is enforced on every customer-facing table. Each customer can only see their own rows. Service role keys are server-only and never reach the browser.
• Admin access from developer endpoints is restricted to the Director, MFA-protected, and logged.
• Dependency vulnerability scanning runs on every deploy. Access logs are reviewed monthly.

No system can be guaranteed completely secure. If you discover a security issue with AutomateIT please email ivan@automateitonline.co.uk rather than disclosing it publicly, and we will work with you to fix it.

11.1 Privacy by design and by default

We bake the following controls into the product so they are always on:

• The recording disclosure is server-injected into every customer's begin_message (section 3.3.4) so it cannot be turned off by accident.
• Row-level security on every customer-facing table prevents cross-tenant data access.
• End-caller transcripts are scrubbed at 24 months without admin action (see retention policy).
• We do not collect a "caller name" field by default; the agent only captures it if the caller volunteers it during the conversation.

11.2 Breach process

Internal breach process: any AutomateIT person who detects or suspects a personal data breach must report it to the Director within one working hour. The Director assesses the risk against the Article 33 and Article 34 thresholds, notifies the ICO via the online form within 72 hours where required, notifies affected data subjects where the risk to their rights and freedoms is likely to be high, and notifies any affected customer-controllers within 24 hours so they can meet their own 72-hour ICO notification deadline. Every breach (including those that did not require notification) is recorded in our internal breach log per Article 33(5).

All time periods in this section are calendar hours, not working hours. The 72-hour ICO notification clock and the 24-hour customer-controller commitment run over weekends, bank holidays and Christmas Day. The internal 1-hour-from-becoming-aware reporting target is also calendar hours.

12. Children

AutomateIT is built for adults running their own trade business. Our customer-facing surfaces (signup, onboarding, dashboard) are not directed at anyone under 18. Under UK law, the age at which a child can consent to an information society service is 13 (Article 8 of the UK GDPR as retained in UK domestic law). The phone agent itself may incidentally record a call from a child (e.g. a teenager dialling the plumber on a parent's phone). We treat any such recording as ordinary call data under section 3.3, and the customer-controller is responsible for handling it appropriately under their own privacy notice. If you believe we hold personal data of a child where there is no legitimate reason to, contact us and we will delete it.

In particular: an end-caller dialling a tradesperson on AutomateIT's number may incidentally be a child (e.g. using a parent's phone in an emergency). The customer (tradesperson) is the controller of those calls; AutomateIT, as processor, ensures (a) the recording disclosure is played at the start of every call regardless of caller age, (b) the AI agent is not configured to ask for age, identity verification, or any data category that would treat a child differently, (c) the customer-controller is responsible for any further age-aware decisions on what to do with the recording (e.g. seeking parental consent if they decide to retain it for their own purposes).

13. Changes to this notice

We will update this notice when our processing changes, when we add or remove a sub-processor, or when the law requires us to. The current version and effective date are at the top and bottom of the document. We will tell you about material changes by email if you have an active customer account, and by updating the version note on this page in any case. The previous version remains available on request.

For material changes that affect how your data is used, we will update this notice within 30 days of the change taking effect, and notify active customers by email.

Change log.

• Version 1.4 (2026-07-05): Added Sentry (Functional Software, Inc. d/b/a Sentry) as a platform-wide error-monitoring sub-processor in section 6, listed for transparency but currently dormant (the integration is switched off with no DSN configured, so it processes no data yet; sendDefaultPii: false, no session replay). Event data will be stored in Sentry's EU region (Frankfurt) and Functional Software, Inc. is certified under the EU-US Data Privacy Framework with the UK Extension, so the transfer relies on the UK-US Data Bridge with EU SCCs and the UK Addendum as fallback; the Sentry data processing agreement will be counter-signed and the EU project created before the scaffold is switched on. No change to lawful bases or retention periods for existing data.
• Version 1.3 (2026-07-03): Documented the Stripe deposit webhook (built but dormant at this version). Added a new recipient class and purpose: a deposit-payment receipt email sent to the end-caller, on the customer's behalf, where the caller gave an email address (the end-caller data list in section 3.3, section 3.3.6, and the Resend role in section 6). Added the jobs.stripe_payment_intent_id column and the refunded deposit status, plus full-refund handling, in section 3.3.8. No change to lawful bases, retention periods or the sub-processor inventory.
• Version 1.2 (2026-06-25): Added the optional CRM connectors (ServiceM8 and Jobber) throughout: a CRM-token row in section 3.2.3, a new section 3.3.10 (CRM push), two sub-processor rows in section 6, and a CRM paragraph in section 7 on the Australia and Canada/US transfers. Recorded that the CRM connections are customer-optional, push-only, and not yet enabled for customers, pending an executed Article 46 transfer safeguard for each provider. No change to lawful bases or retention periods for existing data.
• Version 1.1 (2026-06-18): Updated section 3.1's description of the demo-call ("Lucy") caller-identification disclosures to match the current call flow. Caller identity is now given in the opening greeting, and the purpose of the call, the recording disclosure and an immediate verbal opt-out follow in the immediately-following turn, within the opening seconds and before any substantive discussion of the recipient's business. The demo call is openly acknowledged and Lucy gives an explicit AI demonstration near the end of the call; the honesty-when-asked obligation is unchanged. No change to lawful bases, retention periods or sub-processors.
• Version 1.0 (2026-05-04): Initial publication.

14. Complaints

If you are unhappy with how we have handled your personal data, please contact us first using the details in section 1 so we have a chance to put it right.

You also have the right to complain to the UK Information Commissioner's Office. The ICO's contact details are:

Information Commissioner's Office Wycliffe House Water Lane Wilmslow Cheshire SK9 5AF

Helpline: 0303 123 1113 Online complaint form: https://ico.org.uk/make-a-complaint/

The ICO is the UK's independent regulator for data protection. It can investigate complaints, require us to provide information through an information notice, audit our processing through an assessment notice, require us to take or stop a particular action through an enforcement notice, and impose monetary penalties of up to £17.5 million or 4% of our worldwide annual turnover (whichever is higher) for serious breaches of UK GDPR or the DPA 2018.

You can go straight to the ICO without contacting us first, but we'd appreciate the chance to put things right ourselves.

15. Effective date and version

Version: 1.4 (AI-drafted) Effective date: 2026-07-05 Document owner: Ivan Aguilar Mari, Director, AutomateIT Online Ltd.

16. Data Protection Impact Assessment

Because the AutomateIT platform involves call audio recording, AI sentiment classification, and innovative AI technology applied to UK consumer voice data, we have committed to carrying out a Data Protection Impact Assessment in accordance with UK GDPR Article 35. The DPIA covers (a) the systematic description of the processing, (b) the necessity and proportionality assessment, (c) the risks to the rights and freedoms of data subjects (in particular UK end-callers), and (d) the technical and organisational measures we have adopted to mitigate those risks. The DPIA is reviewed when processing materially changes and at minimum annually. A redacted summary is available to customers and to the ICO on written request.