Last updated: 27 June 2026

SMS Messaging Terms

SMS Messaging Terms

Australia SMS Messaging Terms for BuildPass Messaging Services

Australia SMS Messaging Terms

Effective date: 1 July 2026

These Australia SMS Messaging Terms are issued by BuildPass Pty Ltd ACN 652 324 635 (BuildPass, we, us or our).

1. Application and acceptance

1.1 These Australia SMS Messaging Terms (SMS Terms) apply to the use of the Messaging Services where:

  1. the Customer, User or relevant Project is located in Australia;
  2. a Message is sent, or proposed to be sent, to an Australian telephone number;
  3. a Recipient is located in Australia; or
  4. Australian law otherwise applies to the Message or the use of the Messaging Services.

1.2 These SMS Terms form part of, and must be read together with, the BuildPass Terms of Service and Privacy Policy.

1.3 Capitalised terms that are not defined in these SMS Terms have the meaning given to them in the BuildPass Terms of Service.

1.4 By accessing or using the Messaging Services, selecting an acceptance checkbox, selecting "Agree and send", activating a Workflow, or otherwise causing a Message to be sent through BuildPass:

  1. the User agrees to comply with these SMS Terms;
  2. the User confirms that they are authorised to use the Messaging Services for the Customer; and
  3. where the User accepts these SMS Terms on the Customer's behalf, the User represents and warrants that they have authority to bind the Customer.

1.5 The Customer must ensure that each User who accesses or uses the Messaging Services:

  1. is authorised to do so;
  2. is given appropriate permissions and training;
  3. understands the permitted purposes of the Messaging Services; and
  4. complies with these SMS Terms.

1.6 The Customer is responsible for the acts and omissions of its Users in connection with the Messaging Services.

1.7 BuildPass may require a Customer, Administrator or User to accept or re-accept these SMS Terms:

  1. before using the Messaging Services;
  2. before sending a particular Message;
  3. before creating, activating or changing a Workflow;
  4. when these SMS Terms are updated; or
  5. where BuildPass reasonably considers further confirmation necessary.

1.8 If there is any inconsistency between these SMS Terms and the BuildPass Terms of Service, these SMS Terms prevail to the extent of the inconsistency in relation to the Messaging Services.

2. Definitions

In these SMS Terms:

Applicable Messaging Requirements means all laws, regulations, standards, codes, directions, regulatory guidance and provider requirements applying to a Message or the Messaging Services, including, where applicable:

  1. the Spam Act 2003 (Cth);
  2. the Telecommunications Act 1997 (Cth);
  3. the Telecommunications (SMS Sender ID Register) Industry Standard 2025;
  4. the Privacy Act 1988 (Cth);
  5. applicable State and Territory privacy, workplace, surveillance, employment, health and safety, emergency-management and telecommunications laws;
  6. requirements, directions and guidance issued by the Australian Communications and Media Authority;
  7. requirements imposed by telecommunications carriers, carriage service providers, electronic messaging service providers, SMS aggregators and other messaging providers; and
  8. any amendment, replacement or successor to those requirements.

BuildPass Sender ID means any alphanumeric, branded or other sender identifier controlled, registered, supplied or approved by BuildPass, including "BuildPass", "BUILD PASS" or any replacement or alternative sender identifier.

Commercial Electronic Message has the meaning given to that term in the Spam Act 2003 (Cth).

Customer Message means a Message that a Customer or User creates, enters, imports, configures, schedules, triggers, authorises or otherwise causes to be sent through the Messaging Services.

Emergency Message means a Customer Message created and sent through the Emergency Module.

A message created or sent through a Workflow, broadcast, general SMS feature, notification feature or any other part of BuildPass is not an Emergency Message, regardless of its content, urgency or how it is described by the Customer or a User.

Emergency Module means the dedicated emergency messaging feature made available by BuildPass and identified within the BuildPass platform as the emergency module.

Essential Security Functionality means BuildPass functionality specifically designated for authentication, identity verification, fraud prevention, account security or the generation and delivery of a one-time password or passcode.

Essential Security Message means a system-generated Message produced through Essential Security Functionality for authentication, identity verification, fraud prevention, account security or the delivery of a genuine one-time password or passcode.

Message means an SMS, MMS or other text message sent or proposed to be sent using the Messaging Services.

Messaging Services means the SMS, MMS and related text-messaging functionality made available through BuildPass, including:

  1. general SMS functionality;
  2. broadcast functionality;
  3. Workflow Messages;
  4. project and operational notifications;
  5. the Emergency Module;
  6. Essential Security Functionality; and
  7. any associated message-management, recipient-management, preference, suppression, Sender ID or delivery functionality.

Non-Critical Message means a Customer Message other than an Emergency Message or Essential Security Message.

Recipient means a person to whom a Message is, or is proposed to be, sent.

Suppression Record means a Workflow Opt-Out, unsubscribe request, do-not-contact request, invalid-number record or other messaging preference or restriction recorded or applied by BuildPass in relation to a Recipient, Project, Customer, Workflow or message category.

Workflow means an automated or configured process in BuildPass that generates, schedules, triggers or causes one or more Messages to be sent.

Workflow Message means a Customer Message generated, scheduled or triggered by a Workflow.

Workflow Opt-Out means a preference recorded by BuildPass indicating that a Recipient does not wish to receive one or more specified Workflow Messages, categories of Workflow Messages or other applicable non-critical project notifications.

3. Purpose of the Messaging Services

3.1 The Messaging Services are intended primarily to support genuine operational communications connected with current construction Projects and the use of BuildPass.

3.2 Permitted purposes may include:

  1. current Project and site updates;
  2. scheduling and attendance information;
  3. relevant delivery and site-logistics information;
  4. sign-on and attendance reminders;
  5. induction, permit and compliance reminders;
  6. routine health and safety information;
  7. site-access information;
  8. Emergency Messages;
  9. Essential Security Messages; and
  10. account-administration and service-related information.

