HaloPSA — run the service desk end to end

draft

Using HaloPSA as the MSP PSA for tickets, problems, projects, quotes, and invoicing through to Xero — so service delivery and commercial work live in one system.

Audiences: customer, ae, tech · Tags: psa, service-desk, halopsa, ticketing, projects, quoting, invoicing · Last verified: 2026-07-25

Teach module

# Teach — HaloPSA for MSP service delivery

## Core truths

- HaloPSA is the PSA: it is where the MSP runs service desk tickets, related problems, projects, sales quotes, and invoicing (including invoices through to Xero).
- Tickets are the unit of reactive work: every client request should be logged, owned, prioritised, and closed with a clear trail — not handled only in chat or email.
- Problems link recurring or underlying issues across tickets so the team fixes the cause, not just each symptom as a one-off.
- Projects are for planned work (onboarding, migrations, scoped changes) with tasks, ownership, and progress separate from day-to-day ticket noise.
- Quotes capture agreed commercial scope before delivery; invoicing turns delivered or billed work into invoices that can flow to Xero for finance.
- One PSA beats a patchwork of spreadsheets, email threads, and disconnected tools: status, ownership, and billing context stay visible in one place.

## Common myths to correct

- "Email and chat are fine for support" — without tickets you lose SLA visibility, ownership, history, and a clean path to billable work.
- "Projects are just long tickets" — projects need structure, milestones, and commercial scope; stuffing them into the ticket queue hides progress and overruns.
- "Quoting and invoicing belong only in finance tools" — the PSA connects what was sold and delivered to what gets invoiced; Xero handles the accounting side once invoices are raised.
- "Problem records are optional paperwork" — without problems, the same incident pattern keeps generating tickets and burning engineer time.

## Pitfalls

- Leaving work in email or Teams instead of logging a ticket, so nothing is queued, measured, or handed over cleanly.
- Closing repeat tickets without raising or linking a problem, so root cause never gets owned.
- Running project work only in the ticket board, with no project plan, so scope and deadlines drift.
- Raising invoices without a clear quote or logged delivery context, which creates finance disputes and rework.
- Assuming every HaloPSA–Xero behaviour is identical in every tenant — confirm local config before promising automation detail in a live session.

Apply module

# Apply — discovery, objections, and talk tracks

## Discovery questions

- Where does a client request live today from first contact to resolution — ticket system, email, chat, or a mix?
- When the same issue hits three users in a week, how do you track that it is one underlying problem rather than three unrelated tickets?
- How do you separate break/fix tickets from planned project work so neither queue buries the other?
- How does a scoped piece of work go from conversation to quote to delivery to invoice today?
- Who can see, at a glance, what is open for a client across tickets, projects, and outstanding commercial items?
- When finance asks "what are we billing this month?", how long does it take to answer from the tools you use now?

## Objections and responses

- "We already manage support in email and spreadsheets." — That works until handover, holiday cover, or a billing dispute; ask who owns status when the person in the thread is offline.
- "Another system for the team to learn." — The PSA replaces fragmented queues and side lists; the learning curve buys one place for tickets, projects, quotes, and invoices.
- "We have a ticketing tool already." — Ticketing alone often stops at the service desk; ask how projects, quotes, and invoicing connect to that tool today.
- "Finance already uses Xero — we do not need the PSA for billing." — Xero remains the accounts system; the PSA is where delivery and quotes become invoices that can go through to Xero with context.
- "Our clients are all different, so one process will not fit." — Ticket, problem, project, and quote stages stay the same; client-specific detail lives on the record, not in a parallel undocumented process.

## Talk tracks

- "One system from ticket to invoice" — frames HaloPSA as the spine of service and commercial delivery, not just a helpdesk.
- For customers: emphasise visibility — they get clearer ownership and status because work is logged and progressed in a proper service desk, not lost in inboxes.
- For AEs: sell the outcome (reliable delivery plus a clean path from quote to invoice), not feature lists; HaloPSA is how the MSP keeps that promise.
- For tech: lead with queue hygiene — tickets for reactive work, problems for root cause, projects for planned delivery — so engineers stop firefighting the same issue twice.

