Giday: Data Handling, Retention and Sub-processors

Version 1.24. Last updated 25 October 2026. Launchr Pty Ltd (ABN 46 696 518 206), operator of Giday, giday.com.au. Latest change: section 4 describes the greeting as each business's own wording, which must say the call is recorded; two version-history notes now point at 3.3, where the opt-out check on automatic texts is described. Recent changes, newest first, are listed under Version history at the end of this statement.

This document explains what Giday does with the information that passes through it: what we collect on a call, which other companies touch it, where it is processed, how long we keep it, how to get it deleted, how we protect it, and what we do if something goes wrong.

It is written to be checked. Where we cannot state something accurately yet, we say so rather than guess, and where a period is not yet enforced automatically we say that too. We handle personal information as if the Australian Privacy Principles applied to us in full, and nothing here is intended to exclude, restrict or modify any right you have under the Australian Consumer Law or the Privacy Act 1988 (Cth).

Where this document and the Privacy Policy give different periods for the same thing, the one more favourable to you applies (as in every document in the pack) and we will correct the other document.

1. Who holds what, and who is responsible

There are three parties in every Giday call.

You, the caller. You rang a business. Your name, your number and what you said are yours.

The client. This is the business you actually rang: the plumber, the trades business, the agency. They chose to use Giday to answer their phone. The message, booking or quote belongs to them, and they hold their own copy of it in their diary, their job system and their phone.

Launchr Pty Ltd. We build and operate the Giday platform. We hold the transcript, the message, the booking and the quote so that we can deliver the service to the client. The call recording is held by our voice provider in the United States, not by us (section 3). We are not the business you rang, and we do not sell your information to anyone.

Both the client and Launchr can hold the same record at the same time. That matters for deletion (section 6) and for breach notification (section 8), so we set out how it works in both places.

2. What we collect on a call

• The caller's phone number, as presented by the phone network.
• Call audio. Every answered call is recorded (except in restricted mode, section 10, where call audio is not recorded at the voice provider), and a spoken notice at the start of every call tells the caller before anything is captured (section 4).
• A transcript of the call, produced automatically, and a short written summary of what the caller wanted.
• The name, contact details and details of the enquiry the caller gives to the agent.
• The booking, if one is made: date, time, address, job description.
• The quote, if one is given: the figure the agent actually quoted on that call.
• SMS we send: the recipient number, what the message was for, and whether it sent. We do not store the message text.
• A consent record where a caller agrees on the call to receive quote follow-up messages: the fact of consent, the words the agent recorded on the call, the call reference and the timestamp.
• Call metadata: which number was called, when, how long it ran, and the outcome.
• Client account data: business name, contact details, plan, agent configuration, price list, knowledge base content, the answer to the health-service question we ask at sign-up (section 10), and any credentials the client gives us for an integration.
• Billing data: subscription, invoices and payment history. We never see or store full card numbers (section 3).

We do not ask callers for identity documents, payment card details, government identifiers, or health information; for health and medical clients the agent runs in restricted mode and is instructed not to hear or record clinical detail (section 10). If a caller volunteers something sensitive, it ends up in the recording and the transcript like anything else they said, which is one reason retention is short and deletion is available.

3. Sub-processors

These are the other companies that necessarily touch data in order for Giday to work. We keep this list current. If we add one, we update this page and tell clients (section 11).

No card data touches us. When a client subscribes, the card is entered on a checkout page hosted by Stripe. At sign-up the card is saved, not charged, and we receive a confirmation that it was saved and a customer reference; once a plan is kept we receive a confirmation of each payment. We do not receive, hold or log the card number, and there is no point in our systems where it could be read.

3.1 What we do not do with your data

• We do not sell it, rent it, or share it with data brokers, advertisers or list builders.
• We do not use call recordings, transcripts or caller details to train any model of our own.
• We do not use one client's call content for the benefit of another client.
• We do not use a caller's number for our own marketing. Any SMS from Giday goes out in the client's name, for the client's purposes, and only in the two cases in 3.3.