3.3 Every Customer Message must:

  1. be sent for a genuine and lawful purpose;
  2. be reasonably necessary for that purpose;
  3. be accurate and not misleading;
  4. be directed only to Recipients who reasonably need the information;
  5. be proportionate in its content, timing, frequency and audience;
  6. contain no unnecessary personal or sensitive information; and
  7. comply with these SMS Terms and the Applicable Messaging Requirements.

3.4 The Messaging Services are not intended or authorised for use as a marketing, advertising, promotional or general-purpose bulk-messaging platform.

3.5 The availability of a technical feature in BuildPass does not mean that a particular use of that feature is permitted or lawful.

4. No marketing or promotional messages

4.1 Unless BuildPass has expressly made a separate marketing-messaging service available to the Customer under additional written terms, the Customer and its Users must not use the Messaging Services to send any Message whose purpose, or one of whose purposes, is to advertise, offer, promote or solicit:

  1. goods or services;
  2. the Customer or another business or organisation;
  3. a supplier, contractor or prospective supplier or contractor;
  4. employment, contracting or business opportunities unrelated to current Project activities;
  5. events, subscriptions, memberships or training products;
  6. competitions, surveys or questionnaires intended for marketing or promotional purposes;
  7. fundraising, donations or sponsorships;
  8. political campaigns or political support;
  9. discounts, special offers or sales opportunities; or
  10. any other commercial or promotional activity.

4.2 This restriction applies even if the Customer believes that the Recipient has consented to receive marketing or promotional messages.

4.3 A Customer Message must not contain:

  1. promotional wording;
  2. advertising or sales material;
  3. promotional footers;
  4. links to promotional content;
  5. unrelated offers or opportunities; or
  6. content intended to promote the Customer or another organisation beyond what is reasonably necessary to identify the sender.

4.4 A Message that has a legitimate operational, project, safety, compliance or account-related purpose may still be prohibited if it also contains marketing or promotional content.

4.5 The Customer must not use the Messaging Services to request consent to receive marketing or promotional communications.

5. Recipient eligibility and list management

5.1 Before sending a Customer Message, the Customer and sending User must reasonably determine that each proposed Recipient:

  1. is currently assigned to, engaged on, attending, supplying or involved with the relevant Project;
  2. is reasonably expected to attend, perform work or provide services for the relevant Project;
  3. may be directly affected by the matter addressed in the Message; or
  4. otherwise has a current and legitimate operational need to receive the Message.

5.2 The fact that a person:

  1. was previously inducted onto a site;
  2. previously attended or worked on a Project;
  3. was historically employed or engaged by the Customer, a Contractor or another organisation;
  4. remains recorded in a worker register, contact list or recipient group;
  5. previously supplied goods or services;
  6. has previously received Messages; or
  7. has not previously opted out,

does not, by itself, establish that the person has a current need to receive a Customer Message.

5.3 The Customer and its Users must select the smallest reasonably necessary audience for each Customer Message.

5.4 A User must not select:

  1. all inducted workers;
  2. all historical workers;
  3. all previous Project participants;
  4. all contacts associated with the Customer; or
  5. another broad recipient group,

merely because that group is readily available or convenient to select.

5.5 Where a broader audience is genuinely necessary, the Customer must be able to explain:

  1. the operational purpose of the Message;
  2. why the broader audience was necessary; and
  3. how the Customer determined that the proposed Recipients remained relevant.

5.6 The Customer must regularly review recipient information and remove, archive or exclude:

  1. outdated contacts;
  2. duplicated contacts;
  3. incorrect telephone numbers;
  4. reassigned telephone numbers;
  5. former Project participants who no longer have a relevant connection; and
  6. Recipients who no longer need the relevant communications.

5.7 The Customer must not use:

  1. purchased or rented recipient lists;
  2. scraped or harvested telephone numbers;
  3. a list produced using address-harvesting software;
  4. a list obtained from an unrelated organisation without lawful authority; or
  5. telephone numbers that the Customer knows, or ought reasonably to know, are invalid, reassigned or unrelated to the intended Recipient.

5.8 BuildPass may display warnings, audience counts, inactivity indicators or other controls intended to help identify stale, excessive or potentially irrelevant recipient selections.

5.9 Those controls do not replace the Customer's responsibility to review and approve the audience for each Customer Message.

6. Customer responsibility for Messages

6.1 The Customer is responsible for every Customer Message that it or one of its Users creates, enters, imports, configures, schedules, triggers, authorises or causes to be sent.

6.2 Without limitation, the Customer is responsible for:

  1. the content of each Customer Message;
  2. the purpose for which it is sent;
  3. the selection and accuracy of Recipients;
  4. the accuracy of mobile telephone numbers and other recipient information;
  5. the timing, frequency and volume of Messages;
  6. the configuration and ongoing operation of Workflows;
  7. obtaining and maintaining any consent, permission, authority or other lawful basis required to collect, use or disclose a Recipient's mobile telephone number and send the relevant Message;
  8. providing any privacy or collection notice required by law;
  9. identifying the organisation that authorised the Message;
  10. complying with Suppression Records and communication preferences;
  11. responding to complaints and requests received directly by the Customer;
  12. retaining appropriate records; and
  13. compliance with the Applicable Messaging Requirements.

6.3 Each time a User sends a Customer Message or creates, activates or materially changes a Workflow, the Customer and User represent and warrant that:

  1. the User is authorised to act for the Customer;
  2. the Message has a genuine, lawful and permitted purpose;
  3. the Message is permitted under these SMS Terms;
  4. the Message is not marketing or promotional;
  5. the proposed Recipients have been reviewed and satisfy clause 5;
  6. each proposed Recipient has a current and legitimate need to receive the Message;
  7. all required consents, permissions and authorities have been obtained and have not been withdrawn;
  8. the Message accurately identifies the Customer and relevant Project;
  9. all applicable Suppression Records have been respected;
  10. the Message is not deceptive, fraudulent, offensive, threatening, discriminatory, harassing or otherwise unlawful; and
  11. the Message complies with the Applicable Messaging Requirements.