Convert module

# Convert — CTAs and next steps

## Approved CTAs

- Book a service-desk walkthrough: we show how a ticket, problem, project, quote, and invoice flow through HaloPSA for one of your typical client scenarios.
- Offer a process mapping session: map how requests and projects move today, then highlight where a PSA removes handoffs and blind spots.
- For internal enablement: assign each engineer one open ticket and one project task to update in HaloPSA this week using the agreed statuses.
- Invite a follow-up with service desk and finance together to confirm how invoicing through to Xero should look for your billing cycle.

## Next-step framing

- Customer webinars: end on the walkthrough offer, positioned as a practical look at how support and projects stay visible — low commitment, no tool dump.
- AE sessions: the goal is booking the process mapping or walkthrough conversation, not closing a PSA licence discussion in the room.
- Tech sessions: the next step is practising the ticket → problem → project discipline on real work in a sandbox or non-critical queue before changing client-facing process.

Demo steps

# Demo — tickets, problems, projects, quotes, and invoicing in HaloPSA

1. Open HaloPSA and show the service desk ticket list (queue, status, and client context).
2. Open an existing ticket (or create one) and walk through assignment, status update, and a short work note so the audience sees ownership and history.
3. From a recurring or related scenario, raise a problem ticket and link it to the relevant ticket(s) to show root-cause tracking beyond one-off incidents.
4. Switch to the projects module and open a sample project; show tasks, ownership, and how project work sits apart from the reactive ticket queue.
5. Raise a quote for a scoped piece of work (or open a prepared quote) and highlight client, line items, and that commercial intent is captured before delivery.
6. Show how delivered or billable work connects to invoicing — raise or open an invoice tied to the work just demonstrated.
7. Show the invoice path through to Xero at a high level (status or sync view as configured in the demo tenant) without promising automation detail beyond what is on screen.
8. Return to the ticket or project list and close the loop: status updated, problem linked if relevant, and commercial record visible so nothing lives only in chat.

## Pre-demo checklist

- Demo tenant or sandbox confirmed safe to create tickets, problems, quotes, and invoices.
- Sample client, ticket, problem, and project records prepared so the session does not rely on live production data.
- Quote and invoice demo data ready (or a clear script to create them quickly) with non-sensitive amounts.
- Xero connection or invoice-to-Xero path verified in this environment — if not configured, say so and demo invoicing inside HaloPSA only.
- Screen sharing hides real client names, emails, and financial detail where the audience is external.

Claims policy

# Claims — HaloPSA

## Allowed claims

- HaloPSA is a PSA used to run MSP service desk tickets, problems, projects, quotes, and invoicing.
- Tickets provide a logged, owned trail for reactive support work.
- Problem records help track underlying or recurring issues across related tickets.
- The projects module supports planned work separately from the day-to-day ticket queue.
- Quotes capture scoped commercial offers before or alongside delivery.
- Invoices can be raised in HaloPSA and sent through to Xero for accounting.
- Centralising tickets, projects, and commercial records in one PSA reduces reliance on email and spreadsheets for status and handover.

## Forbidden / needs-human-review claims

- Any specific pricing, licensing tiers, seat counts, or discount figures.
- Any guaranteed time savings, revenue uplift, or ROI percentage.
- Any claim that HaloPSA alone makes the MSP compliant with a named standard or certification.
- Guarantees about Xero sync behaviour, timing, tax mapping, or multi-currency handling beyond "invoices through to Xero" as configured for that MSP.
- Claims about specific HaloPSA modules, automations, SLAs, or integrations not verified for the demo tenant.
- Comparisons naming competing PSA products (for example ConnectWise, Autotask, or others) unless explicitly approved.
- Promises that every client process will fit HaloPSA without configuration or change management.