We have not audited every sub-processor's own model-training and retention terms, so we do not make a claim on their behalf. Where a supplier offers a setting that stops it using customer data for its own training, we intend to have it on; we will name each one here as we confirm it, rather than publish a blanket promise we cannot yet evidence.

3.2 Integrations a client turns on

If a client connects ServiceM8, Giday pushes booking and job information into that client's own ServiceM8 account. That is the client's system and the client's relationship with ServiceM8, not a Giday sub-processor arrangement. We store the credentials the client gives us, encrypted (section 7), and we use them only to push data the client asked us to push. We do not pull the client's customer records into Giday.

Where a client gives us a calendar feed, we read it so the agent does not double-book them. We do not write into it.

3.3 SMS

Giday sends two kinds of message, both in the client's name, never in Giday's or Launchr's:

1. Transactional messages: a booking confirmation, a reminder an hour before the booking (where the business has switched reminders on), a cancellation, a message passed to the business owner. These are factual messages about a specific job and do not carry an unsubscribe line, because they are not marketing.
2. Quote follow-ups, which are optional and only ever sent where the caller gave express consent on the call.

Every quote follow-up identifies the client business and gives contact details for it, as required by section 17 of the Spam Act 2003 (Cth), and carries an opt-out instruction. Messages go from an ordinary Australian mobile number that can receive replies, so replying STOP actually reaches us; if the identification is missing or the opt-out line would be truncated, the message is blocked rather than sent. We keep the consent record so consent can be proved, and we keep the opt-out suppression separately for each client so that opting out of one business's messages does not silently break another's.

Every automatic job text, including a booking confirmation from a business's online booking page, is sent through the guarded path, so a suppressed number does not receive one (closed 24 October 2026).

3.4 Where data is processed, and what leaves Australia

We will not tell you your data stays in Australia, because that is not true today and we are not going to write something we cannot stand behind.

Call audio, transcripts, caller phone numbers, message content, booking and quote content, and client account data are processed outside Australia, primarily in the United States, and on Cloudflare's distributed network where a single country is not always the right description of where processing happens.

Three specific honest limits:

• ElevenLabs. The call audio, the speech recognition and the transcription happen in the United States, and the recording and the transcript are held there. This is the single largest overseas flow in the product: every word of every call goes through it.
• Cloudflare. Giday's records sit in Cloudflare D1 and Workers KV. Jurisdictional restriction on Cloudflare storage is available for some products and jurisdictions — the United States, the European Union and FedRAMP environments — and there is no Australian jurisdiction option. Workers KV cannot be jurisdiction-restricted for stored values at all. So the strongest thing that can honestly be said is which jurisdiction, if any, each resource is pinned to. We publish that configuration here once it is pinned and verified, and until then we say what we are saying now.
• Twilio. Our Twilio account runs in Twilio's default region, us1, so the call metadata, the SMS content and the delivery records sit in the United States. Twilio carries the call and plays the receptionist's greeting, which carries the notice; it does not hold a recording of the call. Twilio operates an Australian region, and its own documentation says that during the current phase of that rollout it does not guarantee all data stays within the selected region — so even if we moved, we would not describe it to you as an Australian-only guarantee.

Under Australian Privacy Principle 1.4, an entity's privacy policy must state whether it is likely to disclose personal information to overseas recipients and, if practicable, the countries involved. This section is our attempt to do that properly rather than hide behind "our service providers may be located overseas".

3.5 Advertising conversion reporting

This section is about people who visit giday.com.au and prospective clients who click one of our ads — it never involves callers, call content, or an existing client's service data.

When someone arrives at giday.com.au from a Meta ad and then signs up, we report that signup to Meta, server-to-server — at most twice: once when the signup form is submitted, and once when sign-up is completed by saving a card, which is how Meta learns the ad produced a client rather than a form-fill. Each report contains the same, and only the following: the email address and mobile number given at signup, hashed (SHA-256) before they leave our infrastructure; the click reference Meta itself attached to the ad link; the landing page and the time; and the IP address and browser type of the signup request. Meta matches the report to the ad so that we can measure which ads produce clients and audit what we are billed. This report is produced by our own server, and a signup that arrived any other way (organic search, a referral, a typed address) is never the subject of one.

