For everyone
Glo Privacy Policy
What personal information Glo holds, why, who it goes to, where it is processed, how long it is kept, and how to ask for access or correction.
Version 1.5. Effective 1 October 2026.
Glo is operated by Connor Wu trading as Glo, ABN 23 380 080 435, of Unit B14, 161 Arthur Street, Homebush West NSW 2140. Privacy enquiries and general enquiries: hello@welcomeglo.com. A real person reads it.
This policy is published at /legal/privacy and is in force. We will give you a copy in another
format if you ask for one.
The short version
Glo is booking, payment and record keeping software that Australian businesses use to run their day to day operations. That means we hold a lot of information about people who never signed up with us: the customers of the businesses that use Glo.
- If you run a business that uses Glo, we hold your account, your business details and your records. The whole policy is for you, and section 2 says which parts matter most.
- If you booked work with a business that uses Glo, we hold your booking on that business's behalf. Section 2.2 is written to you, and section 6 is the notice you should have been given at the moment you typed your details in. Sections 11 to 15 are our obligations to you and you can hold us to them.
- If you are just reading our website, it depends which page you are on. Our public marketing pages may carry advertising tags from Meta and Google, because we advertise Glo to the businesses that might use it. The pages a business's clients are sent to carry nothing of the kind, and neither do these legal pages. Section 2.4 and section 10 are the short answer.
Three things worth knowing up front, because they are the ones people ask about:
- We never see or store your card number. Card details are typed on our payment provider's own page, not ours (clause 5.7).
- We never advertise to a business's customers. Not ours to advertise to (clause 9.4).
- We cannot delete everything on request, and we will tell you why rather than quietly keeping it. Australian tax law requires business records to be kept for five years, and that beats a deletion request (clause 12.4).
1. About this policy
1.1 Who we are
Glo is software Australian businesses use to run their day to day operations. It is operated by Connor Wu trading as Glo, ABN 23 380 080 435 ("Glo", "we", "us", "our"). Our postal address is Unit B14, 161 Arthur Street, Homebush West NSW 2140.
We are the software. We do not do the work, we do not attend jobs, and we are not a party to the agreement between a business and its customer.
1.2 What this policy covers
This policy explains what personal information we collect, why we collect it, what we do with it, who we give it to, how we keep it, how long we keep it, and what you can do about it.
It applies to the whole of the Service, defined in clause 1.4.
1.3 What this policy does not cover
- What a business does with your information outside Glo. If a business keeps a paper diary, or texts you from their own phone, that is their handling, not ours, and their own privacy practices apply.
- Other companies' websites. Where we link to a payment page, a mapping service or anything else run by somebody else, their privacy policy governs what happens there.
- Information that is not personal information, such as anonymous counts and totals that cannot be connected to any person.
1.4 Words we use
These definitions do not depend on how you reach Glo, so this policy still holds if we add a new way of reaching it.
- "the Service" means the Glo software and everything we supply through it,
however you reach it. That includes our website, the dashboard, the public
booking pages at
/book/, client tracking pages at/track/, invoice and quote pages, the emails we send, the text messages described in clause 9.6, and any other channel we add later, such as a mobile or tablet application, push notifications, or a connection to another business system. If we add one of those, we will update this policy, and in particular the provider list in clause 8.3, before it starts handling personal information, on the notice terms set out in clause 8.3. - "business" means a business that holds a Glo account, together with its owner, administrators and staff who use that account.
- "client" means a person who books, or is booked in for, work by a business using Glo. A client is not a Glo account holder and never signs up with us.
- "personal information" has the meaning given in the Privacy Act 1988 (Cth): information or an opinion about an identified individual, or an individual who is reasonably identifiable, whether or not it is true and whether or not it is recorded in a material form.
- "the Australian Privacy Principles" or "the APPs" means the 13 principles in Schedule 1 to the Privacy Act 1988 (Cth).
1.5 How this policy fits with our other documents
If you run a business that uses Glo, this policy is one of the documents that make up your subscription agreement with us. The whole agreement is:
- the Terms of Service, at
/legal/terms; - the Refunds and Cancellations Policy, at
/legal/refunds; - the Acceptable Use Policy, at
/legal/acceptable-use; - this Privacy Policy, at
/legal/privacy; - the Data Processing Addendum, at
/legal/data-processing; and - the Plan you chose.
The Terms come first, with three exceptions. The Refunds and Cancellations Policy comes first on anything about refunds, cancellations or what happens when a payment fails. The Data Processing Addendum comes first on the handling of personal information about your clients. And this Privacy Policy always governs how we handle personal information, which is what it is for.
Two documents are not part of that agreement. Our Client Terms of Use at
/legal/client-terms and our SMS Terms at /legal/sms govern a different
relationship, between us and a business's own client. They sit outside a
business's subscription agreement and nothing in them changes that agreement.
2. Who this policy is for, and which part applies to you
Glo sits between three different groups of people, and they are in very different positions. Read the row that describes you.
| If you are | You reach Glo by | The parts written for you |
|---|---|---|
| A business that uses Glo, or someone on its team | Signing in to the dashboard with an email and password | All of it. You are our customer. Sections 3, 4.1, 5, 7 to 9, 11 to 20 |
| A client of a business that uses Glo | Following a link to a booking page, a tracking page, an invoice or a quote. You never sign in | Sections 2.2, 2.3, 4.2, 5.2, 5.3, 6, 8, 11 to 15 in particular. The rest still applies to your information |
| A visitor to our website | Reading our public pages | Sections 2.4, 4.4, 5.5, 8.3, 10, 16 to 20 |
2.1 Businesses that use Glo, and their staff: our customers
If you hold a Glo account, or you are on a team that does, you are our customer. We decide, jointly with you where you configure it, what we collect about you and why. You deal with us directly. Every right in this policy is yours to exercise against us.
2.2 A business's own clients: not our customers, but we hold your information
If you booked work with a business that uses Glo, you have no account with us, you never agreed to anything with us, and you probably reached a Glo page through a link without noticing whose software it was.
We still hold a lot of information about you, and we are still answerable for it. That is the reason for section 6 and for the whole of sections 11 to 15. Nothing in this policy asks you to deal with the business instead of us. Clause 13.3 explains why going to the business first is usually faster, and why we will never use that as a reason to turn you away.
2.3 What our role is
For a business's own account information (clause 4.1), we decide what we collect and why. It is our information about our customer, and we answer for it in full.
For a business's client information (clause 4.2), the business decides. The business chooses what to record about their customer, what notes to write, what services to offer, whether to take a deposit, and how long to keep working with that person. We hold and process that information on the business's behalf, as their service provider, and we act on the business's instructions.
That does not make us a bystander. Two things follow, and both protect you:
- We hold your information, so Australian privacy law makes us directly answerable for how we secure it and handle it. Section 11 (security), section 12 (how long we keep it), section 13 (access and correction) and section 14 (data breaches) are our obligations, not the business's, and you can hold us to them.
- We do not get to use it for our own purposes. Because it was collected for the business's purposes, we may only use it to supply the Service, plus the narrow additional uses set out in clause 7.3. That is why we do not market to clients (clause 9.4), do not sell information (clause 7.4), and do not build other products out of a business's customer list.
A note for anyone who works with European or United Kingdom terminology. Australian law does not use the words "controller" and "processor", and this policy deliberately does not build its structure on them, because they are terms from the EU General Data Protection Regulation and importing them would misdescribe the Australian position. If those laws ever applied to a Glo customer, the closest equivalents would be: Glo as controller of a business's own account and billing information, and Glo as processor of a business's clients' personal data, processed on the business's documented instructions.
Our Data Processing Addendum at /legal/data-processing sets out the terms on which we
handle personal information on a business's behalf. It applies automatically to
every Glo account, not only to customers in Europe, and you do not have to sign
anything or ask for it. It is worth reading whoever you are, because it carries
things this policy only summarises: who notifies whom after a data breach (its
clause 7.4), the 30 day notice and exit right when we add a provider (its clause
8.6), and the terms on which we help you answer an access request from one of
your own clients (its clause 5.5). Its Annex A adds the extra terms the GDPR and
the UK GDPR require, if and when either of those laws applies to a customer. See
also section 17.
2.4 Website visitors
Which page you are on decides the answer, so this clause has two halves. The second half is the one that matters if somebody sent you a link.
Our public marketing pages, which today means our home page at welcomeglo.com and nothing else:
- They may carry advertising tags from Meta and Google. We buy advertising to reach the businesses that might use Glo, and those tags are how we find out whether an ad we paid for brought somebody here. Clause 4.4 lists what they collect. This clause is the notice, and the policy that covers them is effective 7 September 2026.
- Where we use them, they report your visit to Meta and to Google, they set cookies of their own on your device, and those companies are able to recognise the same browser on other sites carrying the same tags. That is what an advertising tag is for, and we would rather write it down than call it measurement and leave you to work it out. Section 10 is the cookie answer, and clause 10.3 says why there is still no banner and what that reasoning now rests on.
- Meta and Google are overseas recipients, in the United States among other places. We are required to tell you that, which is what this clause is doing. Clause 8.3 lists them as providers of what happens on those pages and says where each of them processes, and clause 8.4 is the longer answer about what an overseas disclosure means and what we remain answerable for.
- Once you sign in to a business account you are no longer only a visitor, and clause 4.1 covers what we then record about how the dashboard is used.
Every other page. That means every page a business's client is ever sent to, a booking page, a tracking page, a public invoice, a public quote and an unsubscribe link, and it also means the signed-in dashboard and these legal pages you are reading now:
- No advertising tag, no third-party script and no third-party frame. None of it, on any of them. This is not a description of what we happen to have built so far. Those pages are set up to refuse a third party's script outright, page by page, so an advertising tag cannot appear on one because somebody pasted it into the wrong file.
- If you are a client of a business that uses Glo, the only cookie you will ever meet is the booking draft cookie, which holds what you typed into a booking form so that you do not lose it between steps. None of the four cookies in clause 10.1 is set on our marketing pages either, but that is a smaller point than this one. See section 10.
- Our hosting provider handles the technical information any web server needs in order to send you a page, and our rate limiting counts requests against an identifier such as an IP address so that nobody can flood the site. That is the whole of it.
3. Our commitment: we follow the Australian Privacy Principles
3.1 The commitment
We handle personal information in accordance with the Australian Privacy Principles. We deal with access requests, correction requests and complaints to the standards the Privacy Act 1988 (Cth) sets, and we run the data breach process in section 14 as if the Notifiable Data Breaches scheme bound us.
3.2 Why we say it that way
Some small Australian businesses sit outside parts of the Privacy Act because of their turnover. We are not claiming that exemption, and this policy makes no claim in either direction about our legal status. We are not going to ask you to work out our turnover in order to know how your information will be treated.
What is written above is a commitment we are making to you, not a legal conclusion about ourselves. It is enforceable as a statement about how we operate: if we said it and did not do it, that is a misrepresentation, and we would rather be held to the standard than argue about whether it applies.
Two further points, because they are true regardless of any exemption:
- The Spam Act 2003 (Cth) applies to us whatever our size. See section 9.
- The statutory right to sue for a serious invasion of privacy, in force since 10 June 2025, applies to us whatever our size, and it is available to a business's clients directly against us without going through any regulator.
4. What personal information we collect and hold
The tables below are meant to be complete. If you think something is missing, tell us at hello@welcomeglo.com and we will correct this policy.
4.1 About a business that uses Glo, and its team
| Category | What that means in practice |
|---|---|
| Identity | Your name, and the name of your business |
| Contact details | Your email address, your phone number, your business email address, your business phone number, and your business address |
| Sign-in credentials | Your password, which we never store in a readable form. We cannot read it or recover it for you |
| Account role and status | Whether you are an Owner, Admin or Staff member, and whether the account is active or disabled |
| Sign-in security records | Count of failed sign-in attempts, any lock-out expiry time, and the time of your last sign-in |
| Business profile | Your business name, your public booking page address (the "slug"), your ABN, whether you are registered for GST, your GST accounting basis, your timezone, your logo, and your brand colour |
| Your own policy text | The terms and conditions and cancellation policy you write for your own customers. They are your words, not ours, and they are shown to your clients on your booking page and on their tracking page exactly as you wrote them |
| Booking settings | Your booking mode, booking window, buffer times, cancellation window, deposit percentage, size labels and status labels |
| Payment identifiers | Your connected payment account identifier (money you receive), your customer identifier with our payment provider (money you pay us), and your subscription status. Not card numbers. See clause 5.7 |
| Bank transfer details | Only if you enter them. The details your clients need to pay you by bank transfer or PayID: the name to pay, your PayID and which kind of PayID it is, your BSB and account number, and a short note to your clients. We show them to your clients on their tracking page and on their invoice while something is owing, so that they can pay you directly. See clause 7.1 |
| Activity records | Audit log entries recording actions taken in your account, including the action, the time, the actor, an IP address, a browser user agent string, and a record of the details of the action |
| Usage records | Which parts of the dashboard your team uses. Which screen was opened and when, which of a small set of actions was taken, the role of the person and the plan the business was on at the time. No IP address, no browser user agent, and no free text, which is what tells this apart from the audit row above: that one exists to answer "who did this to my account", this one exists to answer "is this feature worth keeping". Where a screen's address would name one of your clients, the name is removed before it is recorded, so it reads as "a client record was opened" and never which one. It is not collected on your booking page, your clients' tracking pages, or a public invoice or quote. You can ask us to stop recording it for your account and we will, usually the same day, with no reason needed and no effect on anything else. See clauses 7.1 and 12.1a, and Cookie Policy section 5.1, which also explains why that is an email rather than a button |
| Notifications | In-app notices generated for your team, including who caused each one |
| Correspondence | Anything you send us by email, and our replies |
4.2 About a business's clients
This is information a business records about their own customers, held by us on that business's behalf.
| Category | What that means in practice |
|---|---|
| Identity | Full name |
| Mobile number | Stored in international E.164 format, for example +61412345678, and a record of whether and when that number was verified |
| Email address | Where one is given |
| Free-text notes | Notes the business writes about the client, in the business's own words. See clause 4.5 |
| Whether you have said stop | Where you have used the link on one of the two emails described in 9.4, a record that you did: the business, the email address, when, and which route you used. Never edited and never deleted. See clause 9.5 |
| Logged contact | What somebody at the business wrote down about a call, a text, a meeting or a visit: which of those it was, when it happened, how long it took, how it went, anything typed about it in their own words, and a date they set to follow it up. Written only by the business, never by the Service. See clause 4.5 |
| Emails we sent | For every email the Service sends you: the kind, the subject line, the address it went to, when, whether the mail provider accepted it, and the provider's own identifier for it. Not whether it arrived and not whether you opened it, because we do not know either. See clause 12.1a for how long we keep it |
| Texts we sent | For every text the Service sends you, or tries to: the kind, the number it went to or would have gone to, the words of the message, when, whether our text message provider accepted it and, if it did not go, why, and that provider's own identifier for it. See clause 9.6, and clause 12.1a for how long we keep it |
| Figures worked out from the above | Counts and dates worked out from a client's own bookings, payments, messages and logged contact, and stored beside the record so a long client list can be sorted and searched: when they first and last booked, how many jobs, how many finished, how many were called off, what has been settled net of refunds, and when they were last in contact. Arithmetic over that business's own records, and nothing else goes into it. See clause 18.2 |
| Enquiries | Where somebody has asked a business about work and is not a client yet: a name, and whatever else they gave, which may be a phone number, an email address, a suburb, what they asked about, and how they got in touch. Typed by the business, never collected by the Service |
| Billing details | Optionally, an ABN, a billing email address and a billing address, where the client is a business or a fleet |
| Details of the things the business works on | Today the Service records these as vehicles. For each vehicle: make, model, year, colour, size class, how that size class was decided, whether a person has approved it, free-text vehicle notes, and registration. If we add another kind of item, we will update this policy before we do. See clause 4.6 |
| Booking details | The full street address the work happens at, and, where the address was picked from the suggestion list, Google's own identifier for that address. Then the date and time, notes, the service and add-on lines and their prices, the deposit amount, any discount code and the amount it took off, the status, which of the three ways a booking ended (the client called it off, the business cancelled work it had accepted, or the business declined it), and any reason given for that ending, in the words of whoever typed it: a client can type one when they cancel from their tracking page, and a business can type one when it declines |
| Message content | Everything written in the message thread attached to a booking, from both sides, and when each message was read |
| Payment records | The amount, whether it was a payment or a refund, the method, the status, when the money moved, a reference, notes, and the payment provider's own identifiers for the transaction. Not card numbers |
| Financial documents | Invoices, adjustment notes and quotes issued to the client, and the details frozen onto those documents at the moment they were issued |
| Returning-client links | A record linking a business and a client to a one-time link. It holds no personal information of its own |
| Notifications | In-app notices generated about the client's booking |
| Activity records | An IP address and an audit log entry each time the client does something that changes a record: making a booking on a booking page, removing a vehicle from it, cancelling, rescheduling or releasing a slot that was being held for a deposit from a tracking page, and accepting or declining a quote. The entry records the action, the time, that it was the client rather than the business, and the details of the action. See clause 12.1a for how long we keep it, and clause 7.5 for who can read it |
4.3 About a business's own records, which may contain other people's information
| Category | What that means in practice |
|---|---|
| Expenses | Date, description, amount, GST portion, payment method, notes, and a supplier name or supplier record |
| Receipt images | The image file itself, its filename, its type and its size. A receipt may incidentally contain personal information, for example a name on a docket or a signature. Those images are handled exactly like everything else in this policy |
| Vehicle logbook trips | Trip date, purpose, a "from" label and a "to" label written by the business, distance travelled, optional odometer readings, an optional reason, the job the trip was for where there was one, and who recorded it |
| Reports and exports | Summaries built from the records above, and copies of them generated as CSV or PDF files |
4.4 About website visitors
| Category | What that means in practice |
|---|---|
| Request information | The technical information any web server needs to send you a page, handled by our hosting provider |
| Rate limiting counters | An identifier for the requester, typically an IP address, and a count of recent requests, held for a short window so that nobody can flood the site |
| Anything you send us | If you email us, we hold your email address and whatever you wrote |
| Advertising tag information, on our public marketing pages only | Those pages may carry advertising tags from Meta and Google. Where we use them, they pass to Meta and to Google that a browser loaded the page, which page it was, the ad or the search that sent you where there was one, the identifier that company's own cookie put on your device, and the ordinary technical details of a web request including your IP address. No name, no email address, no phone number, no booking and no account goes with it. Meta and Google hold what they receive on their own terms, not ours, and both are overseas. See clauses 2.4, 8.3 and 8.4 |
Everywhere except those marketing pages, none of that happens. We collect no analytics about you, we do not profile you, we build no advertising audience, and we share nothing about your visit with an advertising network. That covers every page a business's client is ever sent to, and it is the half of this clause that matters most, because a client never chose to deal with us.
And nothing about a business's clients ever reaches an advertising network, from anywhere. We upload no client list to Meta or to Google, we send them nothing about a booking, a payment or an appointment, and we match nothing we hold against an advertising profile. Those tags never run where any of that information is.
A person signed in to a business account is no longer only a visitor, and the usage records row in clause 4.1 is what applies to them.
4.5 Free-text notes deserve their own paragraph
A business can type anything into a note about a client, or a note on a booking, or a note on a vehicle. We do not read those notes, we do not analyse them, and we do not restrict what a business may write. But whatever is in them is personal information about the client, and it is covered by this policy: it is secured the same way, kept for the same period, and disclosed on an access request the same way.
If you run a business that uses Glo: write notes you would be comfortable with your client reading, because a client can ask to see what we hold about them.
We do not ask for, and do not want, sensitive information. That means health information, racial or ethnic origin, political or religious beliefs, sexual orientation, criminal record or biometric information. There is no field for any of it. If a business types something of that kind into a free-text note anyway, it is still covered by this policy and by the higher standard the Privacy Act sets for it, but it should not be there.
4.6 Vehicle registration is never shown publicly
A vehicle registration is the one thing on a vehicle record that identifies a specific car to a stranger.
- The public booking flow never asks for a registration. Not once, at any step.
- A registration is never displayed on any public surface: not on the booking page, not on the tracking page, not on a public invoice or quote page, and not in any email.
- The field exists only for a business's own staff, inside the dashboard, and it is optional.
This is a deliberate design decision, and it exists to protect the client.
4.7 What we never collect
- Card numbers, expiry dates or security codes. See clause 5.7.
- Photographs of vehicles or of work done.
- Live location, GPS traces or vehicle tracking. The logbook records a distance a person typed in, and nothing follows anybody anywhere.
- Analytics, advertising or cross-site tracking data about a business's clients, of any kind. The advertising tags in clause 4.4 may run on our public marketing pages and nowhere else, and they never run on a page a client is sent to.
4.8 Information we never asked for
Sometimes information arrives that we did not ask for and would not have collected: something typed into a free-text note that does not belong there, a receipt image carrying somebody's signature or their card details, a document attached to a support email, a list pasted in wholesale that carries more than the job needs.
Where we become aware that we hold personal information we did not ask for and could not properly have collected, we work out whether we are allowed to keep it, and where we are not, we destroy it or de-identify it. Where the law requires us to keep it, for example because it has already become part of a business record, we keep it and it is covered by this policy in the ordinary way, and we will say which of those two applies.
If you think we hold something about you that should not be there, tell us at hello@welcomeglo.com.
5. How we collect personal information
5.1 Directly from a business that uses Glo
When you sign up, set up your business, invite a team member, configure your booking page, write an invoice or record an expense, you are typing the information in yourself.
5.2 Directly from a client, on a booking page or a tracking page
When you fill in a business's booking form, you type in your own name, mobile number, email address, the address the work happens at, the vehicle the job is for, and any notes you want the business to have. When you use the tracking page, you may send messages, reschedule or cancel.
Two things worth knowing:
- Nothing is written to any database until the last screen. If you fill in the first step and close the tab, you have not booked anything and you leave no record in anybody's system. The details you typed sit in a short-lived cookie in your own browser and then expire. See clause 10.2.
- The details you type never appear in the web address. They travel in that cookie precisely so they do not end up in a browser history entry, a bookmark or a referrer sent to another site.
5.3 From the business, about their client
A business can also add a client, a vehicle or a booking themselves, for example when somebody rings up. In that case we have collected personal information about you from somebody other than you.
Australian privacy law allows that where collecting directly from the person is unreasonable or impracticable, which it is for a record a business keeps about its own customers. It also requires that you be told. Section 6 is how we tell you.
5.4 From our service providers
Our payment provider tells us when a payment succeeded, failed or was refunded, and what it charged in fees. Our email provider tells us whether a message was accepted for delivery. We record what comes back so that the business's records are right.
5.5 From your device, automatically
Only the cookies in section 10, plus the technical request information in clause 4.4. On our public marketing pages, that also includes what any advertising tag there collects, which clause 2.4 explains and clause 4.4 lists.
For somebody signed in to a business account, one thing more: the browser tells us which dashboard screen was opened, which is the usage record in clause 4.1. It sets no cookie and stores nothing on your device. Nothing equivalent happens on a booking page, a tracking page, a public invoice or a public quote, so a client of a business is covered by the first paragraph alone.
5.6 If you do not give us the information
- A business cannot open an account without a name, an email address and a password, and cannot take payments without connecting a payment account.
- A client cannot make a booking without a name, a mobile number, an email address, the address the work is at, and, where the work is on a vehicle, enough about the vehicle to price the job. A deposit, where the business requires one, needs a payment.
- Everything else is optional. In particular, a client does not have to give a vehicle registration and will never be asked for one.
5.7 We never see or store card numbers, and here is why
When a payment is made through Glo, we do not show you a card form. We send you to our payment provider's own website, on their own domain, as a full page redirect. You type your card details there. When you are finished, they send you back to us and tell us only the outcome: paid, failed or refunded, for how much, and their own reference for it.
No card number, expiry date or security code ever reaches our servers, our database, our logs or our code. We could not disclose one if we were asked to, because we do not have it.
This was a deliberate choice and not a shortcut.
Two separate money flows exist and it is worth keeping them apart:
- A client paying a business goes to the business's own account with the payment provider. That money never passes through us and never sits in any balance of ours.
- A business paying us for their subscription goes to our own account with the same provider.
Both use the same hosted page and the same rule about card numbers.
5.8 Can you deal with us anonymously, or under a name that is not yours?
Australian privacy law says you should be given the option of not identifying yourself, or of using a pseudonym, wherever that is lawful and practicable. Mostly it is not practicable here, and this is why.
- Booking a job. A business has to know who the work is for, where to come, and how to reach you if they are running late. A booking made under a name that is not yours, with a number that is not yours, is a job nobody can turn up to. So the booking form asks for a real name, a real mobile number, a real email address and the real address the work is at.
- Holding a Glo account. We have to know who our customer is in order to bill them, to issue documents in their business's name, and to know who is entitled to their records.
- Where you can be anonymous. You do not have to identify yourself to read this policy, to read our public pages, or to ask us a general question about how Glo works. If you want to raise a privacy concern without naming yourself, you can, and we will look into it. We may not be able to give you a full answer about a specific record without knowing which record it is, and we will say so rather than string you along.
- Names you use. If you go by a name that is not the one on your birth certificate, use it. We do not check names against anything, and we never ask for an identity document to make a booking.
6. What a client is told when their details are collected
This section exists because Australian privacy law requires that a person be told certain things at or before the point their personal information is collected. It is written to a business's client, in the second person.
6.1 The notice
When you book work through a Glo booking page, or when the business you dealt with enters your details for you:
- Who is collecting it. The business whose page you are on is collecting it for their own purposes. Glo, operated by Connor Wu trading as Glo, ABN 23 380 080 435, of Unit B14, 161 Arthur Street, Homebush West NSW 2140, is the software that holds it for them. You can contact us at hello@welcomeglo.com.
- How we got it. Either you typed it in, or, if you booked by phone or in person, the business typed it in and we collected it from them rather than from you.
- Why. To take and manage your booking, to know the address to come to, to price the job, using your vehicle's details where the work is on a vehicle, to contact you about the job, to take a deposit or payment where one applies, and to make up the business's own business records, including any invoice or receipt. We also record an IP address and an audit log entry each time you make or change a booking, so that there is a reliable record of what was done and when. Clause 7.5 explains who can reach it, section 13 is how to ask us for a copy, and clause 12.1a says how long we keep it.
- Whether any law requires it. Generally, no. One exception: if the business issues you a tax invoice for $1,000 or more, Australian tax law requires that document to carry the buyer's identity or ABN. That is a general statement of the rule, not advice about your situation. See clause 12.3.
- What happens if you do not give it. We cannot take the booking without a name, a mobile number, an email address and the address the work is at. We can take it without anything else.
- Who we usually give it to. The business whose page you booked on, and the service providers listed in clause 8.3, who host our systems, process payments and send our emails and text messages. What you type in the address box also goes to Google, which is what produces the address suggestions you see as you type. That is suggestions only: no map is loaded, and nothing about where you are is collected.
- Overseas. Some of those providers process information outside Australia, including in the United States. Section 8 sets out which ones and what we require of them.
- Your rights. This policy explains how to get a copy of what we hold about you (section 13), how to have it corrected (section 13), and how to complain if you are unhappy with how we handled it (section 15), including how to take it to the Office of the Australian Information Commissioner.
6.2 The short form, and where it lives
The full notice is what you have just read. A short form of it belongs directly under the booking form on the business's booking page, at the moment you are typing, with a link to this policy. That is where a notice actually does its job, rather than three clicks away in a footer.
It is there. The booking form carries a short notice naming both the business and Glo, saying what is collected and why, and linking to this policy, with a longer notice a reader can open underneath it. The address field carries its own line at the point the address is asked for. This section remains the full version of what that notice summarises, and it is written to you in the second person for that reason.
The exact wording of that short form, and of every other point-of-collection
notice across the Service, is at /legal/collection-notice.
6.3 The business's part
Under clause 6.2 of our Acceptable Use Policy at /legal/acceptable-use, a
business must have a lawful basis for the client details they put into Glo, must
tell their own customers that they use booking and invoicing software, and must
point them at this policy. That obligation runs alongside the notice above, not
instead of it. The Acceptable Use Policy is part of a business's subscription
agreement with us: see clause 1.5.
7. Why we collect it, and what we do with it
7.1 The purposes, and why we are allowed to
Each row states what we do, which information it uses, and the basis for it in Australian Privacy Principle terms.
| What we do | Which information | Why we may, in Privacy Act terms |
|---|---|---|
| Create and run a business's account, dashboard, team and settings | Everything in clause 4.1 | APP 3: reasonably necessary for our function of supplying the Service. APP 6: this is the primary purpose it was collected for |
| Publish a business's booking page and take bookings on it | Clauses 4.1 and 4.2 | Primary purpose. Where the business typed it in, APP 3.6 also applies: collecting it from the client directly is not practicable for a record the business keeps |
| Work out the price of a job | Where the work is on a vehicle, the vehicle's make, model and size class; and the business's own services, add-ons, rules and discount codes | Primary purpose |
| Send emails about a booking, an invoice or a quote | Client name, email address, and the details of the job or document | Primary purpose. This is not direct marketing, see clause 9.2 |
| Run the message thread between a business and their client | Message content, and who read what and when | Primary purpose |
| Take deposits and payments, and record refunds | Name, email address, amount, and the payment provider's identifiers | Primary purpose |
| Show a business's clients how to pay it by bank transfer or PayID | The bank transfer details in clause 4.1 | Primary purpose. The business gives them to us so that its clients can pay it, and they are shown only on that business's own tracking pages and invoices, while something is owing |
| Produce a business's invoices, adjustment notes, quotes and reports | Client and billing details, booking records, payment records | Primary purpose |
| Keep a business's expense, receipt and logbook records | Clause 4.3 | Primary purpose |
| Charge a business's subscription and manage their plan | Name, email address, payment provider customer identifier, subscription status | Primary purpose |
| Keep accounts secure, prevent abuse, and investigate misuse | Email address, IP address, browser user agent, sign-in events, audit log, rate limiting counters | APP 3: reasonably necessary. APP 6.2(a): a use you would reasonably expect and that is directly related to supplying the Service safely |
| Understand which parts of Glo are used, so we can improve the product and decide what to keep | The usage records in clause 4.1: screen, action, role, plan and time, for signed-in business accounts only | APP 3: reasonably necessary for our function of supplying and developing the Service. APP 6.2(a): a use you would reasonably expect of the software company whose product you subscribe to. It is never used for direct marketing, never combined with a business's client records, and never applied to a client of a business. See clauses 7.2 and 7.4 |
| Answer a support request or a complaint | Whatever is in the request, plus enough of the account to find the problem | APP 6.2(a): a use you would reasonably expect |
| Meet our own record keeping obligations, and defend a claim | Account, billing and transaction records | APP 6.2(b): required or authorised by an Australian law, in particular the tax record keeping rules. See section 12 |
| Deal with a serious threat to someone's life, health or safety, or with suspected unlawful activity | Whatever is relevant | APP 6.2(c): the permitted general situations in section 16A of the Privacy Act. We would make a written note of it |
7.2 We do not use one business's information for another business
Every record in Glo belongs to exactly one business. There are no shared client lists, no cross-business lookups, and no "we noticed this person books elsewhere" features. Two businesses using Glo cannot see each other's clients, and we do not join their data together. Section 11 covers how we keep them apart.
The one deliberate exception holds no personal information: a shared vehicle catalogue of curated make and model entries that maps a vehicle to a size class. A Toyota Corolla is a small car for everybody, and letting one business edit that would change another business's pricing. A business that disagrees creates its own rule, which wins for them and only for them.
7.3 The only additional things we do with client information
Because a business's client information was collected for the business's purposes, our own use of it is narrow. Beyond supplying the Service, we use it only:
- to keep the Service secure and to investigate abuse;
- to answer a support request, including one from the client;
- where we are required or authorised to by an Australian law, or a court or tribunal order;
- where it is reasonably necessary to deal with a serious threat to somebody's life, health or safety, or with suspected unlawful activity or serious misconduct;
- to establish, exercise or defend a legal claim.
7.4 What we never do with it
- We do not sell or rent personal information. Ever, to anybody.
- We do not use a business's client list to market anything, ours or anybody else's. See clause 9.4.
- We do not use client information to train machine learning models, ours or a third party's.
- We do not build a separate product, benchmark or data set out of what businesses put into Glo.
- We do not share information between businesses, in any form, identified or otherwise.
- We do not track you across other websites, and one boundary belongs on that sentence rather than in a footnote under it. Nothing inside the Service follows anybody anywhere, and no page a business's client is sent to carries a tag of any kind. The advertising tags our public marketing pages may carry are the exception: they are Meta's and Google's rather than ours, and recognising the same browser on other sites carrying the same tags is what they are for. Clause 2.4 says which pages those are, and it is a short list.
- We do not measure anything a business's client does. Not on a booking page, not on a tracking page, not on a public invoice and not on a public quote. Clause 4.1 records that we measure how the signed-in dashboard is used by the businesses that subscribe to us; that measurement cannot reach a client, because it needs a signed-in account to record anything and a client never has one.
- We do not use the usage records in clause 4.1 to market to anybody, to build a profile of an individual, or to decide anything about a person.
7.5 Our own people, and looking at your data
We do not look at a business's data except where it is needed to run the Service, to answer a support request, or where we are required to by law.
Three things back that up rather than leaving it as a promise:
- Our own people's access is recorded, tagged with the person's email address, so every time one of us acts inside a business's account there is a permanent record of who it was.
- You can ask us for your own business's entries. Email hello@welcomeglo.com and we will send them to you.
- We do not sign in as you. If we need to see what you see, the supported way is for you to add us to your team through your own Team page, with your knowledge, and remove us afterwards.
8. Who we disclose personal information to
8.1 To the business
If you are a client, everything we hold about you is visible to the business you dealt with. That is the point of the software. Registration is the one field they can see that is never shown anywhere public.
We do not show your details to any other business using Glo.
8.2 To our service providers
We use a small number of providers to run the Service. They are set out in full below. We give each one only what it needs for its job.
Each of them is engaged on its own published data processing terms, which we have read and accepted. Before a provider handles anything, we satisfy ourselves that those terms require it to:
- handle personal information consistently with the Australian Privacy Principles;
- use it only to provide the service we engaged it for, and not for its own purposes;
- keep it secure, with measures appropriate to what it holds;
- pass equivalent obligations to anybody it uses in turn; and
- tell us about a security incident that affects it, so that we can assess it and tell you.
That is the same list, in the same words, as clause 3.2 of /legal/subprocessors
and clause 8.2 of our Data Processing Addendum. One standard, stated once, so
there is nothing to reconcile.
We chose these providers partly on the strength of those terms, and we do not add a provider whose terms do not carry them. Clause 8.5 keeps us answerable for what they do with your information either way.
Two rows in the list below do not sit on that footing, and you are better
served by our saying so than by a list with a quiet exception inside it. The
Meta and Google advertising rows are not providers
we engaged to run the Service. They are in the list because personal information
reaches them and you are entitled to know that, and each of them
holds what it receives for its own purposes on its own published terms, which
is what an advertising company is. So what limits them is not the second requirement above
but where they are allowed to run: our public marketing pages and nowhere else,
never a page a business's client is sent to, and nothing from inside Glo sent to
either of them. Clause 2.4 is that boundary and clause 4.4 is what they receive.
The five requirements apply, unchanged, to every provider that handles
anything a business or a client put into Glo. That carve-out is written the same
way, and means the same thing, in clause 3.2 of /legal/subprocessors, which also
sets out what we require of the two advertising providers instead, and in clause
8.2 of our Data Processing Addendum.
8.3 The full list of providers, and where each one processes
The current list is also published at /legal/subprocessors. That page carries
the detail, this policy carries the summary, and we update both in the same piece
of work. If you ever find them disagreeing, tell us at hello@welcomeglo.com and
we will fix it, and until we do, this Privacy Policy governs how we handle
personal information. We update both before a new provider starts handling
personal information, not afterwards.
We also email businesses at least 30 days before a new provider starts handling
personal information, and if you would rather leave than accept it, you can
cancel with no exit fee and no notice period, and we refund the unused part of
anything you have already paid. There is one narrow exception, for a provider that
has to be replaced urgently to keep the Service secure or running, and even then
we tell you within 7 days and the exit right runs from the day we tell you. The
exception and the exit right are set out in full in section 8 of
/legal/subprocessors and in clause 8.6 of our Data Processing Addendum.
| Provider | What we use it for | Where it processes |
|---|---|---|
| Vercel | Hosting our website and the application | Sydney. Vercel is a United States company |
| Supabase | Our database. This is where almost everything in section 4 is stored | Sydney. Supabase is a United States company |
| Upstash | The counters behind our rate limits. Holds an identifier and a count, briefly. The identifier is usually an IP address | Sydney. Upstash is a United States company |
| Stripe | Payments, in both directions: a client paying a business, and a business paying us. Receives the name, email address and amount, and takes the card details directly from you on its own page | Overseas, including the United States. Its Australian entity is Stripe Payments Australia Pty Ltd |
| Twilio | Sending the four text messages Glo sends a business's client about a booking, when it is confirmed, cancelled or changed, or a quote for it is sent. Receives the client's mobile number and the words of the message, which are the business's name, what happened and, for a confirmation or a cancellation, the booking's day and time | Overseas, including the United States |
| Resend | Sending our emails. Receives the recipient's email address and the contents of the message | Overseas, including the United States |
| Hostinger | Hosting our mailbox at hello@welcomeglo.com. Receives anything you send us and our replies to you | Overseas. Hostinger International Ltd is based in Lithuania |
| Address suggestions as you type in the address box on a booking form. Autocomplete only: no maps, no geocoding, no routing and no location tracking. The request goes from your own browser straight to Google and never through our servers, so what Google receives is the characters you type into that box, a short-lived session token that groups your keystrokes into one lookup, the address you pick, and the ordinary technical details of a web request including your IP address. No name, no phone number, no booking and no account goes with it | Overseas, including the United States | |
| Meta (advertising) | Advertising tags on our public marketing pages, and nowhere else in Glo, so that we can tell whether an advertisement we paid for brought somebody here. Where we use them, Meta receives what clause 4.4 lists: that a browser opened one of those pages, which page it was, the ordinary technical details of that request including its IP address, and the identifier Meta's own cookie sets. Nothing from inside Glo, and nothing about a business's client, who is never sent to a page it runs on | Overseas, including the United States |
| Google (advertising) | The same job on the same pages, and a separate arrangement from address autocomplete in the row above. Where we use them, Google receives the same things: which of our marketing pages was opened, that request's technical details including its IP address, and the identifiers Google's own cookies set. Nothing from inside Glo, and nothing about a business's client | Overseas, including the United States |
That is the whole list. No other provider handles personal information for us.
The Twilio row is new in this version. Twilio has been our text message
provider since 10 September 2026, and it has been named on /legal/subprocessors
since that day. This list should have named it from then. If you would rather
leave than accept it, the exit right and the pro rata refund described above are
yours, and they run from the day we email you about this version.
8.4 Overseas disclosure, and what it means for you
Yes, some of your personal information is disclosed to recipients outside Australia. We are required to tell you that, and to tell you where they are likely to be.
- The countries our own recipients are likely to be located in: the United States and Lithuania. Most of the providers listed above are United States companies, and Stripe, Twilio, Resend and Google process overseas. Meta does as well, for the advertising tags our public marketing pages may carry. Stripe's Australian entity is Stripe Payments Australia Pty Ltd. Hostinger International Ltd, which hosts our mailbox, is based in Lithuania.
- Vercel, Supabase and Upstash store our data in Sydney, and our server functions run in Sydney. But all three are United States companies, and their own personnel may be able to access systems from outside Australia. So the data is stored in Australia, rather than confined to Australia.
- Each of those providers uses providers of its own, and some of those are in
further countries. We keep
/legal/subprocessorscurrent. If where your information is processed matters to a decision you are making, email hello@welcomeglo.com and we will tell you what we know.
What each provider is bound to. Each provider's published data processing terms bind it to handle personal information consistently with the Australian Privacy Principles, to use it only for the service we engaged it for, to keep it secure, to bind anybody it uses in turn to equivalent obligations, and to tell us about a security incident. That is the same five-item list as clause 8.2, which explains how those terms come to apply. The two advertising rows are the exception clause 8.2 names, because a company that sells advertising uses what it receives for its own purposes and we are not going to describe it otherwise. What limits them is which pages they may run on, not that list.
8.5 The accountability rule, and why it protects you
Australian privacy law does not let a business hand your information overseas and then point at the recipient when something goes wrong.
Section 16C of the Privacy Act treats an overseas recipient's mishandling as the Australian business's own breach, where the information would have been handled in a way that breached the Australian Privacy Principles had the Australian business done it itself, and taking reasonable steps in the contract does not get that business out of it. We hold ourselves to that rule. We carry it.
That rule is one of the strongest protections you have, and it is a large part of why our provider list is short, why we do not add a provider casually, and why we keep as much as we can in Sydney.
8.6 Legal and safety disclosures
We may disclose personal information where:
- an Australian law, or a court or tribunal order, requires or authorises it;
- we reasonably believe it is necessary to lessen or prevent a serious threat to somebody's life, health or safety;
- we reasonably believe it is necessary to take appropriate action about suspected unlawful activity or serious misconduct relating to the Service;
- it is reasonably necessary for an enforcement body's enforcement activities, in which case we make a written note of the disclosure, which is the standard the Privacy Act sets and the one we follow;
- it is reasonably necessary to establish, exercise or defend a legal claim, or to get legal advice.
We do not hand over information because somebody asked nicely. If we receive a request from a law enforcement agency or a regulator, we check that it is valid and that it covers what is being asked for, and we give only what it covers. Where we are permitted to tell the affected person or the business, we will.
8.7 If the business changes hands
If Glo is ever sold, or its assets transferred, personal information would form part of what transfers, because it is inseparable from the Service. If that happens:
- we will tell affected account holders before it takes effect;
- the buyer would be bound by this policy for information collected under it, until they publish their own and give notice of the change;
- it does not become a licence to use the information for a new purpose. A change of purpose needs its own notice and, where the law requires it, consent.
9. Direct marketing
9.1 The two laws in play
Direct marketing in Australia is governed by APP 7 of the Privacy Act, which governs whether we may use your information for marketing at all, and by the Spam Act 2003 (Cth), which governs the message itself: consent, identifying the sender, and a working unsubscribe. The Spam Act applies to us regardless of our size. We have to satisfy both, and we do not treat either as optional.
9.2 What the Service emails you, and which of it offers you something
The Service sends emails because something happened to a booking, an invoice or a quote. Today those are:
booking received; booking accepted; booking declined, with the business's own reason; price changed; time changed; job completed; payment received; refund issued; cancellation; a note that a reply is waiting in a message thread; and one message offering another time after an unfinished checkout. Plus staff invitations, password reset emails, and the returning-client confirmation link.
Two of those carry a deliberate limit: the "a reply is waiting" email is sent once per conversation and never again, and the email itself says so, and the "you did not finish" email is sent once per booking, ever.
All but two of these carry no promotion. A message about your own booking is not an advertisement, and the moment a booking confirmation carried one it would become a commercial electronic message under the Spam Act and the whole set would change character.
The two exceptions are the email sent when a business turns a booking down and the one sent when a booking was never finished. Both invite you to pick another time and link to the business's price list, which makes them commercial electronic messages. Both say as much in the email itself, and both carry a link that stops emails of that kind from that business: one press, from the address the message went to, with no sign-in, no account, no reason asked for and nothing to pay. Your email app's own unsubscribe button works on them as well, and we act on either straight away.
There is no unsubscribe on the rest, because they are the Service doing the thing you asked it to do and none of them is marketing. If you no longer want them, cancel the booking, or ask the business to remove you as a client. Stopping the two that do offer you something does not stop the others, and it is not meant to: you would otherwise lose the email that tells you before your card is charged. Clause 9.6 of the client terms says what we commit to on all of this.
9.3 Marketing to the businesses that use Glo
If you hold a Glo account or sign up for updates from us:
- We only send you marketing with your consent. There is no pre-ticked marketing box on the sign-up form, and there will not be one. Creating an account does not sign you up to anything but the Service.
- Every marketing message identifies us, with our name and a way to contact us that will still work at least 30 days later.
- Every marketing message carries a working unsubscribe that does not require you to sign in, create an account, or give us any information you have not already given us.
- We action an unsubscribe within five business days. "Business days" is the Spam Act's own term for its unsubscribe standard, so we have kept the statutory wording here rather than the "business days" used everywhere else in our documents. In practice we are faster.
- You can also just email hello@welcomeglo.com and ask us to stop.
- Unsubscribing from marketing does not stop transactional email about your own account, your subscription or your bookings. Those are not marketing and you need them.
You can also ask us, at any time, not to use your personal information for direct marketing at all, and to tell you where we got your details. We will action that within 30 days and tell you the source free of charge, unless doing so is impracticable or unreasonable, in which case we will explain why.
9.4 We do not market to a business's clients on our own account
If you are a client of a business that uses Glo, we will never send you a marketing message of our own. Not about Glo, not about another business, not about anybody. We do not sell or rent your details, and they are never used to build an audience.
We are stating that as a commitment, not merely as a description. Your details came to us from the business for the business's purposes, and using them for ours would be a use of your information you never expected and never agreed to.
Two of the emails the business sends you through us do invite you to book again with them, and they are the two named in 9.2: the one sent when the business cannot take your booking, and the one sent when a booking was never finished. Those are the business's messages, about the very job you asked them for, sent on their behalf. Both carry a link that stops emails of that kind from that business, from the address the message went to, without a sign-in and without a reason. Stopping them does not stop the emails about a booking you have made, a payment or a refund, and it is not meant to: you would otherwise lose the message that tells you before your card is charged.
9.5 The list of people who have said stop
There used to be a marketing opt-in flag on a client record. It was never switched on by anything, nothing ever read it, and it was removed. What exists in its place is the opposite of a flag and is worth describing plainly.
- When you stop the emails described in 9.4, we record that you did. The business, your email address, when you asked, and which route you used: the link in the message, your email app's own unsubscribe button, or a request you sent us by hand.
- It is a stop, not a preference, and nothing lifts it. It is never edited and never deleted, including if the business deletes your client record. A record that could be undone by an import or by somebody tidying up is not a record of your decision.
- It is per business. Telling one business to stop does not tell another one anything, in either direction. That decision is yours to make separately because the relationships are separate.
- We keep it for as long as the business uses Glo. Keeping it is the only way to honour it; deleting it would quietly make you contactable again.
If a business markets to its own customers by its own means, outside Glo, that business is the one that authorised the message, and the consent, the sender identification and the working unsubscribe are theirs to get right. That does not remove anything the Spam Act puts on us. The Act catches a person who sends a message and a person who causes one to be sent, and where we send, or cause to be sent, it applies to us too, in parallel and not instead.
9.6 Text messages
Glo sends four text messages on a business's behalf, when a booking is confirmed, cancelled or changed, and when a business sends a client the quote they asked for. See our SMS Terms.
10. Cookies
10.1 There are four, and every one is strictly necessary
There are two cookies that matter to you, plus two sign-in housekeeping cookies, all four listed below. A cookie policy that undercounts cookies is not a disclosure, so here they all are.
| Cookie | What it does | Details |
|---|---|---|
__Secure-authjs.session-token, the sign-in session cookie | Keeps an owner, admin or staff member signed in to the dashboard | Encrypted, and httpOnly, so scripts running in your browser cannot read it. Up to 30 days, counted from the last time you used Glo, and deleted immediately when you sign out. Set only on the business side, only after you sign in |
glo_booking_draft, the booking draft cookie | Holds what you have typed into a booking form so far, so you do not lose it moving between steps | httpOnly. Path-scoped to one business's booking page, so it is not sent anywhere else. Expires after two hours, and is deleted the moment the booking is made. Signed, so it cannot be tampered with. Holds the name, mobile number, email address, address and notes you typed, and, where the address came from the suggestion list, Google's identifier for it. It also holds an identifier for your client record with that business, written only after you have proved your email address by opening a link we sent you. That identifier is what lets the page offer you the vehicle you booked last time and the addresses you have used before, instead of a blank form |
__Secure-authjs.callback-url, sign-in housekeeping | Records which page to send you back to after you sign in | httpOnly. Lasts until you close your browser. Holds no personal information: just the address of a page on our own site. Businesses that use Glo, and their staff, only |
__Host-authjs.csrf-token, sign-in housekeeping | Protects a sign-in from being triggered by another website | httpOnly. Lasts until you close your browser. A random string, and it tracks nothing. Set during sign-in, in some circumstances rather than every time |
All four are first party, which means they belong to welcomeglo.com and no
other company can read them, and all four are sent only over an encrypted
connection on our live site. The technical names, lifetimes and contents are set
out in full at /legal/cookies.
The booking draft cookie exists to protect you. Those details have to live somewhere between steps, and the alternative is putting them in the web address, where they would end up in your browser history, in a bookmark you shared, and in the referrer header sent to the next site you visit. A short-lived, signed, script-inaccessible cookie scoped to one page is the safer place.
10.2 What we do not use
In the product, and that means every page a business's client is sent to as well as the signed-in dashboard: no analytics cookies, no advertising pixels, no session recorders, no third-party tracking cookies, no cross-site tracking and no advertising network. Not "we do not currently": there is none of it, and the four in clause 10.1 are the whole list of what is set.
On our public marketing pages there may be more than that. None of the four cookies in
clause 10.1 is set there, which used to be the whole answer and is no longer,
because those pages may carry advertising tags from Meta and Google, and such a
tag sets cookies of its own.
Those cookies are first party by domain, in the sense that our site is what
sets them, but they are not ours and not necessary to anything: they
exist so that
Meta and Google can tell an ad we paid for brought somebody here, and so that the
same browser can be recognised on other sites carrying the same tags. Our cookie
policy at /legal/cookies says more about them, including the part we cannot
promise: the exact set each tag drops is Meta's decision and Google's rather than
ours. Clause 4.4 lists what they send.
Two things in this section have been narrowed, and both are recorded here rather than quietly edited.
The first was on 6 September 2026. It read "No analytics", flatly. We now measure which parts of the signed-in dashboard get used, so a flat denial would be false. What did not change is the cookie position, which is what this section is about: that measurement sets no cookie, stores nothing on your device, and loads no third-party script, so clause 10.1 is still the whole list and it is still four. Clause 4.1 says what is recorded, clause 7.1 says why, and Cookie Policy section 5.1 is the long version.
The second was on 7 September 2026, and it is the larger one. We decided to buy advertising, and our marketing pages may carry the tags that come with it. Until version 1.3 of this policy, effective 7 September 2026, this section said "No advertising pixels", flatly, and it said that none of our four cookies is set on our marketing pages. The first of those does not survive the change and has gone. The second is still true, but it was inviting you to read it as nothing at all being set there, and other cookies now are, so it no longer stands on its own. What did not change is the count in clause 10.1. Those are the cookies the product sets, they are still four, and an advertising cookie on our marketing site does not join that list, because it is not ours and it is not necessary. The only cookie a business's client will ever meet is the booking draft cookie. Nothing was quietly added to a page your clients open, and clause 2.4 explains why nothing can be.
10.3 Why there is no cookie banner
Because Australia has no equivalent of the EU rule that produces those banners.
The European ePrivacy rules require consent before most cookies are set. Australia has no such rule. Cookies that carry personal information are governed by the Privacy Act, and what the Privacy Act requires is that we tell you, not that we make you click something. This section is us telling you.
That answer used to have a second leg, and since 7 September 2026 it does not, so it is worth saying which one is holding it up. We used to add that even under the European rules strictly necessary cookies need no consent, and that all four of ours are strictly necessary. All four still are: one keeps you signed in, one keeps the booking form from losing your details, and two are sign-in housekeeping. But an advertising cookie set on our marketing pages is not strictly necessary, and under the European rules it would need consent. Those rules do not reach us, for the reasons in section 17. So the honest version is that a banner is not required of us here, not that there is nothing on our site a banner would have been for.
Where that leaves you, in practice. Inside the product there is nothing to consent to: all four cookies are necessary, and you cannot refuse them without breaking the page you are on. A banner there would be a click, not a protection. On our marketing pages there is something, and clause 10.5 is what to do about it: your browser can block or delete those cookies, and blocking them costs you nothing, because nothing on those pages needs them to work. We would rather set all of that out in clauses 2.4, 4.4 and 10.2, where you can read it and hold us to it, than compress it into a box you dismiss to get on with your day.
10.4 What would change that answer
We would add a consent mechanism, and update this policy first, if we ever:
- added analytics, an advertising pixel, or a session recorder;
- added any third-party cookie or cross-site tracking;
- began offering the Service to people in the European Union, the European Economic Area or the United Kingdom, or began monitoring the behaviour of people there.
The first two of those have been triggered, on our public marketing pages, and this clause is not being quietly reworded around it. Those pages may carry advertising tags from Meta and Google, and version 1.3 of this policy, effective 7 September 2026, was the notice. Those tags set cookies that are neither ours nor necessary, and recognising the same browser on other sites is the whole point of them, so both of the first two bullets have fired.
This clause said we would add a consent mechanism if that happened, and we have not added one. We are not going to pretend the sentence said something else. What we relied on instead is in clause 10.3: Australia has no rule that makes a cookie consent a legal requirement, and what the Privacy Act does require is that we tell you. Clauses 2.4, 4.4 and 10.2 are us telling you, in more detail than a banner has ever given anybody. Whether that is good enough is a fair question to put to us, and hello@welcomeglo.com reaches a person who will answer it.
None of it reaches a page a business's client is sent to. That is the promise this section exists to protect, and it is the one that did not move.
The third has not happened. See section 17.
10.5 Controlling cookies yourself
Your browser can block or delete cookies. If you block ours, you will not be able to stay signed in to the dashboard, and a booking form will lose your details when you move between steps.
Blocking any advertising cookie our marketing pages set will cost you nothing. Nothing on those pages needs them in order to work, and no part of Glo behaves differently because you refused them. Your browser's own settings, and any tracking protection or content blocker you already run, are enough.
Our full cookie policy, including the technical names and lifetimes, is at
/legal/cookies.
11. How we keep personal information secure
We hold ourselves to the standard the Privacy Act sets: take reasonable steps to protect personal information from misuse, interference, and unauthorised access, modification or disclosure.
11.1 What we do
- We control who can reach personal information, and access is limited to the people who need it for the job in front of them. Our own access rule, and the record we keep of it, is in clause 7.5.
- Every record belongs to exactly one business, and one business's records are kept separate from another's. Two businesses using Glo cannot see each other's clients, and we do not join their data together.
- Connections to Glo are encrypted.
- We never store your password in a readable form. We cannot read it, which is why we can only reset it and never tell it to you. Glo requires a strong password and tells you what it needs when you set one.
- We take steps to stop repeated sign-in attempts.
- Disabling a staff member, forcing a sign-out or resetting a password ends that person's access, everywhere they were signed in.
- Inside the Finances module, a Staff-role user has no access at all, exports and PDFs included. A business employing two people does not want them reading the profit and loss, and that is enforced as a boundary rather than hidden in a menu.
- Our database and the systems that run Glo are hosted in Australia.
No system can be guaranteed completely secure, and we cannot promise that personal information will never be reached by somebody who should not have it. What we can commit to is the measures above, and the response in section 14 if it happens. If you believe your account or your information has been affected, email hello@welcomeglo.com and we will treat it as a priority.
11.2 What you can do
If you run a business that uses Glo: use a password you use nowhere else, remove staff who have left through the Team page, and treat the links we email you, such as tracking links, invoice links and quote links, as private, because anybody holding one can open the page it points to.
12. How long we keep personal information
12.1 The rule
We keep personal information for as long as we need it for the purposes in section 7, and for as long as an Australian law requires us to keep it. After that, we destroy it or de-identify it.
12.1a What we keep, and for how long
These are the periods we commit to. Clause 12.2 sets out what happens when an account ends. This table covers everything else, because a person whose details are sitting in an open account deserves an answer too.
| What | How long we keep it | Why |
|---|---|---|
| A business's account and billing records | On the schedule in clause 12.2 | Tax record keeping, and the limitation period in clause 12.3 |
| A client's record held by a business whose account is open | For as long as that business keeps it, then on the schedule in clause 12.2 running from the day they archive it | It is the business's own customer record and the business decides what to keep. See clause 2.3 |
| Invoices, adjustment notes, quotes, payments, expenses, receipt images and vehicle logbook entries | On the schedule in clause 12.2 | Tax record keeping. An issued document is never edited and never deleted. See clause 12.4 |
| Audit log entries, which include an IP address and a browser user agent string | 2 years from the action they record, then deleted, unless the entry is part of a live investigation or a legal claim, in which case until that is finished and we note why | Long enough to investigate an incident and to answer a question about who did what in an account. Short enough that we are not holding IP addresses for no reason |
| Support and complaint correspondence | 2 years from the last message, or until a complaint or claim is finished if that is longer | To answer a follow-up, and to be able to show what we did |
| Marketing contacts | Until you unsubscribe. We keep the fact that you unsubscribed for as long as we operate, because a suppression list is the only way to be sure we never message you again | APP 7 and the Spam Act. Deleting the record of your unsubscribe would be the fastest way to breach it |
| A note the business logged and then deleted | 30 days from the day they deleted it, then destroyed | A note typed one handed in a driveway is easy to delete by accident. Long enough to put one back for somebody who asks, short enough that a deleted note does not sit in the database indefinitely |
| The record that an email was sent to a client | 24 months from the send, then deleted | Long enough to answer "did they get the invoice" and to support a dispute about a job. It holds a subject line and an address, not the body of the message |
| The record that a text was sent to a client | 24 months from the send, then deleted | Long enough to answer whether a client was told about their booking and to support a dispute about a job. It holds the words of the text, which say only the business's name, what happened and sometimes the booking's day and time |
| An enquiry from somebody who is not a client | For as long as the business keeps it, then on the schedule in clause 12.2 | It is the business's own record of somebody who contacted them, and the business decides what to keep. If it becomes a client record, that record's row above applies |
| Dashboard usage records | 13 months from the day of the action, then deleted | Thirteen rather than twelve so a month can be compared with the same month a year earlier, which is the one comparison a seasonal trade needs. Longer than that would be holding records about identifiable staff for a question nobody is asking |
| Website visitor request information and rate limiting counters | Minutes to hours | It is a counter, not a record |
| What an advertising tag on our public marketing pages collects | We do not hold it, so we cannot set a period for it. It goes from your browser to Meta and to Google, and they keep it on their terms rather than ours | Saying "we delete it after X" would be a promise about somebody else's systems. What is ours to decide is which pages those tags may run on, and clause 2.4 is that answer. Clause 4.4 lists what they receive |
| The booking draft cookie | 2 hours, in your own browser | See clause 10.1 |
12.2 What happens to a business's records when the account ends
| When | What happens |
|---|---|
| At the moment access is about to close | We generate a complete export of the business's financial records and email it to the account owner's email address, before access closes. That export covers invoices, invoice lines, payments, expenses, adjustment notes, the vehicle logbook and a combined transaction list. See clause 12.2a |
| From then until 2 years | Records are kept. Whether the business can browse them inside the app is governed by the billing rules in our terms, but the free records download at /dashboard/finances/records keeps working either way, because a business has to be able to reach the records the ATO requires it to keep. See clause 18.4 |
| At 2 years | Access through the app permanently ends. The records move to cold retention |
| From 2 years on | Held in the background only. Not reachable through the app at all. Reaching them requires an authenticated internal process that leaves an audit entry recording who looked and when |
| At 7 years, counted per record | Deleted, except for records covered by a longer retention obligation. See "which clock" and the exception immediately below |
Which clock, because there are two and they run differently. The two access windows above run from the moment access closes, because access is a property of an account rather than of a record. The seven year destruction date runs from when each record was made, or the transaction it records was completed, whichever is later. That is the Australian Taxation Office's own measure, it is the only one a per-record retention flag can implement, and it is the one that governs. For a business that used Glo for five years the two measures would give the same invoice destruction dates up to five years apart, so it is worth being exact rather than tidy. Our Terms of Service clause 22.2 and clause 9.2 of our Data Processing Addendum express the same schedule and carry the same exception.
One exception, and it exists to protect you. Some records have to be kept longer than seven years. Records about a business asset are the clearest case: they have to be kept for as long as you hold the asset plus five years after you dispose of it. For example, buy a work van in year one, sell it in year eight, and the purchase records are needed until year thirteen. A flat seven year sweep would destroy them and leave you unable to answer the ATO about a deduction you correctly claimed.
So we do not delete a record while a longer obligation is running on it. If you know a record falls into that class, tell us at hello@welcomeglo.com and we will mark it as held, and we will confirm that we have. We would rather hold too long on a stated basis than delete something you needed.
12.2a The export, however the account ends
However a Glo account comes to an end, that export is a commitment and not a
courtesy. You can also ask for it at any time at hello@welcomeglo.com, or take
it yourself from /dashboard/finances/records, which is never gated on billing.
We do not delete a business's records the moment they stop paying us, and that is deliberate. You may still need them: the ATO requires you to keep your business records for five years, and that obligation does not stop because you stopped using Glo. Deleting them quickly would be convenient for us and harmful to you.
We never delete records as a punishment. Not for a missed payment, not for a locked account, not for changing plan.
12.3 Why seven years
- The Australian Taxation Office requires business records to be kept for five years, from when the record was prepared or the transaction completed, whichever is later. That is the hard obligation, and it sits on the business, not on us.
- Six years is the longest limitation period that could apply to us, being the period for bringing a contract claim in most Australian states. A claim filed on the last day of year six needs records that still exist while it is heard.
- Seven years is six plus a deliberate one-year margin. It is our choice rather than a statutory minimum.
One thing this section is not. Everything above is a general statement about
Australian record keeping rules, set out so you can see why we keep what we keep.
It is not tax advice, and it is not advice about your business. Glo is
software. We are not a tax agent or a BAS agent, we do not work out your
obligations, and our support team cannot tell you how the tax law applies to you.
For advice you can rely on, speak to a registered tax agent or BAS agent, or to
your accountant. Clause 13 of our terms at /legal/terms sets that line out in
full.
Two things people cite for long retention that we specifically do not rely on:
- The Corporations Act seven-year rule does not apply to us. It binds companies. Glo is operated by a sole trader, so that section is not available as a justification, and we are not using it as one.
- Anti-money laundering law does not apply to us and is not a basis for anything here. Those obligations attach to businesses that hold, transfer or exchange money. The money for the work a business does for its own customer goes from the client, through the payment provider, into the business's own account. It never passes through us. Our payment provider carries those obligations, not us.
We are spelling out what does not apply because keeping information longer than you need it, on a basis that does not apply, is itself a privacy problem. It makes any future security incident worse for no benefit to anybody.
12.4 The tension between deleting and keeping, and how it resolves
This is the part that catches people out, so we will be direct.
If you ask us to delete your information, we will delete what we are allowed to delete, and we will keep what the law requires us to keep. We will tell you which is which.
Australian tax law requires business records to be kept for five years. A booking that was paid for is part of a business's records. So is an invoice, an adjustment note, a receipt and a payment. A request to delete does not override a legal obligation to retain, and any business that told you otherwise would either be misleading you or breaking a different law.
What that means in practice:
- Financial records are never hard-deleted. An issued invoice or adjustment note is never edited and never deleted. A correction is made by issuing an adjustment note or by voiding the document, and in both cases the original stays visible. That is what the record keeping rules require, and it also protects both sides of a dispute about what was actually agreed.
- Client and vehicle records are archived rather than erased when a business removes them, because a business's entire job and takings history hangs off them and a hard delete would rewrite records the ATO requires them to keep. An archived record drops out of every list and picker.
- Where we cannot delete something, we will say so, say why, and say for how long. We will not quietly keep it and let you believe it is gone.
- Where we can delete something, we will, and we will confirm when it is done.
12.5 How to ask
Email hello@welcomeglo.com. A deletion request goes to a real person and is handled within the timeframe in clause 13.4. See section 13 for what we will do and how long we will take.
13. Getting a copy, and having it corrected
13.1 Your right to a copy
You can ask us for a copy of the personal information we hold about you. This applies whether you run a business that uses Glo, are a member of its team, or are a client of one. You do not need an account with us to ask.
13.2 Your right to have it corrected
You can ask us to correct personal information that is wrong, out of date, incomplete, irrelevant or misleading. We will take reasonable steps to fix it.
If we have already given the incorrect information to somebody else, and you ask us to, we will take reasonable steps to tell them about the correction too, unless that is impracticable or unlawful.
If we decide not to make a correction, we will tell you why in writing, and, if you ask, we will attach a statement to the record saying that you believe it is wrong, in a way that anybody using that record will see.
13.3 If you are a client of a business that uses Glo: the practical route
You can come straight to us and we will deal with your request. We will not turn you away and tell you to go to the business.
That said, going to the business first is usually faster and better for you, and the reason is this: the business knows who you are, can verify you on the spot, and can fix the record immediately in front of you. We do not know you and would have to verify your identity from scratch. On top of that, the record is theirs, and a note they wrote is a note only they can properly explain or change.
So:
- If you contact the business, they can do it themselves.
- If you contact us, we will pass the request on to the business where that is the sensible route, and tell you we have done it. We will still respond to you ourselves within the timeframe below, and we will deal with the request ourselves where passing it on is not appropriate or the business does not act.
- There is one thing we will only ever do with the business: correcting a record that changes their business's own financial documents. See clause 12.4.
13.4 How to make a request, and how long we take
Email hello@welcomeglo.com, or write to us at Unit B14, 161 Arthur Street, Homebush West NSW 2140. Tell us:
- what you want, a copy or a correction;
- enough to find you, such as the name, mobile number or email address used, and the business involved if you are a client;
- how you would like to receive it.
We will acknowledge your request within 5 business days and respond within 30 days. If a request is complicated and we need longer, we will tell you before the 30 days is up, tell you why, and give you a date.
Identity. We will ask for enough to be reasonably satisfied you are who you say you are, and no more than that. We will not demand a passport to confirm a phone number. We do this to protect you: handing your booking history to somebody who claimed to be you would be a far worse outcome than a short delay.
Charges. We do not charge you for making a request, and we do not charge for a correction, ever. If a request for access is unusually large and would take substantial work to put together, we may ask you to cover a reasonable cost of doing it. We will tell you the amount before we start, it will never be a charge for asking, and it will not be excessive.
Format. We will give it to you in the way you ask for, where that is reasonable and practicable. A business can also export their own financial records at any time from within the app, in CSV, and generate invoice and report PDFs, without asking us at all. That export covers invoices, invoice lines, payments, expenses, adjustment notes, the vehicle logbook and a combined transaction list. For anything outside that, including a full copy of client, vehicle, booking and message records, ask us and we will put it together.
13.5 When we may say no
We apply the same limits the Privacy Act sets on when access may be refused. Those are limited situations, for example where giving it would have an unreasonable impact on somebody else's privacy, where it would reveal information about a third party, where the request is frivolous or vexatious, where the information relates to a legal claim between us, or where giving it would be unlawful.
If we refuse, in whole or in part:
- we will tell you in writing, with our reasons, unless it would be unreasonable to give them;
- we will tell you how to complain about the refusal, including to the OAIC;
- where the reason is somebody else's privacy, we will consider whether giving you access through an agreed intermediary would work instead.
14. Data breaches
14.1 What we do
If personal information we hold is accessed or disclosed without authorisation, or is lost, we work through four stages:
- Contain. Stop it getting worse. Revoke sessions and keys, rotate credentials, disable the affected path, and preserve the logs and evidence before changing anything.
- Assess. Work out what happened, what information was involved, who could have obtained it, and whether it is likely to cause serious harm to anybody.
- Notify. See below.
- Review. Work out how it happened, fix it, and record what was done.
14.2 The 30 day clock
Where we suspect an eligible data breach may have occurred, we will complete our assessment within 30 days, which is the maximum the Notifiable Data Breaches scheme allows.
The clock starts when we first have reasonable grounds to suspect, not when we have finished working out what happened. 30 days is a maximum and not a target, and we will move faster where we can. We document when the suspicion arose, who assessed it, what they looked at, and what they concluded.
14.3 When and how we notify
If we conclude a breach is likely to result in serious harm to any affected person, we will notify the Office of the Australian Information Commissioner and the affected people as soon as practicable.
The notice will tell you:
- who we are and how to contact us;
- what happened, when, and how we found out;
- what kinds of information were involved;
- what you should do about it, specifically and practically, not generic advice.
Where we cannot practicably notify each person individually, we will publish the notice prominently on our website and take reasonable steps to publicise it.
14.4 If a business's clients are affected
Where a breach affects a business's clients, we will tell the business, and we will agree with them who notifies the clients, so that the people affected are told once and told properly, rather than twice or not at all.
How fast we tell the business. Within 24 hours of first having reasonable grounds to suspect a breach affecting that business's data, and within a further 24 hours of concluding that it is likely to be an eligible data breach. That is clause 7.2 of our Data Processing Addendum and it is a contract term, not an aspiration. Do not confuse it with the 30 days in clause 14.2, which is the statutory maximum for finishing the assessment, a different clock doing a different job.
Our Data Processing Addendum at /legal/data-processing, clause 7.4, sets
the notification allocation out in advance, situation by situation, including who
notifies in each one, so that it does not have to be negotiated during an
incident. That Addendum applies automatically to every Glo account, so it is
already yours. See clause 2.3.
Being breached is one problem. Being slow to assess it and slow to tell people is a second, separate problem, and it is entirely within our control. We treat it that way.
15. Complaints
15.1 Complain to us first
If you think we have mishandled your personal information, or breached the Australian Privacy Principles, email hello@welcomeglo.com with "Privacy complaint" in the subject line, or write to us at Unit B14, 161 Arthur Street, Homebush West NSW 2140. Tell us what happened, when, and what you would like us to do about it.
15.2 What we will do
- We will acknowledge your complaint within 5 business days.
- We will investigate and respond in writing within 30 days. If we need longer, we will tell you before the 30 days is up, explain why, and give you a date.
- Our response will tell you what we found, what we have done or will do, and what to do if you are not satisfied.
- We will not charge you for making a complaint.
15.3 If you are not satisfied
You can take it to the Office of the Australian Information Commissioner (OAIC). They are the independent regulator, they are free, and they generally expect you to complain to us first and give us 30 days to respond.
- Website: oaic.gov.au
- Phone: 1300 363 992
- Post: GPO Box 5218, Sydney NSW 2001
If your complaint is about a marketing message or a text message rather than about privacy generally, the regulator is the Australian Communications and Media Authority at acma.gov.au.
Nothing in this policy limits any right you have to complain to a regulator or to take a matter to a court or tribunal.
16. Children
The Service is not directed at children.
Glo is a business tool for businesses. We do not market it to children, we do not design it for children, and we do not knowingly collect personal information from a child. A person booking work with a business that uses Glo would ordinarily be an adult, and a Glo account holder is a business.
If you believe we hold personal information about a child that was collected in error, contact us at hello@welcomeglo.com and we will look into it and deal with it under section 12.
17. If you are outside Australia
17.1 Where the Service is offered
We offer the Service to businesses in Australia. Our prices are in Australian dollars, our timezone is Australia/Sydney, our tax and record keeping features are built around Australian rules, and we do not advertise or offer the Service to people in the European Union, the European Economic Area or the United Kingdom. We do buy advertising, and clauses 2.4 and 4.4 describe the tags that come with it. We buy it to reach businesses in Australia. The sentence above about Europe is doing more work than it used to, so it is worth stating on its own: we are not targeting Europe or the United Kingdom with any of it, and we are not looking for customers there.
We also do not monitor the behaviour of people anywhere in the sense that test means, and the test is narrower than it sounds. We build no profile of anybody out of the Service, and we measure nothing at all about a business's clients, who are the people in this product who never chose to deal with us. The one thing that follows a browser between sites is the advertising tags our public marketing pages may carry. They are Meta's and Google's rather than ours, they may run on those pages and nowhere else, and they never run on a page a business's client is sent to. Clause 17.2 is what we think that means.
The one thing we measure ourselves is which parts of the dashboard our own subscribing businesses use, described in clauses 4.1 and 7.1. It is product record keeping about our own customers, not behavioural monitoring: it does not follow anybody between sites, it is never used to decide anything about a person, and it applies only to somebody signed in to an account they took out with us. See clause 10.2.
17.2 What that means for the GDPR and the UK GDPR
The EU General Data Protection Regulation and the UK GDPR apply to a business outside their territory where it offers goods or services to people there, or monitors their behaviour. Merely being reachable from a browser in Europe is expressly not enough.
On that basis, neither applies to us today. If you happen to read our website from Europe or the United Kingdom, that does not by itself bring us inside those laws, and it does not change how we handle your information: we would handle it under this policy, to the Australian Privacy Principles.
One qualification we would rather write down than leave you to find, added 7 September 2026. The advertising tags in clause 2.4 may run on our public marketing pages, and a tag that can recognise a browser on other sites sits closer to the monitoring limb than anything we have run before. Our position is that neither law reaches us: we do not offer the Service in Europe or the United Kingdom, we buy our advertising to reach Australian businesses, and somebody there who happens to open our home page is not a person whose behaviour we set out to monitor. That is a position, not a certainty, and if it turns out to be wrong, clause 17.3 is what we already committed to doing about it. In the meantime, if you are in Europe or the United Kingdom and you would rather those tags never ran on your browser, clause 10.5 is how you stop them, and hello@welcomeglo.com reaches us if you want us to look at it. What we cannot honestly offer is to reach into Meta's or Google's records for you, because what those tags collect goes to them and not to us, and each publishes its own controls.
17.3 If that ever changes
We have written this policy so that it does not need rewriting if it does. If we begin offering the Service to people in the EU, the EEA or the UK, or if a customer subject to those laws uses Glo:
- Our Data Processing Addendum at
/legal/data-processingalready applies to you, as it does to every Glo account, and its Annex A, which sets out the additional terms those laws require, comes into effect. The Addendum covers the sub-processor, security, assistance, breach notification and return-or-delete obligations. - The role mapping in clause 2.3 applies: controller for a business's own account and billing data, processor for a business's clients' data.
- Australia does not have an EU adequacy decision, so a transfer into Glo from Europe would need the appropriate standard contractual clauses, and from the United Kingdom the relevant addendum.
- We would publish the additional information those laws require, including the details of any representative we have to appoint, and we would add a cookie consent mechanism per clause 10.4.
None of that applies today.
18. Automated processing and automated decisions
18.1 The headline
No decision that has a legal effect on you, or a similarly significant effect, is made about you by automated means without a person being involved or able to intervene.
We do not do automated credit scoring, automated eligibility decisions, automated profiling, or any decision about a person's rights or status made by a computer alone.
One thing worth naming precisely, because it looks like profiling and is not. The Service works out counts and dates from a client's own record, such as how many jobs they have had and when they last booked, and it can list the clients a business has not seen for a while. That is arithmetic over that business's own records, shown to that business. It produces no score, no ranking and no category, it is never compared against anybody else's customers, and nothing is decided by it: the business reads a list and decides for itself whether to pick up the phone. Nothing is sent to a client because of it. Every one of those is in the table below.
We are setting this out now, before the transparency rules in the Privacy Act on automated decision-making commence on 10 December 2026, because it is worth knowing and because we would rather write it while it is simple.
One distinction worth drawing, because it decides who answers for what. Those rules attach to the business that arranged for a computer program to make or help make a decision, not to the business that merely operates or hosts it. Where a business uses a Glo feature to decide something about their own customer, that business is the one who arranged for it and we are the ones running it. Where we decide something about a business's own account, that is ours. The table below covers both, because you should be able to see what the software does either way.
18.2 What automated processing actually happens
| What is automated | What it uses | How much of it is automatic |
|---|---|---|
| Working out a vehicle's size class, where the work is on a vehicle | Make and model, matched against a shared curated catalogue, and against the business's own rule if they have written one | See clause 18.3 |
| Grouping addresses on a client record | Google's place identifier where the address was picked from the suggestion list, otherwise a normalised version of the text | Automatic where the identifier matches. It never merges two addresses across that gap on its own: "12 Smith St" and "12 Smith Street, NSW 2204" stay separate entries until a person says they are the same, because a false merge sends a business to the wrong house |
| Recognising a returning client | Whether a mobile number and an email address both match the same client record of one business | Automatic, but it decides only whether an emailed link is worth sending. Nothing about the client is shown to anybody until that person opens the link from their own inbox |
| Rate limiting | An identifier such as an IP address, and a count of recent requests | Fully automatic and temporary. It slows or blocks requests for a short window. If it catches you unfairly, contact us |
| Account lock-out | Count of failed sign-in attempts | Fully automatic and temporary, and it protects your account |
| Subscription state | The status of a subscription with our payment provider | Fully automatic. See clause 18.4 |
| Deposit hold expiry | Whether a deposit was paid within the hold window | Fully automatic. A held slot is released after the window and the hold does not become a booking |
| Working out counts and dates from a client's own record | That client's own bookings, payments, messages and the contact the business logged by hand | Fully automatic, and it is arithmetic rather than a judgement: how many jobs, what has been settled, when they last booked, when they were last in contact. It produces no score, no ranking and no category, and nothing is decided by it. It exists so a long client list can be sorted and searched without adding up the whole history every time |
| Listing clients a business has not seen for a while | The date of that client's last job, against a number of days the business picks on the screen | Fully automatic, and it is a filter on a date rather than a prediction. It is shown only to the business, it says nothing about you, and nothing is sent to you because of it. The business decides what to do, if anything |
| An evening summary for the business | Counts of the above, plus quotes it has sent with no answer, jobs it has finished without invoicing, and checkouts nobody completed | Fully automatic and it goes only to the business, as a notice inside their own dashboard. Nothing is sent to a client, and no message about you is generated by it |
18.3 Vehicle size classification, explained properly
This is the one piece of automated processing that affects a price, so it gets its own clause. It applies where the work is on a vehicle.
- Where the vehicle is in the shared catalogue, the size class is applied automatically, and it determines which of the business's price bands the job falls into.
- The catalogue is not exhaustive, deliberately. Where a vehicle is not in it, the Service does not guess. The client picks a size themselves, and the vehicle is flagged for the business's staff to approve. The size is not treated as settled until a person confirms it, and confirming it re-prices the job and records a price change the client can see.
- A size a member of staff has confirmed is authoritative, and a later public booking can never quietly downgrade it back to a guess.
- A business can override the catalogue for itself with its own rule, which wins for them and only for them.
This is a decision about a vehicle, and it changes a price band. It is not a decision about a person, and it does not affect anybody's rights or status.
18.4 Subscription state, and why we say so
Whether a business's subscription is in good standing, in a warning state, or locked is worked out automatically from the subscription's status with our payment provider. It is the one automated determination in Glo that affects a customer's access to their own account, so we disclose it rather than leaving it implied.
Three things about it, and they are all in our customer terms at /legal/terms
as commitments, not just descriptions:
- A failed payment does not lock anything straight away. There is a warning state that exists precisely because a payment provider retries a failed card for days. Only a genuine lapse locks.
- A complete export of the business's financial records is generated and emailed to the account owner's email address at the moment of locking, before access closes. It covers invoices, invoice lines, payments, expenses, adjustment notes, the vehicle logbook and a combined transaction list. See clause 12.2a.
- A permanent, free download of a business's own financial records survives the lock, and is deliberately not gated on billing, because a business must be able to reach the records the ATO requires it to keep.
A lapse never affects the client side. Booking pages and tracking pages keep working.
18.5 Our payment provider's own checks
Our payment provider may apply its own automated checks to a payment and decline it. Those are its decisions and its processes, made under its own terms, not ours. If a payment is declined, we are told the outcome and nothing more.
19. Changes to this policy
We will change this policy when the Service changes, when the law changes, or when we can explain something better.
- The version number and effective date at the top always tell you which version you are reading, and they are what a recorded acceptance points at. An acceptance that matches no version proves nothing.
- For a change that materially affects how we handle personal information about the businesses that use Glo or their clients, we will email you at least 30 days before it takes effect, at the address on the account. We do not simply post a new version and treat that as having told you.
- We will tell you in plain English what changed and why, alongside the new version and its effective date. A difference nobody can read is not notice.
- If you run a business that uses Glo, you can cancel before the change takes
effect, with
no fee and no notice period, and if you cancel because of the change we refund
the unused part of anything you have already paid for. You should not be held
to a period you paid for under different terms. This matches clause 25 of our
terms at
/legal/terms. - A change that takes nothing away from you takes effect as soon as we publish it. Correcting an error, making something clearer, adding a feature or a protection, and anything the law requires. It still gets a new version number and effective date, and we still say what changed. Nobody should wait thirty days for a fix.
- The thirty days above is for a change that takes something away: less of the Service, a new or higher cost, a shorter period, a narrower right, more of your information collected or used in a way it was not before, or anything else that leaves you worse off than the version you agreed to.
- Where it is not obvious which kind a change is, we treat it as the second kind. That call is not ours to make in our own favour.
- A change never applies retrospectively to information we have already handled.
- We will always update the provider list in clause 8.3, and the page at
/legal/subprocessors, before a new provider starts handling personal information, not afterwards, and on the 30 day notice and exit terms set out in clause 8.3. - This version adds Twilio to the provider list in clauses 8.3 and 8.4. Twilio has been our text message provider since 10 September 2026, receiving a client's mobile number and the words of each text, and this list should have named it from that day. It also lists two things we have held since that day and should have listed then: the bank transfer and PayID details a business may give us so that its clients can pay it directly, in clause 4.1, with why we hold them in clause 7.1, and our record of each text we send, in clause 4.2, with how long we keep it in clause 12.1a. Clauses 1.4 and 6.1 now mention text messages too, and clauses 10.2 and 10.4 now name the version they refer to. The exit right and the pro rata refund in the fourth bullet above run from our email about this version.
- We keep previous versions. Ask us at hello@welcomeglo.com and we will send you the version that applied on any given date.
We will not use a change to this policy to give ourselves a use of information you never agreed to. Where a new purpose needs your consent, we will ask for it separately.
20. Contact us
For anything about privacy, including a request for a copy of your information, a correction, a deletion request, or a complaint:
- Email: hello@welcomeglo.com
- Post: Connor Wu trading as Glo, Unit B14, 161 Arthur Street, Homebush West NSW 2140
For anything else, including support:
- Email: hello@welcomeglo.com
We are Connor Wu trading as Glo, ABN 23 380 080 435. A real person reads both addresses and will reply.
Related documents:
| Document | Where |
|---|---|
| Terms of Service | /legal/terms |
| Refunds and Cancellations Policy | /legal/refunds |
| Acceptable Use Policy | /legal/acceptable-use |
| Data Processing Addendum | /legal/data-processing |
| Cookie Policy | /legal/cookies |
| Subprocessors, the current list | /legal/subprocessors |
| Collection notices, including the short form that belongs under the booking form | /legal/collection-notice |
| Client Terms of Use, for a business's own clients | /legal/client-terms |
Questions about this document?
Email hello@welcomeglo.com.