6.4 The Customer must independently determine whether a Message:

  1. is a Commercial Electronic Message;
  2. requires consent;
  3. requires an unsubscribe facility;
  4. may lawfully be sent to a particular Recipient; or
  5. is subject to any specific workplace, safety, privacy, employment or telecommunications requirement.

6.5 BuildPass may provide message categories, templates, warnings, opt-out tools, audience controls and other compliance functionality.

6.6 Those tools:

  1. do not constitute legal advice;
  2. do not guarantee that a Customer Message is lawful;
  3. do not transfer the Customer's responsibilities to BuildPass; and
  4. do not prevent BuildPass from taking enforcement action.

6.7 BuildPass is not required to review or approve every Customer Message before it is sent.

6.8 Nothing in these SMS Terms excludes or transfers any legal obligation imposed directly on BuildPass.

7. Prohibited conduct

The Customer and its Users must not:

  1. send marketing or promotional Messages contrary to clause 4;
  2. send untargeted Messages to people who have no current or reasonably anticipated connection with the relevant Project;
  3. contact former workers or former Project participants merely because their details remain in BuildPass;
  4. send repeated, excessive, harassing or materially duplicative Messages;
  5. send Messages at unreasonable times without a genuine operational need;
  6. misrepresent the identity of the Customer, sender, Project or purpose of a Message;
  7. impersonate BuildPass or another person or organisation;
  8. state or imply that BuildPass authored, reviewed, approved or endorsed a Customer Message;
  9. use false, misleading or unauthorised sender information;
  10. use a BuildPass Sender ID outside the Messaging Services;
  11. remove, obscure, alter or circumvent sender-identification information, opt-out information or other compliance information inserted by BuildPass;
  12. override, evade or work around a Suppression Record;
  13. create a replacement Workflow, recipient group, Project or account for the purpose of contacting a Recipient who has opted out;
  14. use another User, Customer or Project account to avoid a Suppression Record;
  15. classify or send an ordinary operational Message through the Emergency Module for the purpose of avoiding an opt-out or other restriction;
  16. use or imitate Essential Security Functionality to send project, operational, marketing or free-form content;
  17. send malicious links, malware, scams, phishing content or content intended to obtain information by deception;
  18. send content that is unlawful, defamatory, threatening, abusive, discriminatory, offensive or harassing;
  19. include personal, health, financial, identity, security or other sensitive information beyond what is reasonably necessary for the permitted purpose;
  20. use address-harvesting software or a list created using address-harvesting software;
  21. interfere with a Recipient's ability to exercise an opt-out or messaging preference;
  22. instruct or encourage another person to breach these SMS Terms; or
  23. use the Messaging Services in a manner that may harm the reputation, security, availability or deliverability of BuildPass or its messaging providers.

8. Sender identification

8.1 Each Customer Message must clearly and accurately identify:

  1. the Customer that authorised the Message; and
  2. where relevant, the Project or site to which the Message relates.

8.2 Unless BuildPass inserts the relevant identification automatically, the Customer must include a recognisable identifier in substantially the following form:

[Customer trading name] - [Project or site name]:

8.3 Where required by law or reasonably requested by BuildPass, the Customer Message must also contain accurate contact information through which the Recipient can readily contact the Customer.

8.4 Contact information included in a Message must remain valid and functional for any period required by applicable law.

8.5 The appearance of a BuildPass Sender ID:

  1. identifies the sender identifier or messaging route used to deliver the Message;
  2. does not, by itself, identify the Customer that authorised the content;
  3. does not mean that BuildPass authored or approved the content; and
  4. does not remove the Customer's obligation to identify itself in the Message body.

8.6 The Customer and its Users must not state or imply that:

  1. a BuildPass Sender ID belongs to the Customer;
  2. BuildPass is the author of a Customer Message; or
  3. BuildPass endorses the Customer, Project or Message.

9. BuildPass Sender IDs

9.1 BuildPass's shared Sender ID has been approved for use under the Australian SMS Sender ID Register.

9.2 BuildPass may deliver Messages using a BuildPass Sender ID, a telephone number, a shared messaging route or another sender-identification method selected by BuildPass or its messaging providers.

9.3 All rights and interests in a BuildPass Sender ID remain with BuildPass or the applicable rights holder. The Customer receives no ownership interest in a BuildPass Sender ID.

9.4 The Customer's ability to cause Customer Messages to be delivered using a BuildPass Sender ID is limited, revocable, non-exclusive, non-transferable, restricted to use through the Messaging Services and conditional on compliance with these SMS Terms.

9.5 The Customer must not:

  1. attempt to register a BuildPass Sender ID in its own name;
  2. use a BuildPass Sender ID through another provider;
  3. authorise another person to use a BuildPass Sender ID;
  4. copy, imitate or create a confusingly similar Sender ID; or
  5. represent that it owns or controls a BuildPass Sender ID.

9.6 Customer-owned Sender IDs are not available through BuildPass unless BuildPass expressly agrees otherwise in writing. BuildPass may introduce Customer-owned Sender IDs in the future, subject to approval, provider requirements, registration requirements, additional terms and applicable fees.

10. Message categories

10.1 Non-Critical Messages

10.1.1 Non-Critical Messages include:

  1. general Project updates;
  2. delivery notifications;
  3. scheduling and roster information;
  4. workflow notifications;
  5. routine sign-on or attendance reminders;
  6. routine induction or permit reminders;
  7. overdue-document reminders;
  8. routine compliance notifications;
  9. routine health and safety information;
  10. site-access information; and
  11. other ordinary operational communications.

10.1.2 Non-Critical Messages are subject to applicable Workflow Opt-Outs, Suppression Records and other messaging preferences administered by BuildPass.