Meta's pixel (live from 3 October 2026). Separately from that report, the public pages of giday.com.au load Meta's pixel. For every visit to those pages it sends Meta, directly from the visitor's browser: the page address and referring page, IP address and browser type, and Meta's own first-party cookies (_fbp, and _fbc for arrivals from a Meta ad). On the sign-up page it additionally reports two events: that the visitor interacted with the page, and that the first step of the form was completed. It does not send form contents — automatic advanced matching is switched off, and so is Meta's "track events automatically" setting. It is not present on the client dashboard, the post-checkout page or any client's booking page. Meta receives this as an independent company under its own terms, in the United States. Automatic advanced matching was on by default on the dataset from 3 October 2026 until we found and disabled it on 5 October 2026; during that window Meta's code could read hashed form input from the sign-up page.

Meta Platforms receives this as an independent company under its own privacy policy, processed in the United States, not as our sub-processor: once the report is matched, its use inside Meta's advertising system is governed by Meta's terms, which is exactly why we keep the report's contents this small.

Google (live from 29 August 2026). An ad-attributed signup is now also reported to Google Ads, through Google's server-side Data Manager API, from our own server. Unlike Meta there is exactly one Google report per signup, sent when sign-up is completed by saving a card — never at form submission. The Google report is deliberately smaller than the Meta one: it contains only the click reference Google itself attached to the ad link (gclid, gbraid or wbraid), the time the trial started, the identifiers of our own Google Ads account and conversion action that route the report, and two consent flags. Those flags are our assessment that consent applies for Australian traffic under Australian law, not a per-person signal captured from the visitor — we collect no such signal, and the report carries nothing about the person for those flags to govern. It contains no email address and no mobile number, hashed or otherwise — Google can match on its own click reference, so there is no reason to send anything about the person, and we do not. A Google-sourced signup with no click reference is simply never reported. There is no Google tag on the site, and adding one would breach section 12 of the Privacy Policy. Google LLC receives this as an independent company under its own terms, processed in the United States. The click record behind all of this is the first-party measurement described in section 12 of the Privacy Policy, and it keeps those retention promises: IP address and browser details deleted within 90 days, the whole click record within 14 months.

4. The recording notice and the consent record

Every answered Giday call starts with the agent's own spoken greeting, before anything is captured to storage, and the recording notice is inside it. Each business chooses its greeting's wording, but every greeting must tell the caller the call is recorded. The standard greeting, for example, is: "Giday, you've reached [the business] — [the receptionist] speaking, on a recorded line. How can I help you?" If a caller asks whether they are speaking to a person, the agent says plainly that it is the business's virtual receptionist and never claims otherwise.

The notice is permanent. There is no off switch, for any client, on any plan. In New South Wales, South Australia, Western Australia, Tasmania and the ACT the notice is how consent to record the call is obtained, so a call without it would leave both the client and us with no consent position at all. A setting that could turn it off existed briefly and was withdrawn on 26 August 2026; the code that answered a call without the notice was deleted, not just disabled. A business that does not want its callers told the call is on a recorded line should not use Giday.

Said exactly: the notice names the business and says the call is on a recorded line. It does not use the word "transcribed", and it does not offer the caller a route to continue the call without being recorded. The call is transcribed, which is why this document and the Privacy Policy say so, and a caller who objects is offered deletion instead, and a transfer where the business has set one up (section 6).

We do not currently keep a per-call log of whether the notice completed on each individual call. The notice is part of the call flow itself rather than a setting, so there is nothing that could differ between accounts — but we would rather tell you what we do not log than describe a record that does not exist.

Where a caller consents on the call to a quote follow-up SMS, we keep a consent record: the structured fact of consent, the words the agent recorded, the call reference and the timestamp. It is stored with the call and quote record. We do not keep a separate long-lived audio excerpt of the consent moment. A caller can ask us to delete the consent record, and if they do we delete it and stop the messages, because we will not keep sending messages on the strength of consent we can no longer show.

