Skip to content
PitlaneHQ
Log in
Privacy

Privacy policy.

Last updated: 5 November 2026

This Privacy Policy explains how Surau Engineering Pty Ltd (ABN 51 696 483 468), trading as “Pitlane HQ” (“PitlaneHQ”, “we”, “us”, or “our”), handles personal information in connection with our workshop management software and related services (the “Service”).

We are bound by the Australian Privacy Principles (“APPs”) in the Privacy Act 1988(Cth) (“Privacy Act”), by the Spam Act 2003 (Cth) for electronic marketing, and by applicable State and Territory legislation, and we are committed to meeting those obligations. This policy describes how we go about it. Where we identify a shortfall we will say so and fix it rather than paper over it — see the cookie section below for a current example. “Personal information” has the meaning given in the Privacy Act.

1. Our two roles: when we control data, and when we only process it

PitlaneHQ handles personal information in two distinct capacities. Understanding which applies determines who is accountable under the Privacy Act and how you exercise your rights.

  • As the responsible entity (we decide how data is handled). For information about the workshop business and its users — the account holder's name, login, billing details, and how the workshop itself uses the Service — PitlaneHQ is the APP entity. This policy governs that information directly.
  • As a service provider acting on a workshop's instructions (the workshop decides). For the operational data a workshop stores in the Service about its own customers, vehicles, employees, jobs, invoices, and communications, the workshop is the APP entity and is responsible for that data under the Privacy Act. PitlaneHQ processes it only to provide the Service, on the workshop's behalf, under the terms of our Data Processing Addendum. If you are an end customer or employee of a workshop, your privacy enquiries should generally be directed to that workshop; we will assist them in responding.

2. Information We Collect

2.1 Workshop account information (we are the responsible entity)