10.1.3 The fact that a Message concerns compliance, safety, induction, permits, site access or site operations does not make it an Emergency Message.

10.1.4 A compliance or safety Message sent through a Workflow, broadcast, general SMS feature or other non-Emergency Module feature is a Non-Critical Message.

10.2 Emergency Module

10.2.1 An Emergency Message is only a Customer Message created and sent through the Emergency Module.

10.2.2 The Emergency Module may be available to Users with access to the relevant functionality. The Customer is responsible for ensuring that Users only use the Emergency Module for genuine emergency, safety or security communications and that Users are appropriately authorised and trained.

10.2.3 BuildPass may introduce additional Emergency Module permissions, confirmations, warnings, audit requirements, usage restrictions or approval controls at any time.

10.2.4 The Customer and its Users must not use the Emergency Module for ordinary roster or scheduling changes, general Project updates, routine delivery notices, overdue-document reminders, routine sign-on or attendance reminders, routine induction or permit reminders, ordinary site delays, general announcements, marketing or promotional content, or any other routine operational communication.

10.2.5 A Workflow Opt-Out ordinarily does not apply to an Emergency Message. BuildPass may nevertheless suppress, restrict, delay or refuse an Emergency Message where BuildPass reasonably considers this necessary because of applicable law, provider requirements, security requirements, recipient-protection requirements, recipient eligibility, a broader do-not-contact request, a suspected misuse of the Emergency Module, or these SMS Terms.

10.2.6 The Customer must not rely on an Emergency Message or the Messaging Services as the sole means of communicating an emergency, evacuation, serious safety incident, immediate site closure, threat to life, health, safety or security, or another time-critical instruction.

10.3 Essential Security Messages

10.3.1 Essential Security Messages may only be generated through Essential Security Functionality.

10.3.2 An Essential Security Message may be sent notwithstanding a Workflow Opt-Out where the Message:

  1. is reasonably necessary for authentication, identity verification, fraud prevention or account security;
  2. is triggered by a genuine authentication, verification or security event;
  3. contains only information reasonably necessary for that purpose; and
  4. contains no marketing, promotional, Project-update or unrelated operational content.

10.3.3 Essential Security Functionality must not be used to send:

  1. free-form Customer Messages;
  2. Project updates;
  3. operational broadcasts;
  4. compliance reminders;
  5. Emergency Messages; or
  6. marketing or promotional content.

10.3.4 A Customer or User must not use, imitate or attempt to access Essential Security Functionality for the purpose of avoiding a Workflow Opt-Out or Suppression Record.

10.3.5 BuildPass may suppress, delay or refuse an Essential Security Message where:

  1. the telephone number is invalid, inactive or blocked;
  2. BuildPass reasonably believes that the number has been reassigned;
  3. the request appears fraudulent, abusive or automated;
  4. a security limit has been exceeded;
  5. a provider restriction applies; or
  6. BuildPass otherwise reasonably considers suppression necessary to protect the relevant account or Recipient.

10.3.6 BuildPass does not guarantee that an Essential Security Message will be delivered or received.

10.3.7 BuildPass may require a Recipient to use another authentication or account-recovery method where an Essential Security Message cannot be delivered.

10.4 Classification does not determine legal status

10.4.1 A category selected or displayed in BuildPass does not determine the legal status of a Message.

10.4.2 The content, purpose, presentation, links, audience and surrounding circumstances of a Message determine which Applicable Messaging Requirements apply.

10.4.3 Selecting a message category does not:

  1. make an unlawful Message lawful;
  2. create consent;
  3. make an unsubscribe request inapplicable;
  4. make a Message exempt from the Spam Act;
  5. establish that a Message is an emergency communication; or
  6. transfer responsibility from the Customer to BuildPass.

10.4.4 BuildPass may reject, reclassify or require changes to a Message where BuildPass reasonably considers that the selected category is inaccurate or inappropriate.

11. Workflows and automated Messages

11.1 The Customer is responsible for the creation, configuration, testing, monitoring and ongoing operation of each Workflow.

11.2 Before activating a Workflow, the Customer must confirm:

  1. the permitted purpose of the Workflow;
  2. the intended message category;
  3. the content of each Message;
  4. the criteria used to select Recipients;
  5. the timing and frequency of Messages;
  6. how Workflow Opt-Outs and Suppression Records will be applied by the functionality then available in BuildPass; and
  7. that the Workflow complies with these SMS Terms.

11.3 Recipient eligibility and applicable Suppression Records may be assessed when a Workflow is created, configured, updated or processed, depending on the functionality available for that Workflow.

11.4 Unless BuildPass makes runtime suppression available for the relevant Workflow, the Customer is responsible for reviewing, updating or recreating Workflows to ensure that recipient selections remain current and appropriate.

11.5 A Recipient's eligibility when a Workflow is created does not establish that the Recipient remains eligible for every future Message generated by that Workflow.

11.6 The Customer must regularly review active Workflows and promptly disable or update a Workflow where:

  1. its purpose is no longer current;
  2. its recipient criteria are no longer accurate;
  3. the Project has ended or materially changed;
  4. the Workflow is sending Messages to irrelevant or inactive Recipients;
  5. complaints or opt-outs indicate that the Workflow is no longer appropriate; or
  6. the Workflow may no longer comply with these SMS Terms.

11.7 BuildPass may suspend or disable a Workflow without suspending the remainder of the Customer's Account.

12. Commercial Electronic Messages

12.1 The Customer must not send a Commercial Electronic Message through the Messaging Services unless BuildPass has expressly authorised that use in writing under separate or additional terms.