5. How long we keep things

Once information is no longer needed for any purpose we are allowed to use it for, it should be destroyed or de-identified. That is the rule in Australian Privacy Principle 11.2, and it is the reason the periods below are short rather than indefinite.

5.1 Retention schedule

This table says what happens today, including where a period is enforced by a scheduled job and where it is not yet.

A client can ask for shorter periods than these, and we would rather they did. We do not offer longer periods for call audio or transcripts.

Deleting records early does not change anyone's legal position about the recording itself. It reduces how much exists, for how long, and what a security incident could expose. That is the honest reason we do it.

5.2 Backups

Records deleted from live storage can survive for a short time in operational backups before the normal cycle overwrites them. We do not keep long-term archives of call audio or transcripts. Where a deletion is requested on a call, we delete from live storage within an hour; where it is emailed to us, within 10 business days. The record is gone from operational backups within a further 35 days.

5.3 When an account closes

When a client's service ends, their callers' records — call recordings, transcripts, messages and our log of texts — are deleted 7 days later, from our systems and from the voice provider's, and the written cancellation confirmation names that date. A number we supplied is held for 30 days. The account's settings and knowledge base are kept for 90 days, so that a returning client does not start again, and are then deleted by a scheduled job, along with the account's bookings and quotes, or sooner on request. Billing records stay for the 7 years described above. On request at any time before deletion, we will give the client an export of their call records, messages, bookings and transcripts, and help them port their number away. That is not conditional on why they left, and it applies even if we are in a dispute about money.

For up to 30 days after a service ends, a Giday-supplied number keeps answering with a short message telling callers the line is not taking calls just now, and the call then ends. Nothing on that call is recorded or transcribed and no message is taken, so it carries no recording notice.

5.4 The repeat-trial record

When a free trial ends we keep a one-way fingerprint of the email address, mobile number and IP

address that trial used, so the same person cannot take the free trial repeatedly.

The secret key is never written to the database, so a copy of the table on its own reveals nothing

and cannot be reversed. The record is not used for marketing, profiling or anything else, is

never shared with anyone, and is deleted 24 months after the trial ended.

An IP match never blocks a sign-up by itself. Carrier-grade NAT means a whole suburb of mobile

users can share one address, as can an office or a caravan park, so treating an IP as an identity

would refuse genuine customers. Only a matching email or mobile prevents a second free trial, and

neither ever prevents a paid sign-up.

5.5 Marketing contacts

Where a client has given express consent — an unticked box at sign-up that they chose to tick — we

keep their name, business, email address, the fact and date of that consent, and a record of what

we sent. Consent, sender identification and a working unsubscribe are requirements of the Spam Act

2003, not preferences. An unsubscribe is actioned immediately and is honoured globally, and it

never affects transactional email such as booking notifications or billing.

5.6 The calendar feed

A client can subscribe their own calendar (Google, Apple, Outlook) to a private Giday feed so their

bookings appear on their phone. It is off unless they turn it on.

When they subscribe, that calendar provider receives the booking details — the caller's name,

phone number, the job description and the time. That is the client's own decision about their own

customers' information, and it is worth them understanding it: Google or Apple will hold a copy of

those bookings under their own terms, not ours.

The feed URL contains a long random token derived per client. It is a key, not just a link —

anyone holding it can read that client's bookings — so it should be pasted only into their own

calendar app, and it can be revoked from the dashboard at any time, which immediately breaks every

copy of the old URL. The feed is served no-store and noindex, and carries the last fortnight

and the next 90 days rather than the client's entire history.

6. Deletion, access and correction

6.1 If you are a caller

You can ask us for any of the following.