When a workshop registers for PitlaneHQ, we collect information to create and manage the account:

  • Name and contact details of account users (email address, phone number)
  • Business name, ABN, and business address
  • Billing information (payment method and transaction history are processed and stored by Stripe, and your subscription invoices, credit notes and payments are also recorded in PitlaneHQ's own accounts in Xero; we do not store full card numbers)
  • Login credentials (passwords are securely hashed and never stored in plain text)
  • If you choose to sign in with Google: the identifier Google assigns to your Google Account, your email address and whether Google has verified it, and your name. We use the email address to match you to your PitlaneHQ account the first time (or, if you do not have one yet, to pre-fill our sign-up form), and keep the identifier so we can recognise you after that. Google's basic profile also carries a link to your profile photo, which we do not keep. We do not receive or store your Google password.
  • If Microsoft sign-in is switched on and you choose it, we receive your Microsoft directory identifier, tenant identifier, email address, name and, for a work or school account, whether its email domain is verified by the tenant. If Microsoft sign-in is switched on and you choose it, we keep the directory and tenant identifiers to recognise you on later sign-ins. If Microsoft sign-in is switched on and you choose it, on a first sign-in we use a trusted email to match your existing account or pre-fill sign-up; an untrusted email is never matched, so you first sign in with your password and link under Settings > Security. If Microsoft sign-in is switched on and you choose it, we do not keep a profile photo or receive or store your Microsoft password.

2.2 Workshop operational data (the workshop is the responsible entity)

In the course of running their business, a workshop may store the following in the Service. PitlaneHQ processes this data on the workshop's instructions and does not use it for our own purposes:

  • Customer names, contact details, and vehicle information (including registration plate and VIN)
  • Job records, inspections, quotes, invoices, payments, and related financial information
  • Employee and technician records, including timesheets and payroll information where the workshop uses our HR & Payroll module (see section 8)
  • Stock, supplier, and purchase order information
  • Uploaded files and documents (photos, PDFs, attachments)
  • Supplier bills a workshop forwards to its PitlaneHQ bills address — the email and its PDF attachment; only PDF attachments are kept — where the workshop turns that feature on (see section 9 for how long they are kept)
  • SMS, email, webchat, and in-app communication history
  • Call recordings, transcripts and voicemail, where the workshop uses Pitlane Phones and has enabled recording or transcription. This covers the call audio (if audio storage is on), the automated speech-to-text transcript, any AI-generated summary of it, and call metadata such as the numbers involved and the time and duration. These features are off by default. Because recording is regulated by State and Territory law and the rules differ across Australia, the obligation to record lawfully — including giving whatever notice or consent is required, and telling staff — rests with the workshop. See our Call Recording & Transcription Notice.
  • AI receptionist calls, where the workshop turns the AI receptionist on for a site: the recording, transcript and summary of each call it answers, the numbers involved, the time and duration, and any message or booking request taken. Every call the AI answers is recorded and transcribed, and callers are told so at the start of the call (see section 4.1). Where neither a person nor the AI can take a call, or our call handling fails at a workshop that has acknowledged the AI receptionist's notice, the caller can leave a voicemail, which is recorded too.
  • Vehicle records returned by registration and VIN lookups against national vehicle registers, where a workshop uses that feature
  • Marketplace listing content and customer reviews, where a workshop lists publicly
  • Planned, not yet available: job videos a workshop records and shares with its customer, and, where a workshop turns on live tracking for a mobile job, the technician's location while travelling to the customer (see section 9 for how long each is kept)

2.3 End-customer information (collected directly via customer-facing features)

Where a workshop enables customer-facing features — the customer portal, online booking (including the booking and enquiry widgets a workshop embeds on its own website), the “text us” SMS bubble, the website chat widget, or the Pitlane Marketplace — end customers may provide personal information directly to the Service (name, contact details, vehicle, booking, enquiry and quote details, and the messages they send). Where a workshop installs Pitlane Connect on its own website (the booking or enquiry widget or the “text us” bubble), we also record the pages a visitor views on that website, using the first-party cookie described in section 6 of our Cookie & Tracking Notice, and link them to an enquiry or booking the visitor later makes through the widget. The widgets do not record page views for visitors in regions where we do not rely on notice alone. If the workshop also turns on the analytics beacon in our WordPress plugin, the plugin records the pages visitors view on that site under its own first-party cookie, pitlane_vid, and links them the same way; in those regions it records only after the visitor opts in. We process this to deliver the requested feature and make it available to the relevant workshop.

2.4 Usage and technical data

  • Browser type, operating system, and device information
  • IP address and approximate (city-level) location
  • Pages visited, features used, and time spent in the Service
  • Error logs and performance data used to operate and improve the Service

2.5 Cookies and analytics

We use cookies and similar technologies for essential functionality (authentication, security, site preferences) and for analytics and marketing measurement:

  • Essential cookies — required for login, security, and core Service operation. These cannot be disabled without breaking the Service. Cross-site request forgery protection does not generally use a cookie — it works by checking where the request came from — with one narrow exception: a short-lived cookie set only while you are connecting a third-party account or signing in with one, described in the Cookie & Tracking Notice.
  • Google Analytics 4 (GA4) — understanding aggregate usage to improve the Service.
  • Meta Pixel — measuring the effectiveness of our marketing campaigns. If automatic advanced matching is enabled in Meta's settings, Meta may receive hashed contact details (such as email, phone number and name) from forms on pages where the Pixel loads, including sign-up, demo and contact forms, through automatic advanced matching. This involves disclosure to Meta Platforms (United States); see section 11.
  • Sentry — error and performance monitoring. Sentry receives your IP address and request metadata, such as browser details and page addresses, and, for a sample of requests, request and response headers, with credentials removed; error and log messages and the details logged with them; with each error report and session recording, recent console messages and, in your browser, the labels of buttons and links you clicked; and, when you are signed in, your account identifiers and, where your account has them, your name, email address and role. It also receives recordings of a sample of browser sessions, and of most sessions in which an error occurs, with page text and form inputs masked and phone, email and text-message links left out, but the address of pages visited included; a page opened from a payment, invitation, password-reset or other access link, and any page visited after it until the browser next loads a page in full, is not recorded. The full list is on our Sub-processors page.
  • Our own advertising conversions — not a cookie and not a tag. When you send us an enquiry or demo request through this website, start a trial, or become a paying subscriber, our servers report that to PitlaneHQ's own Google Ads, Meta and Microsoft Advertising accounts so we can tell which of our ads worked, and to our own Google Analytics 4 property. In these server-side conversion sends, your email address goes with it to the three advertising platforms, SHA-256 hashed first, and your phone number too where you gave us one on an enquiry form — the trial and subscription events carry the email alone. Google Analytics 4 receives neither. The field-by-field list is on our Sub-processors page.

Being straight with you about the current position: non-essential analytics and advertising tags — Google Analytics 4 (when configured), Google Tag Manager (when configured) and Meta Pixel (when configured) — load on our public marketing website and the sign-up page. We do not present a consent banner. You can block browser tags with a tracker blocker or use browser and platform privacy controls. You can also ask us to exclude you at privacy@pitlanehq.com.au. Note that those browser-level controls act on tags in your browser, so they stop the Google Analytics 4 tag, Google Tag Manager and the Meta Pixel but do not reach the conversion sends in the bullet above, which run on our servers. There is no self-service switch for those; ask us and we will stop sending further events about you, which we do by hand. Full detail, including who receives what, is in our Cookie & Tracking Notice. None of this applies inside the product: no advertising or analytics tag is loaded there, and no advertising cookie is set. Marketing attribution is a separate thing, it runs on our servers rather than in your browser, and it does reach advertising platforms — section 5.1 sets out what is sent, to whom, and when.

3. How We Use Personal Information

We use personal information only for purposes connected with providing and operating the Service:

  • Provide and maintain the Service — deliver workshop management features and process data on the workshop's behalf
  • Communicate with you — send transactional messages (invoices, booking confirmations, password resets), service announcements, and support responses
  • Process billing — manage PitlaneHQ subscription billing via Stripe, and record it in PitlaneHQ's own accounts in Xero
  • Improve the Service — analyse aggregate usage, diagnose issues, and develop features
  • Security and fraud prevention — detect and prevent unauthorised access, abuse, and other threats
  • Legal compliance — meet our obligations under Australian law

We will not use or disclose personal information for a purpose other than the one for which it was collected unless you would reasonably expect it, you consent, or the use is otherwise permitted under the APPs.

4. Artificial Intelligence and Automated Processing

Ask the Boss may be processed outside Australia by an AI sub-processor. When Ask the Boss is configured to run through the overseas routing service, each request asks it to route only to zero-data-retention providers that do not collect the data. The other AI assistance features that generate or analyse text may also be processed outside Australia once we switch them to that routing service; their requests ask for the same zero-data-retention routing. Matching imported staff, booking and customer records during a data import may also be processed outside Australia, through that routing service, whenever it is configured; those requests ask that providers do not collect the data, but do not ask for zero data retention. Our sub-processor list names it and where it processes data.

Depending on the features used and the user's permissions, Ask the Boss can receive questions and conversation text; customer names; staff and technician names and hours worked; vehicle details, including registration numbers (rego), VINs and specifications; job numbers, status, descriptions, notes and repair history; quote and invoice descriptions, draft line items and prices; booking details; stock names, SKUs, quantities, reorder levels and locations; catalogue names and prices; and manufacturer technical data.

Some optional features (collectively, “Ask the Boss” and our AI assistance features) use machine-learning models to generate draft text and suggestions — for example, drafting SMS replies, polishing quote and invoice wording, cleaning up technician notes, and assisting with job estimation. Where these features are enabled:

  • Relevant workshop data is processed by our AI sub-processors to generate the output. This processing occurs to deliver the feature you requested. The providers engaged for this purpose, and their locations, are named in our Sub-processors list.
  • Outputs are drafts for human review by default. Except for the decisions listed in section 4.2, we do not make decisions that produce legal or similarly significant effects about an individual by automated means alone. A workshop user reviews and decides whether to use an AI-generated output — unless that workshop has switched on automatic SMS or website chat replies, which are off unless enabled. Section 4.2 says which automatic replies are checked before they are sent, and lists the decisions our features make without a person reviewing them first.
  • Where the insights come from. The insights and history a workshop sees about its own jobs draw only on that workshop's own data. The pooled records described below are used only internally by PitlaneHQ to improve the platform. They carry no workshop name or account identifier, and they are never shown to, or used in any feature for, another workshop.
  • Pooled repair records for platform improvement (optional). If a workshop enables Ask the Boss by accepting its terms and does not tick the contribution opt-out offered on the same screen, repair and inspection records from its completed jobs are pooled into our platform intelligence and combined into cross-network statistics — such as how often a repair is seen on a given make, model and mileage band, typical labour-hour ranges, repairs that commonly occur together, and seasonal patterns. Before pooling we remove the customer details we hold for the job — names, contact details, plates, VINs and addresses — and we strip prices we can detect from the text. That removal is automated and works from what we hold, so it is not a guarantee: someone we have no record of, named only in a technician's note, can survive it. A pooled record has no price fields and no workshop name or account identifier. A pooled repair record keeps an internal reference to the job classification it came from, so we can trace it and delete it on request; it includes the vehicle's make, model, year, class, fuel and engine details, driver-assistance features and mileage band; the repair type and parts categories; redacted symptom and fix summaries and a numeric vector derived from them, used to find similar repairs; diagnostic trouble codes; labour hours, turnaround time, staff count and repeat-repair, sublet and third-party-billing flags; the job completion date; and, where recorded, the state or territory of the workshop's registered business address. A pooled inspection record includes the vehicle's make, model, year, class and mileage band; the standardised inspection item checked and its result; the inspection date; and, where recorded, the same state or territory — it keeps no reference back to its source workshop, so once pooled it cannot be attributed to any workshop or individually deleted for one. It is never your raw data shared with another workshop. Pooled records are used only internally by PitlaneHQ to improve the platform. They are never shown to, or used in any feature for, another workshop. A workshop can opt out at any time from Settings → Ask the Boss, and we will exclude it from this contribution going forward.
  • What we keep if you leave. The cross-network statistics we derive from pooled records — how often a repair is seen on a given make, model and mileage, and similar patterns — store no workshop or customer identifier, and a group is only published once at least five contributing jobs sit behind it. They are part of PitlaneHQ's own product data and are retained if your workshop closes. The pooled repair records your workshop contributed are deleted with the rest of your data, located through the internal reference each one keeps. Pooled inspection records are not: they keep no reference back to your workshop, so they cannot be located or deleted for one, and they remain in the pool.
  • Technical reference data sourced from licensed third-party providers is excluded from any model training, consistent with our licensing obligations.

4.1 AI receptionist

The AI receptionist is an optional feature, off by default, that a workshop can turn on for a site so an AI agent answers calls to that site's texts number. Nothing in this section applies to calls to a workshop that has not switched it on, with one exception: once Pitlane has made the AI receptionist available to a workshop and an owner or administrator has acknowledged its notice, a call to one of that workshop's texts numbers that our call handling fails to answer can go to a recorded voicemail, even while the AI receptionist is off. Where a workshop uses it:

  • Calls are handled by an overseas AI sub-processor. It turns the caller's speech into text, runs the conversation on an AI model, speaks the replies, and writes the transcript and summary. It receives the caller's and called numbers, the call audio, everything said on the call, and what the agent looks up to answer it, then sends us the recording, transcript and summary. Section 11 says who it is and where, and our sub-processors page sets out the detail.
  • Callers are told. Every call starts with the agent saying the call is recorded and transcribed. The workshop chooses whether the opening also says the caller is speaking with an AI assistant. The “Tell callers they're speaking with an AI” setting is off unless the workshop turns it on. A workshop cannot turn the feature on until an owner or administrator acknowledges the recording notice.
  • A caller who objects. If a caller objects to the recording or to speaking with an AI, the agent records the objection and tells the caller that the workshop will not keep the audio of the call but keeps a written transcript. We then delete the recordings we hold for the call, a voicemail left on it included, and ask the AI sub-processor to delete its copy of the conversation once the transcript has reached us, or about a day after the objection if it has not. The transcript and summary follow the transcripts period in section 9. Both deletions wait while the call is held to meet a legal obligation.
  • What is automated, and what is not. The agent answers questions about the workshop, takes messages, and sends booking requests that staff accept or decline; it does not confirm a booking itself. It tells a caller a job's stage only after they read back a code texted to the mobile number the workshop holds for that customer. It does not make decisions with legal or similarly significant effects about a caller. The summary of a call is a draft for staff, not a record of fact. Section 4.2 lists the decisions it makes.
  • Answers suggested from past calls and texts. For a workshop with the AI receptionist, we read its recent call transcripts, and the text messages its customers sent together with the staff replies, and suggest general answers about the workshop that the AI receptionist could give, such as which services it offers. This is on by default, and an owner or administrator can turn it off. The calls and texts are not sent to the AI receptionist's provider for this (section 11). We discard any suggestion in which we detect a name, email address, phone number or amount of money; that check is automated, so staff should still read each one. We do not read the calls and texts of customers who have asked to be erased. If a customer asks to be erased while a run is already under way, the calls and texts that run had already read may still be processed, but no suggestion the run ties to them is stored. Staff must approve a suggestion before the AI receptionist can use it; suggestions nobody approves are discarded after 30 days. When a customer's erasure request is carried out, any answer suggested from their calls or texts is deleted, approved or not. An approved answer reaches the AI receptionist's provider whenever the AI receptionist's knowledge search returns it during a call, whether or not it is read out.

4.2 Automated decisions

From 10 December 2026, the Australian Privacy Principles require a privacy policy to say when a computer program uses personal information to make a decision, or to do something substantially and directly related to making one, that could reasonably be expected to significantly affect someone's rights or interests. That test can reach decisions with smaller effects than the “legal or similarly significant effects” mentioned in section 4, and it is not always clear whether the decisions below meet it, so we list them anyway. They are made by the AI receptionist, the SMS and website chat assistant, automatic SMS replies, website chat auto-reply, booking reply texts, SMS rebooking, the cancellation waitlist, quote intake, lead scoring, automatic late fees and call coaching. Each is part of a feature a workshop chooses to turn on, and some of these features are still being introduced and may not yet be available to every workshop.

Decisions a program makes without a person reviewing them first:

  • Checking who a caller is (AI receptionist). Before it tells a caller a job's stage, lists their bookings, quotes or invoices, or takes a request about one of them, the AI receptionist matches the number they are calling from to a customer, texts a code to the mobile number the workshop holds for that customer and refuses until the caller reads it back. If it cannot match the caller, finds no mobile number on file or cannot send the code, it withholds the details and offers to take a message. It sends at most two codes on a call. After three wrong codes it stops for the rest of that call and offers to take a message. For a job's stage, the caller also gives the vehicle's registration, and after three registrations that do not match that customer's vehicles it stops giving job stages for the rest of that call. It uses the caller's number, the customer's mobile number on file, the code, and for a job's stage the registration and the customer's vehicles.
  • Booking requests by phone (AI receptionist). The AI receptionist checks a requested booking against the workshop's booking settings, the diary and the caller's customer record. It refuses, for example, a date too soon or too far ahead to book by phone, a time that is no longer free, work the workshop does not take bookings for by phone, any booking once the day's limit on phone bookings is reached and a booking with no usable phone number. Where the workshop turns on self-service and the caller has passed the code check, it also refuses a booking for a customer who must give a purchase order number and has not, or who has asked to be erased. It then offers another time, asks for what is missing or takes a message. A booking request it does accept goes to staff, who accept or decline it. It uses the details the caller gives, such as their name, number, vehicle and the booking they want, and the customer record their number matches.
  • Changing a booking by phone (AI receptionist, where the workshop turns on self-service). Once a caller has passed the code check, the AI receptionist cancels an upcoming, still-open booking they ask to cancel straight away if it is not linked to a job or a fleet request; if it is, the cancellation goes to staff to decide. A request to move a booking always goes to staff, and a new date outside the workshop's booking settings is refused. It uses the customer's bookings and the date and time the caller asks for.
  • Replying to booking texts (SMS). When a customer replies YES or NO to a booking reminder, the program confirms or declines the soonest upcoming pending booking it sent them a reminder for, when it can match the reply to one. A reply of C cancels their upcoming booking at once when it comes from the booking's mobile number, unless the booking is linked to a job or a fleet request, in which case staff decide. A reply of R asks to move it. Where a site turns on SMS rebooking, after a NO, or an R about a booking that is not yet confirmed, the program can text up to three free days in the next 14 days. When the customer replies 1, 2 or 3 within 24 hours, it moves the booking to that time, but only if the time is still free and the booking has not changed since the offer; otherwise the booking stays as it was and the text says the workshop will call. An R that gets no offer goes to staff. When a C or R reply cannot be matched to exactly one upcoming booking, nothing changes and the text waits for staff, and so does a YES or NO that matches no booking. It uses the customer's phone number, their bookings, the reply and, for new times, the workshop's diary.
  • Sending SMS and assistant replies automatically (where a workshop switches that on). For automatic SMS replies, and for the SMS and website chat assistant in automatic mode, a program decides whether each AI-written reply goes out without a person reading it first. A second automated check rates the reply, and the reply is sent only when that check finds it safe with enough confidence; otherwise it is held for staff. The SMS and website chat assistant also hands the conversation to staff instead of answering when the customer's message contains certain words, such as “person”, “human”, “speak to someone”, “complaint”, “refund”, “payment”, “invoice” or “where is my car”, once a conversation has had a set number of assistant replies, or when it is unsure, and it does not send automatically a reply that our checks flag as containing a price or a promise. It uses the messages in the conversation and the answers the workshop has approved.
  • Website chat auto-reply (where a workshop turns it on and does not use the assistant). The AI replies to a website visitor without a person reading the reply first and without the second check described above. It hands the conversation to staff when the visitor's message contains words such as “person”, “human” or “speak to someone”, and after a set number of AI replies (three unless the workshop changes it). It uses the visitor's messages and name.
  • Offering a freed time to the waitlist (SMS, where a site turns on the cancellation waitlist). When a booking is cancelled, the program texts a link to up to three customers on the site's waitlist whose available times fit the freed time, oldest entry first. The first to accept through the link gets a booking request that staff accept or decline. It uses the waitlist entries, the times each customer said they can come in, and their phone number.
  • Late fees (where a workshop turns them on). A fixed rule, not an AI model, adds a late fee to an invoice that is still overdue, with an unpaid balance, once the grace period the workshop sets has passed. The fee is either a fixed amount or a percentage of the unpaid balance for each day since the due date, as the workshop chooses, and tax is added to it. The fee is added as a line on the invoice and raises its total. It adds a late fee only to an invoice that does not already have one. It uses the invoice's status, due date, total and the payments made on it, and the workshop's late fee settings.

Decisions where a program helps staff decide:

  • Urgent calls and call-backs (AI receptionist). After each call, the AI judges from what was said whether the caller described an unsafe car or needed an urgent call-back, asked to be called back, or wanted a booking that could not be made. It raises a task for staff, marked high priority when the call is urgent. Staff decide what to do. It uses the call's transcript and the customer record the caller's number matches.
  • Quote approvals and payment links (AI receptionist, where the workshop turns them on). When a caller who has passed the code check approves or declines a quote or extra work, or asks for a payment or deposit link, the AI receptionist passes it to staff as a request to review. It does not change the quote or send a link itself. It uses the customer's quotes and invoices and what the caller says.
  • Booking requests by SMS and website chat (SMS and website chat assistant). The assistant offers free times from the workshop's diary and sends the booking request the customer chooses to staff, who accept or decline it. If no time is free or the request cannot be made, it hands the conversation to staff. It uses the messages in the conversation and the customer's name, email address and phone number.
  • Suggested replies (SMS and website chat assistant). Where the workshop uses suggest mode, the assistant writes each reply for staff to send, change or discard. The booking requests and enquiries described in this list are still made in suggest mode, before staff see the reply. It uses the messages in the conversation and the answers the workshop has approved.
  • Enquiries and draft quotes (SMS and website chat assistant, where the workshop turns on quote intake). The assistant asks for the customer's name, contact details, registration and what they need, and records them as an enquiry. It then chooses, from the workshop's own job and service templates, the ones that match the request. Where an SMS enquiry matches a single existing customer, through the customer linked to the conversation or the phone number, it builds a draft quote from those templates: a job template gives its own lines and prices, the workshop's labour rate, or a line left for staff to price, and a service template is priced for that customer; otherwise it saves the chosen templates on the enquiry. The program never sends a draft quote: staff review it, change it if needed and decide whether to send it. It uses the customer's messages, name, phone number, email address and registration, and for a matched customer their customer record, vehicle and pricing.
  • Quote requests by phone (AI receptionist, where the workshop turns on quote requests). The AI receptionist takes the caller's name, contact details, vehicle and what they need, and records them as an enquiry for staff, up to three on a call. If the caller has passed the code check, it starts a draft quote on their customer record. If no customer has the phone number or email address given, it creates a new customer record and starts a draft quote for them. In both cases, when the caller gives a registration or a make and model, it adds that vehicle to the record unless a vehicle with the same registration is already on it. If a customer does have that number or email address but the caller has not passed the code check, it does not link the enquiry to that customer, and staff are asked to check it. A draft quote it starts has no lines or prices, and the program never sends it: staff fill it in and decide whether to send it. It uses what the caller says, the number they call from, and the customer records that number or email address matches.
  • Call coaching scores (staff phone calls, where the workshop turns on call coaching). After a call that a staff member answered, that lasted at least a minute and that has a transcript, the AI can score from 1 to 5 how they greeted the caller, found out what was needed, offered a booking or next step, explained clearly and stayed courteous, and note what went well and what to improve. Only staff the workshop allows to see coaching scores can see them. It uses the call's transcript and who answered it.
  • Lead scoring (Pitlane Connect). Where a workshop installs Pitlane Connect on its own website, a fixed formula, not an AI model, scores the website browsing linked to each enquirer or customer from 0 to 100: how many pages they viewed, how many different service, pricing, booking, quote or contact pages they viewed, how recently and how often they visited, and whether they made an enquiry or booking there. Staff see the score and what made it up. If the workshop turns on the browsing win-back list, people with a high score and no recent enquiry or booking appear on that list for staff to review; the score never decides on its own who is sent a message. It uses that browsing and the enquiries and bookings linked to it.

Asking a person to look again. On an AI receptionist call, ask to speak to a person: where the workshop has call transfer on, the AI is set up to put you through, and otherwise to take a message so the team can call you back. In an SMS or website chat conversation with the assistant or website chat auto-reply, write that you want a person, using words such as “person”, “human” or “speak to someone”, and the conversation is handed to the workshop's staff. At any time you can contact the workshop directly and ask its staff to review a decision listed here; they see the calls, messages, requests and drafts behind it and can change the outcome, for example by booking a date the AI receptionist refused. You can also contact us using the details in section 15.

5. Disclosure and Sub-processors

We do not sell personal information. We disclose information only to the service providers (“sub-processors”) needed to deliver the Service, and only as necessary for that purpose. The list — including each provider's location, purpose, and the categories of data they process — is published at pitlanehq.com.au/legal/sub-processors and is kept current as providers change. It also names the analytics providers used on our own marketing website and the sign-up page, and the provider involved if you choose to sign in with Google or Microsoft where that sign-in is switched on. If you believe a recipient is missing from it, tell us at privacy@pitlanehq.com.au and we will correct it.

Categories of recipient include:

  • Infrastructure — hosting, database, and encrypted backups (Microsoft Azure in Australia; Cloudflare; AWS and Backblaze for backups)
  • Payments and communications — Stripe (PitlaneHQ subscription billing), Xero (PitlaneHQ's own accounts: every workshop we bill is recorded in our own Xero organisation, whether or not it uses Xero itself, with its trading name, email address (the account owner's, or else the workshop's) and street address and the subscription invoices, credit notes and payments we record against it), Global Payments (Pitlane Pay — card payments a workshop takes from its own customers, including counter sales), Twilio (SMS, and voice calls to a site's texts number, including forwarded calls, calls connected to the AI receptionist and the voicemails it records where a workshop has the AI receptionist), Resend (email), RingCentral (telephony, and call recording or transcription where a workshop enables it), ElevenLabs (the AI receptionist, where a workshop turns it on)
  • Observability — Sentry (error and performance monitoring)
  • Opt-in integrations — engaged only when a workshop activates them: accounting providers (a workshop's own Xero organisation, QuickBooks Online), vehicle data and visualisation providers. Data flow to the workshop's connected provider stops when the workshop disconnects the integration. Where a workshop connects its own Xero organisation, PitlaneHQ exchanges the following with that organisation: it reads and writes invoices, supplier bills, credit notes, payments, credit-note allocations, and customer and supplier contacts, and can void invoices and credit notes and delete payments it previously recorded; it uploads attachments to supplier bills, can replace a file it uploaded to a bill earlier when that bill's document changes, and reads the file names and Xero identifiers of those already attached; where the workshop turns on bringing in files attached in Xero, it also reads the details (such as the file name, type and size) of the files attached in Xero to the workshop's linked invoices, credit notes and supplier bills and downloads the PDF and image files among them, when staff use “Get files from Xero” on one of them and after Xero notifies a change to a linked invoice or bill, and stores the files it brings in with that record in PitlaneHQ, where they count toward the workshop's storage; it reads the organisation's details, its account and tax-rate settings, and the list of Xero organisations the connecting user has connected to PitlaneHQ; when the connection is made, Xero also returns the connecting user's Xero identity (such as their name and email address); it receives the change notifications Xero sends about that organisation; and, where the workshop has also connected Xero Payroll (Australia or New Zealand), it reads employee records (keeping only each employee's name, Xero identifier, whether they are still employed and, in Australia, a reference to their ordinary earnings rate), earnings rates, payroll calendars and leave details, writes timesheets and leave applications, and in New Zealand can delete timesheets and leave it previously wrote. This is separate from PitlaneHQ's own accounts in Xero, listed under payments above. Where a workshop connects QuickBooks Online, and only then, PitlaneHQ creates and updates that workshop's customers, invoices, credit notes and supplier bills, creates its suppliers, records its payments and refunds, uploads supplier-bill documents, reads those records back along with the names of documents already attached to a bill, reads its currency, account, tax, product and payment-method settings, and deletes the matching QuickBooks entries when the workshop voids a credit note or reverses a supplier payment. It does not access QuickBooks Payroll.
  • Sign-in providers — engaged only for a person who chooses to use one, not switched on by a workshop: Google, if you choose to sign in with Google. Google tells us who you are. Beyond the fact that you are signing in to PitlaneHQ, the most we send Google is your own email address, as a hint when you link a Google Account to your login — nothing from the workshop's records and nothing about its customers. If Microsoft sign-in is switched on and you choose it, Microsoft confirms your identity; we send Microsoft your PitlaneHQ email address as a sign-in hint only when you link from Settings > Security, and send no workshop records or customer information. The Sub-processors page sets out what passes each way.
  • Advertising platforms — engaged only where a workshop connects its own advertising accounts: Google (Google Ads, and the workshop's own Google Analytics 4 property), Meta, Microsoft Advertising, TikTok, and LinkedIn. Section 5.1 explains what they receive.
  • Planned, not yet engaged — social publishing (Meta), Google Business Profile posting (Google), a map provider for live tracking of mobile jobs (Microsoft Azure Maps) and a stock-matching pilot (TypeSafe, through OpenRouter, outside Australia), each listed on the sub-processors page ahead of time (section 11). The first three are engaged only where a workshop turns the feature on; the pilot only for workshops whose AI features are switched on.

We provide workshops at least 30 days' notice before engaging a new sub-processor that will process workshop or customer personal information. We may also disclose information where required by law, court order, or governmental authority, or to protect the rights, property, or safety of PitlaneHQ, our users, or others.

Franchise and enterprise groups. Where this workshop is part of a franchise or enterprise group, your information may be accessed by that group's head office for reporting and oversight, consistent with Australian Privacy Principles 5 and 6. This access is read-only and is recorded in an access log. The same notice appears on invoices and quotes issued by member workshops.

5.1 Marketing attribution (advertising platforms)

Correcting an earlier version of this policy: it said the product “carries no advertising or third-party tracking”. That was wrong, and had been since the marketing-attribution feature shipped. There is no advertising shown in the product and no ad network tag loaded in it, but end-customer data does leave our servers for advertising platforms in the case described here.

The feature does nothing until a workshop connects its own advertising accounts in the Marketing module. Once it has, PitlaneHQ sends an event from its servers as one of that workshop's customers moves through the funnel — an enquiry created, a quote sent, a quote accepted, an invoice paid — to whichever of Google Ads, Meta, Microsoft Advertising, Google Analytics 4, TikTok and LinkedIn that workshop has switched on. Where the workshop has separately accepted the platform's customer-data terms, hashed contact lists are also uploaded to Google Customer Match, Meta Custom Audiences and Microsoft Customer Match; connecting the account alone does not turn that on. Google and Meta receive a hashed email and a hashed phone number, each only where we hold it for that customer; Microsoft receives a hashed email and never a phone number, because its list format has no phone field. Two lists are built: customers with an invoice paid in the last 540 days, and customers sent a quote in the last 90 days that has not converted.

Email addresses and phone numbers are SHA-256 hashed before they leave our servers, and so are names, for every platform that receives them but one. Some things are not hashed, because those platforms will not match a hashed value. Ad click identifiers and advertising cookie values are sent as they are; Meta and TikTok also receive the customer's IP address and browser user-agent; Google Ads receives country and postcode in plain text; and LinkedIn receives a plain-text first and last name where we hold no hashed email or LinkedIn identifier for that person. The field-by-field list per platform is on the sub-processors page.

A customer who has opted out of marketing is excluded: no conversion event about them is sent. The audience uploads exclude them too, and go further by also excluding anyone who has asked to be erased. Coming off a list we have already uploaded works differently by platform: an erasure request sends Google and Meta an active instruction to remove that person's identifiers, while for Microsoft no such instruction exists — the daily upload replaces the whole list, so they drop out when the next daily replace runs, and stay in the list Microsoft already holds if that sync stops before it. Consent mode is on by default for workshops outside Australia, New Zealand and the United States, or whose country we do not hold, and any workshop can switch it on. Where it is on, a conversion event is suppressed unless that customer granted the matching consent — advertising consent for the advertising platforms, analytics consent for Google Analytics 4. It works differently for the audience uploads: consent mode does not stop them, it changes what we tell Google, which is that consent is unspecified rather than granted. For these records the workshop is the responsible entity (section 1, second role): it decides whether an advertising account is connected at all. The send itself is performed by our servers and we choose the fields, so a workshop switching this on should tell its own customers what it means for them. Disconnecting the account stops further sends; removing someone from an audience already uploaded is what the erasure path does.

6. Direct Marketing and the Spam Act

We may send you marketing communications about PitlaneHQ where permitted. In doing so we comply with APP 7 and the Spam Act 2003 (Cth):

  • We send commercial electronic messages only with your express or inferred consent
  • Every marketing message identifies us and includes a functional unsubscribe facility
  • We action unsubscribe requests promptly (within the statutory period)

Note for workshops using the Marketing module: when a workshop sends SMS or email campaigns to its own customers through the Service, the workshop is the sender and is responsible for holding the necessary consents and complying with the Spam Act for those messages. The Service provides consent-management and unsubscribe tooling to assist, but the workshop remains accountable for its own marketing.

7. Data Security

We implement technical and organisational measures appropriate to the sensitivity of the data, including:

  • Encryption in transit — all traffic to and from the Service uses TLS/HTTPS
  • Encryption at rest — sensitive credentials and integration tokens are encrypted at rest using strong, industry-standard encryption
  • Access controls — role-based permissions restrict users to data relevant to their role
  • Multi-tenant isolation — each workshop's records are logically segregated and inaccessible to other workshops. The pooled records described in section 4 are held separately, and are used only internally by PitlaneHQ; they are never shown to another workshop.
  • Secure authentication — passwords are securely hashed; user sessions use secure, short-lived tokens; optional two-factor authentication; sign-in with a third-party account, where offered, is verified on our servers before a session is issued
  • Australian primary hosting — the application and the primary database are located in Australia (Azure Australia East), with point-in-time recovery and geo-redundant encrypted backups. This is not an Australia-only guarantee: some sub-processors necessarily operate overseas (for example SMS delivery, error monitoring in Germany, and a secondary encrypted backup copy in the United States). Section 11 sets out the cross-border position and the Sub-processors list states each provider's location
  • Audit logging — data modifications are logged for accountability

No system is perfectly secure. While we take reasonable steps to protect personal information as required by APP 11, we cannot guarantee absolute security.

8. Employee and Payroll Data

Where a workshop uses our HR & Payroll module, the Service processes employee personal information — which may include contact details, employment records, timesheets, pay and superannuation details, and tax identifiers. This information is treated with heightened care:

  • The workshop is the employer and the responsible entity for its employees' personal information; PitlaneHQ processes it solely to provide the HR and payroll features and, where the workshop enables it, to sync payroll records to the workshop's connected accounting platform.
  • Tax File Numbers and similar identifiers are subject to additional protections; we handle them only as necessary to deliver payroll functionality and in line with the relevant Tax File Number Rule.
  • The same encryption, access-control, and Australian-residency measures in section 7 apply.

9. Data Retention

We retain personal information only for as long as necessary for the purposes set out in this policy, or as required by law:

  • Workshop operational data (jobs, invoices, customers, vehicles) is retained for the duration of the workshop's subscription so the workshop can run its business.
  • After cancellation or trial expiry, we keep workshop operational data for 60 days, then schedule it for deletion from the live Service, except where longer retention is required by law or as described in the next point. Warning emails may extend the deadline. By default, deletion scheduled by a PitlaneHQ admin follows the same 60 days and warning emails. Existing retention deadlines continue to apply. Export your data before you leave. PitlaneHQ keeps its own subscription billing records with the workshop business name, ABN and original workshop identifier; receipt email addresses and payment method details are removed. A workshop may request earlier deletion of its data.
  • Supplier bills forwarded by email — where a workshop turns on a bills forwarding address, each message it receives is held under that workshop for up to 90 days if nobody converts it into a bill, and for 30 days if it was quarantined, rejected, dismissed or was a duplicate; a daily sweep then deletes the message and its stored PDF. Once a message is converted, its PDF becomes part of the bill and follows the bill's lifecycle above. One exception: if a workshop resets its own data, the inbox records go with the reset immediately, and a stored PDF the sweep can no longer find stays in storage, unreachable through the Service, until the workshop's data is deleted.
  • AI receptionist recordings and transcripts — the workshop chooses how long we keep them, separately for recordings (90 days unless it changes this) and for transcripts, summaries and notes (365 days unless it changes this), anywhere from 30 days to 7 years. A scheduled sweep then deletes them from the Service and asks ElevenLabs to delete its copy if it still holds one. The record that the call happened, its charges and the audit log are kept, and so are the messages, call-back notes and call summaries the AI saves to staff tasks and the booking requests it sends, which these periods do not reach. Voicemails left where a workshop has the AI receptionist follow the recordings period. Where a caller objects to the recording, we delete the call's audio sooner and ask ElevenLabs to delete its copy within about a day (section 4.1). Suggested answers nobody approves are discarded after 30 days (section 4.1).
  • Job videos (planned, not yet available) — once available, a video a workshop records and shares with its customer will be deleted 60 days after it is uploaded.
  • Technician location for live tracking (planned, not yet available) — once available, and only where a workshop turns live tracking on for a mobile job, the technician's location points will be deleted 24 hours after the trip.
  • Deletion snapshot — when we start deleting a workshop's data we write a snapshot of it to storage only PitlaneHQ can reach, held with the rest of the Service's data in Australia (section 7). It contains the workshop's own record and its sites, its users' names, email addresses and roles, its customers, vehicles, jobs, invoices, quotes and bookings — including records the workshop had already deleted within the Service — and a summary of its billing and phone-number setup with our payment and messaging providers. It excludes passwords, two-factor secrets, API credentials, bank account details, director identity details, and uploaded files. We keep it so a deletion made in error can be reversed and so we can evidence what was deleted. A deletion that does not finish can leave a snapshot of data that is still live; any snapshot is deleted 90 days after it was written, and our storage provider's recovery copies of it are erased within a few weeks after that.
  • Audit and security logs are kept for at least 90 days in the live Service to support security and accountability. In addition, under our record-keeping policy, a copy of the audit log is written daily to write-protected archive storage and kept for seven years, so that we hold an unaltered record of who changed what for security, fraud investigation and our own record-keeping obligations. This copy can include names and other details recorded in audit entries (for example who changed a record). Because it must stay unaltered to serve those purposes, it is generally kept when a workshop account is deleted or when we act on an erasure request, unless the law requires us to remove it, and we use it only for those purposes.
  • Backups — operational backups are retained on a rolling basis (up to approximately six months) and cycle out automatically. In addition, an encrypted compliance snapshot is retained in cold storage for up to seven years to meet Australian financial-record and related legal obligations. When data is deleted from the live Service it is removed from operational backups as they expire; a copy may remain in the encrypted compliance snapshot until that snapshot expires, after which it is deleted. The deletion snapshot described above is not a backup — it is written when deletion starts and deleted 90 days after it was written (recovery copies within a few weeks after that), and it is included in each backup taken while it exists.
  • Earlier versions of trial cleanup wrote a separate JSON backup before purging expired trial data. Those backups are deleted once they are older than 30 days, including all stored versions.

10. Your Rights (APP 12 and APP 13)

Subject to the Privacy Act, you have the right to:

  • Access — request a copy of the personal information we hold about you
  • Correction — request correction of inaccurate, out-of-date, or incomplete information
  • Deletion — request deletion of your personal information, subject to legal retention obligations and the audit archive described in section 9
  • Complaint — complain to us and, if unsatisfied, to the Office of the Australian Information Commissioner (OAIC)
  • Data export — workshops can export records (customers, vehicles, jobs, invoices, suppliers and stock) as CSV with the export permission. Jobs and invoices also require workshop-wide access, including archived sites.

If your request concerns data a workshop holds about you as its customer or employee (section 1, second role), we will refer you to, and assist, the relevant workshop, who is the responsible entity for that data. To exercise a right or make an enquiry, contact privacy@pitlanehq.com.au. We aim to respond within 30 days.

11. Cross-Border Disclosure (APP 8)

Some sub-processors process data outside Australia (see the sub-processors page for each provider's location and the safeguards that apply). Where we disclose personal information overseas, we take reasonable steps to ensure the recipient handles it consistently with the APPs — through Data Processing Addendums, Standard Contractual Clauses, or reliance on the recipient being bound by substantially similar protections. For overseas disclosures that depend on your consent, your use of the relevant feature indicates that consent.

AI receptionist (ElevenLabs, United States). Where a workshop turns the AI receptionist on, each call it answers is disclosed to ElevenLabs in the United States, including the caller's and called numbers, the call audio, everything said on the call and what the agent looks up to answer it. ElevenLabs uses an AI model provided by Anthropic, in the United States, to decide the agent's replies. We store the recording, transcript and summary it sends us in Australia. Each agent is set to have ElevenLabs keep a call for 30 days. If the caller objects to the recording, we ask ElevenLabs to delete it sooner (section 4.1). The workshop decides to turn the feature on after an owner or administrator acknowledges the recording notice. Every call starts with the agent saying the call is recorded and transcribed. The workshop chooses whether the opening also says the caller is speaking with an AI assistant. The “Tell callers they're speaking with an AI” setting is off unless the workshop turns it on. The answers we suggest from a workshop's past calls and texts (section 4.1) are worked out in Australia; an answer reaches ElevenLabs only once staff have approved it, and then whenever the AI receptionist's knowledge search returns it during a call, whether or not it is read out. Section 4.1 and our sub-processors page set out the detail.

Planned features (not yet available). Our sub-processors page lists, ahead of time, the overseas recipients that planned features will use. Before any of them is engaged we will also notify workshop administrators in the product and, for material changes, email the billing contact. Once those features are available, and only for a workshop that turns them on: publishing to a workshop's own Facebook Page and Instagram account discloses the posts and photos it approves to Meta in the United States; posting to its own Google Business Profile discloses the posts, photos and review replies it approves to Google in the United States; and live tracking for mobile jobs discloses the technician's location points and the job address to Microsoft Azure Maps in the United States or Europe. A stock-matching pilot, only for workshops whose AI features are switched on, will disclose a store listing's text and the names, brands and SKUs of the workshop's stock items it is compared with to TypeSafe, through OpenRouter, outside Australia; it only suggests matches, for staff to confirm. None of these starts before 3 December 2026 or, if later, 30 days after the in-product notice and the email go out.

12. Notifiable Data Breaches

We are subject to the Notifiable Data Breaches (NDB) scheme under Part IIIC of the Privacy Act. If we become aware of an eligible data breach that is likely to result in serious harm, we will notify affected individuals and the OAIC as soon as practicable, in accordance with the scheme. Where PitlaneHQ acts as a processor for a workshop, we will notify the affected workshop without undue delay so it can meet its own obligations, and we will reasonably assist its response.

13. Children's Privacy

The Service is intended for businesses and is not directed to individuals under 18. We do not knowingly collect personal information from children. If we become aware that we have done so, we will take steps to delete it promptly.

14. Changes to This Policy

We may update this Privacy Policy from time to time. We will notify you of material changes by email or by a notice in the Service. The “Last updated” date above reflects the most recent revision. Continued use of the Service after changes take effect constitutes acceptance of the updated policy.

15. Contact Us

For privacy enquiries or to exercise your rights, contact us:

If you are not satisfied with our response, you may lodge a complaint with the Office of the Australian Information Commissioner (OAIC) at www.oaic.gov.au.