12.2 Where BuildPass has given express written authorisation, the Customer must ensure that each Commercial Electronic Message:

  1. is sent with all consent required by law;
  2. accurately identifies the individual or organisation that authorised it;
  3. includes accurate and functional contact information;
  4. contains a clear, conspicuous and functional unsubscribe facility;
  5. presents unsubscribe instructions clearly;
  6. does not require the Recipient to pay a fee to unsubscribe;
  7. does not impose more than the ordinary cost of using the relevant communication method;
  8. does not require the Recipient to create an account or sign into an account;
  9. does not require the Recipient to provide unnecessary personal information;
  10. remains functional for the period required by law;
  11. honours an unsubscribe request within the period required by law;
  12. is not sent after consent has been withdrawn; and
  13. otherwise complies with the Applicable Messaging Requirements.

12.3 The Customer bears responsibility for demonstrating any consent, inferred consent, authority or other legal basis on which it relies.

12.4 The Customer must retain evidence showing:

  1. when and how consent was obtained;
  2. what the Recipient was told;
  3. the scope of the consent;
  4. the organisation for which consent was obtained; and
  5. whether and when consent was withdrawn.

12.5 The Customer must not use an electronic Message to request consent where sending that request would itself require consent.

12.6 BuildPass's provision of an unsubscribe tool or other compliance functionality does not transfer responsibility for compliance from the Customer to BuildPass.

13. BuildPass-managed messaging preferences and opt-outs

13.1 BuildPass provides and administers the technical functionality through which Recipients may record Workflow Opt-Outs and other messaging preferences.

13.2 Depending on the functionality made available by BuildPass, a Recipient may be able to opt out of:

  1. a particular Workflow;
  2. multiple Workflows;
  3. a category of Workflow Messages;
  4. Non-Critical Messages relating to a particular Project;
  5. Non-Critical Messages authorised by a particular Customer; or
  6. another category specified by BuildPass.

13.3 BuildPass will process and apply a valid opt-out received through functionality provided by BuildPass:

  1. as soon as reasonably practicable; and
  2. within any period required by applicable law.

13.4 At a minimum, BuildPass will apply a Workflow Opt-Out to the Workflows or message categories identified to the Recipient when the opt-out was recorded.

13.5 BuildPass may apply a Suppression Record more broadly where:

  1. the Recipient has requested a broader opt-out;
  2. the scope of the request is unclear;
  3. a broader suppression is reasonably necessary to protect the Recipient;
  4. a broader suppression is reasonably necessary to prevent misuse;
  5. a telephone number appears to have been reassigned; or
  6. applicable law or provider requirements require broader suppression.

13.6 BuildPass may apply Suppression Records within the final message-processing or sending systems, including after:

  1. a User has selected a Recipient;
  2. a User has reviewed a proposed audience;
  3. a Workflow has begun processing; or
  4. a User has selected "Agree and send" or a similar command.

13.7 BuildPass may exclude a Recipient from a Message without first obtaining the Customer's or sending User's approval.

13.8 BuildPass will use reasonable endeavours to inform the Customer or relevant Users that a Recipient has opted out or has been suppressed, including through:

  1. the BuildPass interface;
  2. the Recipient's record;
  3. a send report;
  4. a Workflow report;
  5. an activity log; or
  6. another notification method selected by BuildPass.

13.9 Information about a Workflow Opt-Out or Suppression Record may not be displayed to the Customer or a User in real time.

13.10 Without limitation:

  1. a Suppression Record may take effect before the Customer-facing interface is updated;
  2. a Recipient may be excluded after a User has reviewed or selected the proposed audience;
  3. the final recipient count may be lower than the number originally selected;
  4. BuildPass may notify the Customer of a suppression after the relevant Message or Workflow has been processed; and
  5. a User may not receive a separate notification for every suppressed Recipient.

13.11 A delay in notifying the Customer or a User does not:

  1. invalidate the Suppression Record;
  2. authorise the Customer or User to continue sending Messages;
  3. entitle the Customer or User to override the Recipient's preference; or
  4. make BuildPass responsible for the Customer's separate communications with the Recipient.

13.12 The Customer and its Users must not:

  1. remove, alter or attempt to override a Suppression Record;
  2. re-add a Recipient to a Workflow for the purpose of avoiding an opt-out;
  3. create a replacement Workflow or recipient group to contact an opted-out Recipient;
  4. use a different Project, User or Customer account to avoid an opt-out;
  5. export a Recipient's details and use another messaging service to avoid a preference known to the Customer; or
  6. instruct or encourage another person to evade a Suppression Record.

13.13 Where a Recipient communicates an opt-out or do-not-contact request directly to the Customer or a User, including verbally, by email, by telephone or through another communication channel, the Customer must:

  1. stop initiating the affected Messages;
  2. notify BuildPass or record the request using the functionality provided as soon as practicable and no later than one Business Day after receiving it;
  3. provide sufficient information for BuildPass to identify the Recipient and the scope of the request; and
  4. retain evidence of the request and the action taken.

13.14 BuildPass's administration of opt-outs does not remove the Customer's responsibility to:

  1. ensure that its Customer Messages are lawful;
  2. provide BuildPass with opt-out requests received outside BuildPass;
  3. avoid manually contacting a Recipient contrary to a known preference;
  4. ensure that its Users comply with applicable preferences; and
  5. comply with any obligation applying directly to the Customer.

13.15 A Workflow Opt-Out ordinarily does not apply to an Essential Security Message or Emergency Message.

13.16 Despite clause 13.15, BuildPass may suppress an Essential Security Message or Emergency Message where:

  1. the Recipient has made a broader do-not-contact request;
  2. the telephone number is invalid, blocked or believed to have been reassigned;
  3. applicable law requires suppression;
  4. a provider restriction applies;
  5. the Recipient has no relevant connection with the Project or account; or
  6. BuildPass otherwise reasonably determines that the Message should not be sent.

13.17 A Recipient must not be re-subscribed to affected Non-Critical Messages unless:

  1. the Recipient subsequently takes a clear affirmative action authorising those Messages;
  2. the scope of the new authorisation is accurately recorded; and
  3. sending the Messages is otherwise lawful.