• To know what we hold about your call.
• A copy of the transcript or the message that was taken.
• Correction of something recorded wrongly: a misheard name, a wrong number, an address the agent got wrong.
• Deletion of all records of the call, including the recording and the transcript.
• Not to be recorded. Tell the agent during the call and it will delete the recording and transcript of that call within an hour of you hanging up. The recording exists until then — the agent cannot stop recording part-way through a call.
• To stop SMS. Reply STOP to any marketing message, or ask us.
• To speak to a person. Ask the agent to put you through to the business owner, where the business has set that up, or to take a message for a call-back.
• To know whether you are speaking with an AI. Ask, and the agent says plainly that it is the business's virtual receptionist. It never claims to be a person.

How to ask. Say it on the call — that is the fastest route and it is actioned within the hour. Otherwise email hello@giday.com.au with the number you rang from, the business you were calling, and roughly when. We ask for only enough detail to match your call. We will not require you to create an account, log in, or send identity documents.

How long it takes. We acknowledge a request within 2 business days. A deletion asked for on the call is actioned within an hour. Said exactly: the purge runs on an hourly sweep, so if the call is still being processed at our voice provider when the sweep runs, it goes on the next one instead. An emailed request is handled by hand today, so allow up to 10 business days; anything else is completed within 30 days, and usually within 5 business days. If we need longer, we tell you why and when.

What we charge. Nothing, for any of the above.

6.2 If you are a client

You can read your call records, messages and bookings in your dashboard, and full call transcripts there from the Steady plan. Ask us and we will delete an individual call, a caller's records, or your whole account, and send you an export at any time. A self-serve export and delete are on the way; until they ship, one email gets you the same thing, and we will do it within 10 business days at no charge. Records we are required to keep, such as billing records, survive account deletion for the periods in section 5.

6.3 What we cannot do

• We cannot delete the client's own copy, and a deletion does not undo a message we already sent them. Deleting a call removes the recording, the transcript and our record of the call. A message, booking or quote the agent already passed to the business is that business's record; we will pass your request on to them and give you their contact details. Whether they delete their own copy is a matter between you and that business.
• We cannot delete what we no longer hold. Once a transcript has passed its retention period it is gone; we cannot produce it for a caller who asks for it later, and we would rather say that plainly than imply otherwise.
• We keep a minimal record of the request itself, so we can show we honoured it.

7. Security

Launchr is a two-person company. The security posture below reflects that honestly. We would rather a client read this and ask a hard question than read a page of badges.

7.1 What we do

• Data in transit is encrypted using TLS, between carriers and our telephony provider, between our platform and every sub-processor, and between clients and the dashboard.
• Client credentials are encrypted by us at the application layer before they are stored. That covers integration tokens, such as ServiceM8, and any API key a client gives us. They are decrypted only at the moment they are used to make the call the client asked for.
• Transcripts and call records are held in Cloudflare D1 and Workers KV, and rely on the encryption at rest those services provide by default. We do not add a second layer of application-level encryption to call content. The call recording is held by ElevenLabs in the United States, under its own controls.
• The recording notice is part of the call flow, not a setting. There is no configuration that removes it, and the no-notice code path was deleted rather than disabled (section 4).
• Access to production data is limited to the two directors of Launchr Pty Ltd. We do not employ a support team, and we do not give contractors access to production call data.
• We look at a client's call content only when we need to for a support request, a fault, a legal request, a deletion request, or a security investigation.
• Client data is separated by tenant identifier and every request that reads call content is scoped to a single client's tenant.
• Marketing SMS sending is gated on a stored consent record with a timestamp and a call reference, enforced at send time rather than by policy, and blocked outright to a suppressed number.
• Transcript retention is enforced by a scheduled sweep. Where another period in section 5 is not yet enforced in code, section 5 says so on the row rather than presenting it as a promise.
• If a client wants evidence for any statement in this section, ask and we will show you the configuration.

7.2 What we do not claim

• We do not hold ISO 27001 certification, a SOC 2 report, or an independent penetration test report. If that is a procurement requirement, we are not a fit yet, and we will tell you that rather than talk around it.
• We do not operate per-client encryption keys for call content.
• We do not currently offer a contractual availability guarantee or credits for downtime, other than the outage credit in clause 26.4 of the Terms of Service.
• We cannot promise your data never leaves Australia (section 3.4).
• We do not describe our platform as "bank-grade", "military-grade", or any other phrase that means nothing.

