> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcsolar.com.au/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> ## What this documentation covers
> This is the documentation for ArcSolar, the solar-retailer operating system: the web app a solar retailer uses to run quoting, sales, installation, rebates, inventory and reporting. ArcSolar is a hosted web application at https://app.arcsolar.com.au. There is no public API for most workflows, so agentic operation of ArcSolar is UI-driven. Navigate the app, read the labels and controls, and act through the interface, unless a page explicitly documents an API, contract or integration endpoint.
>
> ## How to read these pages
> - Pages are split by audience using Mintlify's Visibility component, and this split is deliberate. Sections marked 'for agents' are hidden on the website and appear only in the Markdown you are reading. They are the authoritative behavioural specification for the page. Where the remaining human-facing prose and an agent section disagree, the agent section is correct.
> - Sections outside any Visibility block appear in both outputs. They are the shared spine of the page: what the feature is and why it matters.
> - Treat every bold label, field name, route, status string and error message quoted in an agent section as canonical. They are copied verbatim from the product. Use that exact wording when telling a user where to click, or when matching an error message to its cause.
> - Australian solar vocabulary is used precisely and not interchangeably: STC (Small-scale Technology Certificate), PRC (Peak Reduction Certificate), REPS, NMI, CEC accreditation, VPP. Do not substitute an overseas equivalent.
> - Money is Australian dollars. Dates shown to users are day-first (DD/MM/YYYY).
>
> ## Behaviour rules for operating or advising on ArcSolar
> - Respect prerequisites and ordering. Agent sections state which inputs block progress and which steps must happen first. Do not skip a step, and do not assume a default that the product itself does not supply.
> - Never invent a value the product requires but the user has not supplied. Ask for mandatory fields rather than guessing. Several features reject a request outright when one is missing, and submissions to external authorities are effectively irreversible.
> - Respect permissions and scoping. Features name the roles, capabilities and access rules that may act. Do not attempt an action the operator's role cannot perform, and do not describe a restricted feature as available to them.
> - Features that are gated, pending release, or blocked on a vendor are documented as exactly that. Never present a gated or unmerged behaviour as live. When availability is unclear for a given workspace, direct the user to support rather than asserting that the feature works.
> - Where a page states something is genuinely undetermined, treat it as unknown. Do not fill the gap with a plausible guess.
> - ArcSolar's built-in assistant is called ArgonixIntelligence. Pages end with an 'ArgonixIntelligence in this workflow' section stating what intelligence can and cannot reason from in that workflow. Treat those limits as binding: intelligence does not replace provider approval, verified evidence, or a customer's own confirmation, and it must not be presented as if it does.
>
> ## Getting help
> Support is support@arcsolar.com.au. The customer-facing website is https://www.arcsolar.com.au.

# Set up and maintain sales availability

> Set onsite and remote hours, block time off, and keep booking readiness current.

Sales availability tells ArcSolar when you can accept onsite and phone/video consultations. Your calendar's busy appointments, holidays and subscribed busy time further restrict those hours.

**Open:** [**Availability**](https://app.arcsolar.com.au/dashboard/sales-availability), **Calendar → My availability**, or [**Profile Settings → Availability**](https://app.arcsolar.com.au/dashboard/profile-settings?tab=availability). These self-service settings are available to Sales reps.

## Complete first sign-in setup

Before initial CRM access, confirm your availability in the setup step. Account setup, sign-out and recovery remain available while you complete it.

1. Choose the timezone in which your weekly hours should repeat.
2. Review **Onsite appointments** and **Phone or video appointments** separately.
3. Use **Add period** for each available day and enter the start and end times. Add another period if you have a break or split shift.
4. Review the weekly preview. Suggested weekday hours must be checked against your actual schedule.
5. Select the confirmation checkbox and **Save and confirm**.

**Save draft** keeps work in progress; it does not replace the required confirmation. You can deliberately confirm an empty schedule when you are unavailable for both channels. That completes initial setup while leaving you unavailable for automatic bookings.

## Keep availability current

Confirm your schedule every **28 days**, even when the hours remain the same. Update the periods before confirming if your working pattern changes.

An overdue review pauses automatic bookings. You keep CRM access and existing appointments. Saving new availability does not silently move appointments that were already booked.

Changing the weekly availability timezone requires a review of future appointments and explicit reconfirmation. Merely changing the calendar's display timezone does not change appointment times.

## Record holidays and other commitments

Use busy time blocks in [Calendar](/delivery/calendar#block-holidays-and-busy-time) for leave, holidays, travel and one-off commitments. Recurring weekly hours describe when you are generally free; busy blocks remove specific times from that schedule.

Check existing appointments before taking time off. Resolve a conflict explicitly with the responsible manager rather than expecting a time block to cancel it.

## Adjust appointment buffers

The **Booking buffers** controls let you adjust your channel defaults within the manager's minimums. Phone/video defaults are 10 minutes; in-person defaults are 30 minutes. Existing saved policies retain their values.

Between adjacent appointments, the larger requirement applies once. Verified travel can require a longer interval. An authorized manual exception records its reason, but cannot bypass actual busy time, leave or manager minimums.

## Connect a subscribed busy calendar

Open **Incoming calendars**, enter a calendar name and HTTPS or webcal feed URL, and choose the feed timezone. Mark a calendar as required when it must be checked before automatic bookings.

Only busy intervals are imported. Authorized calendar views show **External busy**, with no personal event title or contents. Saved feed URLs are encrypted and are not returned to the calendar.

Feeds refresh every five minutes. A required feed becomes unavailable after ten minutes without successful validation, and booking checks refresh snapshots older than one minute. Publisher delays can still apply. Fix failed feeds or use **Refresh busy time**; a failed refresh does not erase the last busy snapshot.

See [calendar subscriptions](/delivery/calendar#subscribe-and-import-calendars) for the separate outgoing ArcSolar subscription and one-time download.

## Check notification readiness

Keep your private notification mobile current in **Profile Settings → Profile**, and review your notification preferences. Appointment SMS for you goes to that mobile, rather than back to the sending work number. Your authorized work line and work email identify you to the customer.

Managers review sender and destination readiness in **Booking settings**. Missing contacts, unavailable senders, opt-outs and delivery failures need follow-up; availability confirmation alone does not resolve them.

## What your manager controls

Managers approve service-area postcodes, channel eligibility, minimum buffers and automatic booking enablement. They also enable appointment messaging for the workspace. You cannot enable your own automation policy.

An assigned customer stays with their rep unless authorized staff explicitly change ownership. For unassigned leads, the booking service chooses among approved, available reps and assigns the customer only after a successful booking.

## ArgonixIntelligence in this workflow

Intelligence can use confirmed availability and current booking constraints to prepare options. It cannot confirm your hours, invent a travel origin, grant booking eligibility or override a conflict. Voice appointment setting remains a separate rollout.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.