13.18 The Customer must not make agreement to receive Non-Critical Messages a condition of:

  1. accessing a Project;
  2. performing work;
  3. receiving payment;
  4. maintaining an employment or contracting relationship; or
  5. exercising another right,

unless the Customer has independently determined that the condition is lawful, reasonably necessary and proportionate.

13.19 An opt-out from BuildPass Messages:

  1. affects the Messages and categories specified by the relevant preference;
  2. does not determine a Recipient's employment, contracting or Project obligations; and
  3. does not prevent the Customer from using another lawful and appropriate communication method.

13.20 A Message that has already been submitted to a telecommunications carrier, SMS aggregator or other messaging provider before a Suppression Record takes effect may still be delivered.

13.21 BuildPass may not be able to recall or cancel a Message after it has been submitted to a third-party messaging provider.

14. Message suppression, delivery and reliance

14.1 BuildPass will use reasonable care and skill in providing the Messaging Services.

14.2 SMS delivery depends on systems, networks, messaging providers and recipient devices that are not wholly controlled by BuildPass.

14.3 To the extent permitted by law, BuildPass does not guarantee that any Message will:

  1. be accepted for sending;
  2. be submitted to a messaging provider;
  3. be transmitted without interruption or delay;
  4. be delivered to the intended Recipient;
  5. be delivered by a particular time;
  6. be displayed correctly on the Recipient's device;
  7. be received by the intended person;
  8. be opened or read;
  9. remain available on the Recipient's device; or
  10. result in the Recipient taking any action.

14.4 A Message may be suppressed, rejected, delayed, filtered, blocked, misdirected or not delivered because of:

  1. a Workflow Opt-Out;
  2. another Suppression Record;
  3. a Recipient no longer being eligible or relevant to the applicable Project;
  4. BuildPass compliance, security, fraud or abuse controls;
  5. an invalid, inactive, disconnected, ported or reassigned mobile telephone number;
  6. the Recipient's device being unavailable, switched off, out of coverage, full or unable to receive the Message;
  7. the Recipient's telecommunications plan or settings;
  8. carrier, aggregator or provider filtering;
  9. Sender ID registration, verification or routing requirements;
  10. message-content or link filtering;
  11. network congestion;
  12. provider interruption or technical failure;
  13. scheduled or emergency maintenance;
  14. events outside BuildPass's reasonable control; or
  15. another legal, technical, operational or provider restriction.

14.5 Where BuildPass excludes a Recipient because of a Workflow Opt-Out or Suppression Record:

  1. the Message is treated as suppressed or not sent to that Recipient;
  2. the exclusion is not a message-delivery failure;
  3. BuildPass is not required to submit the Message to a messaging provider; and
  4. the Customer is not entitled to require BuildPass to override the Recipient's preference.

14.6 Recipient numbers displayed before sending may be estimates.

14.7 The final number of Messages submitted may differ from the number of Recipients originally selected because BuildPass may apply:

  1. Suppression Records;
  2. duplicate-number removal;
  3. recipient-eligibility controls;
  4. invalid-number controls;
  5. legal or provider restrictions; and
  6. security and abuse controls.

14.8 A delivery status such as "sent", "submitted" or "delivered" may be based on information supplied by a third-party messaging provider.

14.9 A "sent", "submitted" or "delivered" status does not prove that:

  1. the intended Recipient personally received the Message;
  2. the intended Recipient opened or read the Message;
  3. the relevant mobile telephone number still belongs to the intended Recipient;
  4. the Message was displayed correctly; or
  5. the Recipient acted on the Message.

14.10 The Customer must maintain appropriate alternative communication procedures for:

  1. emergencies;
  2. evacuations;
  3. serious safety incidents;
  4. immediate site closures;
  5. critical site-access instructions;
  6. legal or regulatory notices;
  7. time-critical operational instructions; and
  8. any matter where failure or delay in receiving an SMS could cause material harm.

14.11 The Customer must not represent to a Recipient, worker, regulator or any other person that BuildPass guarantees SMS transmission, delivery, receipt or reading.

14.12 Nothing in this clause excludes, restricts or modifies any guarantee, right, remedy or liability that cannot lawfully be excluded, restricted or modified.

15. BuildPass compliance controls

15.1 To the extent permitted by law and as described in the BuildPass Privacy Policy, BuildPass may review and process:

  1. Message content;
  2. links contained in Messages;
  3. recipient and sender information;
  4. telephone numbers;
  5. recipient counts and selection criteria;
  6. Workflow configurations;
  7. message-category selections;
  8. delivery and failure information;
  9. Workflow Opt-Outs and Suppression Records;
  10. complaint information;
  11. acceptance and attestation records; and
  12. messaging patterns and usage information.

15.2 BuildPass may undertake that processing for:

  1. legal and regulatory compliance;
  2. security and fraud prevention;
  3. spam and abuse prevention;
  4. enforcement of these SMS Terms;
  5. provider compliance;
  6. Sender ID registration and protection;
  7. message deliverability;
  8. complaint investigation;
  9. operation and improvement of the Messaging Services; and
  10. protection of BuildPass, Customers, Users and Recipients.

15.3 BuildPass may use automated and manual controls to:

  1. warn a User about potentially stale, excessive or irrelevant recipient lists;
  2. display inactivity information;
  3. require confirmation of the purpose or category of a Message;
  4. require an additional representation or attestation;
  5. require evidence of recipient eligibility, consent or authority;
  6. require a Customer to complete remediation or training;
  7. prepend or append Customer identification;
  8. prepend or append Project identification;
  9. add or require opt-out information;
  10. add or require compliance notices;
  11. reformat a Message for delivery or compliance purposes;
  12. block prohibited words, content, links or recipient selections;
  13. reject, delay, throttle or cancel a Message;
  14. disable a Workflow;
  15. apply a Suppression Record;
  16. block a Recipient from further Non-Critical Messages;
  17. change the Sender ID or delivery route; or
  18. suspend or disable the Messaging Services.