8. If something goes wrong: data breach response

By a breach we mean unauthorised access to, unauthorised disclosure of, or loss of the information we hold.

We run the following process, and we run it whether or not the Notifiable Data Breaches scheme in Part IIIC of the Privacy Act 1988 (Cth) is held to apply to a business of our size. We do not rely on any exemption when deciding whether to tell people their information has been exposed.

1. Contain. Cut the access, rotate the credentials, take the affected component offline if needed, and stop the loss getting bigger.
2. Tell the affected clients within 48 hours of forming a reasonable suspicion that a breach has occurred, with what we know at that point. This matters because a client business that is itself covered by the Privacy Act has its own 30-day assessment clock, and it can only start that clock if we tell it.
3. Assess. We carry out a reasonable and expeditious assessment and take all reasonable steps to finish it within 30 days of becoming aware of grounds to suspect a breach, as section 26WH(2) requires. In weighing whether the breach is likely to result in serious harm we work through the matters in section 26WG: the kinds of information involved, their sensitivity, the protections in place, who is likely to have obtained the information, and the nature of the harm. Call recordings and anything touching health raise that assessment, and we treat them accordingly.
4. Notify the Commissioner. If it is an eligible data breach under section 26WE(2), we prepare a statement and give it to the Australian Information Commissioner as soon as practicable, containing what section 26WK(3) requires: who we are and how to contact us, a description of the breach, the kinds of information involved, and what we recommend affected people do.
5. Notify the people affected. Under section 26WL that means notifying each individual, or those at risk of serious harm, or publishing the statement and taking reasonable steps to publicise it. Where callers are affected, callers get told, not just our clients.
6. Coordinate with the client. Where we and a client hold the same records, notification by one of us can discharge the other under section 26WM, but each of us remains responsible for showing we complied. As between us, we notify the affected callers and tell the client we have done it.
7. Fix and record. We write up what happened, what we changed, and what we would do differently, and we keep that record.

If a breach involves health information, additional State obligations can apply independently of the Commonwealth scheme, including under the Health Records Act 2001 (Vic), which has no small business exemption. We assess that separately rather than assume the Commonwealth position covers it.

9. Third-party personal information we will not accept

Giday's knowledge base is for the client's own business content: services, prices, hours, policies, service areas, frequently asked questions, and the client's website copy.

We ask clients not to load other people's personal information into it, and the client agreement asks them to take reasonable care and tell us if some gets in. Concretely:

• No customer lists, contact lists or CRM exports into the knowledge base.
• Integrations push, they do not pull. Where we connect to a client's job system, we send the booking or job we were asked to send. We do not import the client's customer records into Giday. Where we read a calendar feed, we only read busy times.
• Website import means the public pages of the client's site. We read the address we are given and a few of its usual pages (such as services, about, pricing, FAQ and contact), we obey robots.txt, and where the address does not look like it belongs to that business we hold the draft for a person here to check before it can reach the agent. Nothing reaches a live agent until the client has read it and saved it.

This is deliberate. The less third-party personal information the platform ingests from sources other than the caller themselves, the smaller the problem is for everyone.

10. Health and medical businesses

We take on health and medical clients in restricted mode. That covers medical and dental practices, allied health, physiotherapy, chiropractic, podiatry, psychology and counselling, aged care, disability care, pharmacy and veterinary businesses, and anything else where callers ring about their health.

The legal position that used to make us decline the sector has not changed and we are not pretending it has. A business that provides a health service and holds health information is covered by the Privacy Act 1988 (Cth) whatever its size — section 6D(4)(b) — and no consent or contract term changes that. Victoria's Health Records Act 2001 has no small business exemption at all. Health information is also wider than people expect: an appointment time attached to a patient's name is health information, and so is "ringing about my test results". Those obligations are the practice's. What changed is our answer to them: rather than decline the work, we built a receptionist that is instructed to hear and hold as little as a phone service can, and we wrote down exactly what she does. We have not taken legal advice on the sector.

How that works in practice:

• We ask at sign-up. One required question: does your business provide a health service — no, yes, or not sure.
• Yes sets a single restricted flag on the account when the agent is created. That one flag drives everything below, so the prompt and the retention settings can never disagree about which mode a client is in. You are shown the limits before you finish.
• Not sure is an ordinary signup. A clinician knows what they are; we do not second-guess them into a mode they did not ask for. You can ask us to switch it on at any time.
• In restricted mode the agent does not discuss symptoms, conditions, diagnoses, medications, results, treatments or therapies; writes no clinical detail into any message except an emergency alert, which passes on what the caller said (only that the caller wants a call back, with name and number, and whether they said it was urgent; a booking carries the practice's own appointment type, never a symptom); and gives no health advice.
• Call audio is not recorded at the voice provider, and the provider's transcript is scheduled for deletion rather than retained (section 5.1). No audio and no transcript; we keep a call-log entry and the call-back message (number, time, length and outcome, and the message), as for any client.
• In restricted mode only, the agent tells a caller who describes danger to life or limb to hang up and ring 000, ends the call, and texts the account holder at once — or, where the practice has chosen it, first puts them through to the practice's nominated emergency number or first says the practice's own words, then tells them to ring 000; the text is sent in every case, with the caller's number and what they said, and is kept as a message record. She does not ring 000 and does not assess severity. An ordinary agent is given no emergency instruction and does not end a call for anything other than its normal conclusion.

If a caller to an ordinary Giday client mentions something health-related, it is handled like anything else sensitive they said: we did not ask for it, retention is short, and it can be deleted on request (sections 2 and 6).

11. Changes to this statement

We will change this document as the product changes. If a change is material, including adding a sub-processor, extending a retention period, or changing where data is processed, we will give clients at least 30 days' notice by email to the account address and publish a dated summary of what changed. Every version is dated at the top. We do not make changes to this document with retrospective effect.

12. Contact

Privacy and data requests: hello@giday.com.au

Everything else: the contact details on giday.com.au

Postal: Launchr Pty Ltd, Level 1/63-73 Ann St, Surry Hills NSW 2010

If you are unhappy with how we handled a privacy request, tell us first and we will try to fix it. You can also complain to the Office of the Australian Information Commissioner at oaic.gov.au. If the matter involves health information collected in Victoria, the Victorian Health Complaints Commissioner also has a complaints process.

Nothing in this document excludes, restricts or modifies any guarantee, right or remedy you have under the Australian Consumer Law or any other law where it would be unlawful to do so.

Version history

What changed in 1.24, 25 October 2026: section 4 says each business chooses its greeting's wording, which must tell the caller the call is recorded, with the standard greeting as an example; it quoted one fixed greeting. The notes for 1.21 and 1.22 now point at 3.3, where the opt-out check on automatic texts is described (they said section 4). Nothing new is collected and nothing is kept longer.

What changed in 1.23, 24 October 2026: the retention table in 5.1 now gives the same periods as 5.3 — when a client's service ends, call records, transcripts, messages and the text log are deleted by a scheduled job 7 days later, and bookings and quotes 90 days later; it said "deleted with the account". Restricted mode is stated the same way everywhere: no audio and no transcript; we keep a call-log entry and the call-back message (5.1, 10). Section 4 quotes the notice as the greeting says it, "on a recorded line". Nothing new is collected and no period gets longer.

What changed in 1.22, 24 October 2026: booking confirmations from a business's online booking page now go through the guarded path too, so the limit noted in section 3.3 is closed.

What changed in 1.21, 22 October 2026: the one-hour booking reminder is a transactional text, sent through the guarded path, so an opted-out number never receives one (section 3.3).

What changed in 1.20, 22 October 2026: corrections so this document matches the service; nothing new is collected and no period gets longer. Section 3 now lists Google, whose Gmail service holds the Giday team's own mailbox: sign-up details, texts sent to our platform number, help requests and some forwarded enquiries reach us there. We used it before this version and should have listed it. After a service ends, the line's short message says only that it is not taking calls; it no longer opens with a recording notice, because nothing on that call is recorded (5.3). Restricted-mode calls are not recorded (section 2). A caller's deletion request removes the call record within the hour, as the rest of this document says, not "immediately" (5.1). The 1.19 note below is corrected. Section 10 now says a restricted-mode emergency text passes on what the caller said and is kept as a message record.

What changed in 1.19, 22 October 2026: a closed account's settings, price list, knowledge base, bookings and quotes are now deleted by a scheduled job 90 days after the service ends, together with the receptionist at our voice provider; before this there was no scheduled deletion. Nothing is kept longer than before.

What changed in 1.18, 22 October 2026: clarifications so this document matches the service; where two documents give different periods, the one more favourable to you now applies here too, the same rule as the Terms; nothing new is collected and no period gets longer. The greeting that carries the recording notice is voiced by ElevenLabs in the receptionist's voice and played by Twilio, and section 3 now says so. After a service ends, the line's short message takes no message and is not recorded (5.3). Settings and knowledge base are deleted 90 days after an account closes, as 5.1 says (5.3). Website import reads the address given and a few of its usual pages (section 9). Full transcripts are in the dashboard from the Steady plan, and putting a caller through depends on the business having set it up (6.1, 6.2). Sections 5.4 to 5.6 are renumbered; there were two sections numbered 5.3.

What changed in 1.17, 13 October 2026: the Cloudflare row in section 3 now includes Cloudflare Web Analytics, a visit counter Cloudflare adds to every page of giday.com.au. It was running, by Cloudflare's default, before this document described it. It sets no cookie and concerns website visitors only, never callers or call content.

What changed in 1.16, 13 October 2026: corrections so this document matches the service. Call audio is held by the voice provider for 90 days, a period we set. When a client's service ends, their callers' records are deleted 7 days later and a supplied number is held for 30 days; the earlier text said 90 days for both. Email quoting and what it stores are now described. The card is saved at sign-up, not charged. The dashboard does not play recordings.

What changed in 1.15: a restricted-mode practice may choose how a life-or-limb call is handled; the 000 instruction stays the default.

What changed in 1.14: restricted-mode messages may carry one word on urgency and bookings carry the practice's own appointment type; no clinical detail is written.

What changed in 1.13: version 1.12 described Level 1/63-73 Ann St, Surry Hills NSW 2010 as our registered office. It is our postal address; our registered office has not changed. No change to where data lives or who can reach it.

What changed in 1.11: section 3.5 now describes Meta's pixel, which runs on the public pages of giday.com.au from 3 October 2026. The previous version said there was no pixel; that stopped being true on that date. It also records that Meta's automatic advanced matching was on by default from 3 October until we disabled it on 5 October 2026.

What changed in 1.10: the greeting quoted in this document now matches the greeting the line actually speaks. Launchr amended the wording on 2 October 2026 and it reads “Giday, you’ve reached [your business] — [your receptionist] speaking, on a recorded line. How can I help you?”. This is a correction to a quotation, not a change to your rights or ours: the recording notice is in the same place, inside the greeting, spoken in your receptionist’s own voice on every call before any audio is captured, and it still cannot be switched off.

What changed in 1.9: section 10 — the 000 instruction, the hang-up and the owner text apply in restricted mode only; an ordinary agent is given no emergency instruction.

What changed in 1.8: a retention row for unfinished sign-ups — the stepped sign-up form saves completed steps on our side for 7 days.

What changed in 1.7: section 10 — health and medical clients are taken on in a restricted mode instead of being waitlisted; the retention table gains a row for it.

What changed in 1.4: section 3.5 now covers Google as well as Meta — a smaller report carrying no email or mobile at all.

What changed in 1.3: new section 3.5 — the ad-conversion report we send Meta when a click on a Meta ad becomes a signup, with Google named in advance. It involves prospective clients only, never callers or call content.