15.4 BuildPass may require the Customer to modify a Customer Message before it is sent.

15.5 BuildPass is not required to monitor, review or approve every Message.

15.6 BuildPass does not assume responsibility for a Customer Message merely because BuildPass:

  1. did not detect a breach;
  2. did not prevent the Message from being sent;
  3. provided a template or category;
  4. appended compliance information; or
  5. provided the infrastructure through which the Message was sent.

16. Records, complaints and cooperation

16.1 The Customer must maintain sufficient records to demonstrate compliance with these SMS Terms and the Applicable Messaging Requirements.

16.2 Relevant records may include:

  1. Message content and links;
  2. the date and time of sending;
  3. the sending Customer and User;
  4. the relevant Project;
  5. the selected message category;
  6. the proposed and final recipient lists;
  7. the basis on which Recipients were selected;
  8. evidence of each Recipient's current Project connection;
  9. evidence of consent, authority or another lawful basis;
  10. Workflow configurations and versions;
  11. Workflow Opt-Outs and other requests received directly by the Customer;
  12. actions taken in response to opt-outs;
  13. complaints and responses;
  14. the circumstances supporting use of the Emergency Module; and
  15. any acceptance, attestation or confirmation made by the User.

16.3 The Customer must retain those records for:

  1. the period required by applicable law; and
  2. any longer reasonable period notified by BuildPass where a complaint, investigation or dispute is ongoing.

16.4 The Customer must promptly provide relevant records to BuildPass on reasonable request.

16.5 BuildPass may record and retain:

  1. the identity of an accepting or sending User;
  2. the Customer and Project;
  3. the version of these SMS Terms accepted;
  4. acceptance and sending timestamps;
  5. Message content and metadata;
  6. original and final recipient counts;
  7. excluded or suppressed Recipients;
  8. message classifications;
  9. Sender ID and provider information;
  10. delivery, failure and suppression information;
  11. Workflow information;
  12. opt-out and complaint information; and
  13. Emergency Module justifications.

16.6 The Customer must notify BuildPass promptly if it becomes aware of:

  1. a complaint that a Customer Message was unsolicited, misleading, irrelevant, excessive or abusive;
  2. a Message sent after an opt-out;
  3. use of an incorrect or unauthorised recipient list;
  4. a Message sent to materially stale or irrelevant Recipients;
  5. misuse of the Emergency Module;
  6. misuse of Essential Security Functionality;
  7. unauthorised use of a Sender ID;
  8. a request, notice or investigation from ACMA, a telecommunications carrier, a messaging provider or another regulator; or
  9. an actual or suspected breach of these SMS Terms.

16.7 The Customer must cooperate with BuildPass in investigating and remediating any:

  1. complaint;
  2. suspected breach;
  3. provider request;
  4. delivery issue;
  5. Sender ID issue; or
  6. regulatory investigation.

16.8 BuildPass may communicate directly with a Recipient, messaging provider or regulator where reasonably necessary to:

  1. investigate a complaint;
  2. clarify an opt-out;
  3. give effect to a Suppression Record;
  4. prevent further Messages;
  5. investigate misuse or fraud;
  6. satisfy a legal or provider requirement; or
  7. protect BuildPass, Recipients or the Messaging Services.

16.9 BuildPass may disclose Message records and related information where:

  1. required or permitted by law;
  2. required by a court, tribunal or regulator;
  3. reasonably required by a telecommunications carrier, SMS aggregator or messaging provider to investigate unlawful, abusive, fraudulent or non-compliant activity; or
  4. reasonably necessary to establish, exercise or defend legal rights.

17. Restriction, suspension and disabling of Messaging Services

17.1 BuildPass may immediately investigate, restrict, throttle, suspend or disable all or part of the Messaging Services for a User, Project or Customer where BuildPass reasonably believes that:

  1. these SMS Terms have been breached;
  2. a Message may breach applicable law;
  3. a Customer or User has sent marketing or promotional content;
  4. Messages have been sent to materially stale, irrelevant or excessive recipient lists;
  5. the Customer or a User has failed to honour an opt-out;
  6. a Suppression Record has been overridden or circumvented;
  7. the Emergency Module has been misused;
  8. Essential Security Functionality has been misused;
  9. a Sender ID has been misused;
  10. a Message, recipient list or Workflow creates a legal, regulatory, security, fraud, reputational, operational or deliverability risk;
  11. BuildPass has received a material number or pattern of complaints;
  12. the Customer has failed to provide requested evidence or information;
  13. a carrier, messaging provider or regulator has requested or required the restriction;
  14. continued access may harm the Messaging Services or other customers; or
  15. immediate action is reasonably necessary to protect Recipients or BuildPass.

17.2 BuildPass may take action under clause 17.1 in relation to:

  1. a particular Message;
  2. a particular Recipient;
  3. a recipient group;
  4. a particular Workflow;
  5. a particular User;
  6. a particular Project;
  7. all Workflows;
  8. the Emergency Module;
  9. the general SMS module;
  10. all Messaging Services; or
  11. the entire Customer Account where permitted under the Terms of Service.

17.3 BuildPass may disable the entire Messaging Services module for a Customer where there is:

  1. a serious breach;
  2. a repeated breach;
  3. a reckless or deliberate breach;
  4. systemic misuse;
  5. a failure to address earlier warnings or remediation requirements; or
  6. a material risk to BuildPass, its providers or Recipients.

17.4 BuildPass may act without prior notice where:

  1. immediate action is reasonably necessary;
  2. prior notice may increase the risk of further misuse;
  3. a provider or regulator requires immediate action; or
  4. BuildPass reasonably considers that prior notice is not practicable.

17.5 Where reasonably practicable, BuildPass will notify the Customer of a material restriction or suspension and identify any remediation required.

17.6 Reinstatement may be conditional on the Customer:

  1. removing or correcting recipient data;
  2. demonstrating the source and relevance of a recipient list;
  3. addressing complaints and opt-outs;
  4. modifying or disabling a Workflow;
  5. restricting User permissions;
  6. completing compliance training;
  7. providing a written assurance;
  8. providing evidence of consent, authority or lawful purpose;
  9. implementing additional controls; or
  10. completing another reasonable remedial measure specified by BuildPass.

17.7 BuildPass is not required to reinstate the Messaging Services where BuildPass reasonably considers that the relevant risk has not been adequately addressed.

17.8 Conduct that breaches these SMS Terms may also constitute a breach of the BuildPass Terms of Service and may result in suspension or termination of the relevant Account.

17.9 Subject to rights and liabilities that cannot lawfully be excluded, BuildPass is not liable for a Message being rejected, delayed, suppressed, rerouted or not delivered as a result of BuildPass reasonably exercising its rights under these SMS Terms.

18. Personal information and Message data

18.1 The Customer must ensure that it has a lawful basis to collect, use and disclose each Recipient's:

  1. name;
  2. mobile telephone number;
  3. Project relationship;
  4. communication preferences; and
  5. other personal information used in connection with the Messaging Services.

18.2 The Customer must provide any privacy notice and obtain any consent required in connection with its collection and use of Recipient information.

18.3 The Customer authorises BuildPass and its messaging providers to process:

  1. Customer Messages;
  2. Recipient telephone numbers;
  3. sender and Project information;
  4. Workflow information;
  5. delivery records;
  6. messaging preferences;
  7. Suppression Records;
  8. complaints; and
  9. related information,

for the purposes described in these SMS Terms, the BuildPass Terms of Service and the BuildPass Privacy Policy.

18.4 The Customer acknowledges that BuildPass may disclose relevant information to telecommunications carriers, SMS aggregators, messaging providers, regulators and professional advisers where reasonably necessary to provide the Messaging Services, comply with law, investigate complaints or enforce these SMS Terms.

18.5 The Customer and its Users must not include personal or sensitive information in a Customer Message beyond what is reasonably necessary for the permitted purpose.

18.6 In particular, the Customer should not include complete copies of:

  1. government identification numbers;
  2. financial account information;
  3. medical information;
  4. security credentials;
  5. passwords;
  6. one-time passcodes unrelated to Essential Security Functionality; or
  7. other information that may cause material harm if viewed by the wrong person.

18.7 The Customer acknowledges that a mobile telephone number may be shared, transferred, ported or reassigned and that SMS should not be treated as a secure or identity-verified communication channel unless BuildPass expressly indicates otherwise.

19. Indemnity

19.1 Without limiting any indemnity in the BuildPass Terms of Service, and to the extent permitted by law, the Customer indemnifies BuildPass and its officers, employees, contractors and agents against third-party claims, provider charges, reasonable investigation costs, reasonable legal costs and any regulatory loss or penalty that is lawfully recoverable from the Customer, to the extent arising from:

  1. a breach of these SMS Terms by the Customer or its Users;
  2. an unlawful, misleading, unauthorised or prohibited Customer Message;
  3. the content of a Customer Message;
  4. the Customer's recipient selection;
  5. the use of a stale, incorrect or unauthorised recipient list;
  6. failure to obtain or retain required consent, permission or authority;
  7. failure to honour or communicate an opt-out;
  8. circumvention of a Suppression Record;
  9. misuse of a BuildPass Sender ID;
  10. misuse of the Emergency Module;
  11. misuse of Essential Security Functionality;
  12. a breach of privacy or confidentiality caused by information included in a Customer Message; or
  13. inaccurate or incomplete information or instructions supplied by the Customer.

19.2 The indemnity in clause 19.1 does not apply to the extent that the relevant loss was caused by BuildPass's:

  1. breach of law;
  2. breach of contract;
  3. negligence;
  4. fraud; or
  5. wilful misconduct.

19.3 Nothing in this clause requires the Customer to indemnify BuildPass for a liability that cannot lawfully be indemnified.

20. Changes to these SMS Terms

20.1 BuildPass may amend these SMS Terms where reasonably necessary to respond to:

  1. a change in law or regulatory guidance;
  2. a carrier or messaging-provider requirement;
  3. a Sender ID requirement;
  4. a security, fraud or abuse risk;
  5. a new or changed Messaging Service;
  6. an identified compliance issue; or
  7. a change to BuildPass's operational or technical processes.

20.2 BuildPass will give reasonable notice of a material change where reasonably practicable.

20.3 A change may take effect immediately where:

  1. required by law;
  2. required by a regulator or messaging provider;
  3. necessary to address an urgent security, fraud or abuse risk; or
  4. delay could expose BuildPass, a Customer or a Recipient to material harm.

20.4 BuildPass may require the Customer, an Administrator or a sending User to accept the amended SMS Terms before continuing to use the Messaging Services.

20.5 Continued use of the Messaging Services after amended SMS Terms take effect constitutes acceptance of those amended SMS Terms to the extent permitted by law.

21. General

21.1 A failure or delay by BuildPass to exercise a right under these SMS Terms does not waive that right.

21.2 A waiver is only effective if given in writing by BuildPass.

21.3 If any provision of these SMS Terms is invalid or unenforceable, it is to be read down to the minimum extent necessary or, if it cannot be read down, severed without affecting the remaining provisions.

21.4 Headings are for convenience only and do not affect interpretation.

21.5 The words "including", "includes" and similar expressions do not limit what else may be included.

21.6 A reference to legislation includes that legislation as amended, re-enacted or replaced and includes subordinate instruments made under it.

21.7 These SMS Terms are governed by the laws specified in the BuildPass Terms of Service.

22. Contact

Questions, complaints, opt-out issues or suspected misuse of the Messaging Services should be reported to:

BuildPass Pty Ltd
ACN 652 324 635
Support: support@buildpass.com.au
Privacy enquiries: privacy@buildpass.com.au