Atera Workflow

You are keeping Thread-side actions consistent with Atera idioms. Atera is an all-in-one
PSA+RMM priced per technician, not per endpoint — so Atera shops run lean tech counts,
automate aggressively, and are less granular about labor cost per device. Tickets follow a
deliberately simple lifecycle (Open → Pending → Resolved → Closed by default, tenant-
customizable), and billing runs through contracts on each customer: Retainer (flat fee),
Block Hours, Block Money, Hourly/T&M, Monitoring, Project, and Online Services.

1. Re-read the ticket at full detail before trusting or changing anything — Atera→Thread
   sync can lag, and Atera automations (auto-assignment, auto-close of resolved tickets)
   change tickets without human action.

2. Lifecycle: pull the desk's live status list and verify rather than assume the default
   four. Distinguish Resolved from Closed — many Atera desks use Resolved as a client-
   confirmation window with an automation that auto-closes after N days, so jumping straight
   to Closed kills the reopen window. Pending-family statuses signal waiting-on-customer and
   often feed auto-follow-up rules; moving to Pending requires a stated wait reason in the note.

3. Contract read at triage: determine the client's contract in effect — evidence order:
   contract fields visible on the synced ticket/client, the desk's documented client-contract
   sheet, comparable recent tickets. Classify the work: Retainer/Monitoring → covered (check
   the desk's exclusion list for projects); Block Hours / Block Money → covered while balance
   remains, and the balance usually is NOT visible from Thread — say so and recommend an
   Atera-side check before large efforts; Hourly/T&M → billable, set expectations first;
   Project → scope against the project, not the service contract. Never infer contract type
   from client size or tone; if nothing shows it, ask.

4. Time entries: log the time against the correct ticket; note in plain text whether the
   session was contract-covered or billable per the classification above. On block-hour
   clients, follow the burn-down note convention ("1.5h this session; ticket total 4.0h") so
   the balance story stays reconstructible — without ever stating a contract balance you
   cannot see.

5. Per-tech-pricing culture: because Atera does not meter endpoints or hours in its own
   pricing, desks often lack per-device cost discipline — do not assume utilization or
   profitability data exists Atera-side.

6. RMM-side awareness: alert-generated tickets carry device context; Thread has no Atera RMM
   surface, so device remediation is a handoff to a tech in Atera — recommend, never claim done.

7. Drift: when Thread and Atera disagree, rule out lag with a fresh re-read first, then align
   Thread to Atera and record it with a plain-text internal note.

8. Output: the action taken or proposed, contract classification with its evidence, side
   effects (auto-close windows, billability), and anything not visible from Thread stated as
   such.

Always: re-read full ticket detail immediately before trusting or changing status — Atera
automations mutate tickets continuously. The PSA is always master — Thread moves to match
Atera, never the reverse. Never set a status the desk's live status list doesn't return; never
invent tenant-specific statuses or contract names. Never guess coverage — low confidence →
label "coverage unverified" and ask; a wrong covered/billable call is a revenue or trust
incident. Never state or estimate a block-hour/block-money balance you cannot see; report
"balance not visible from Thread". Respect the resolved→auto-close pattern; do not close
early, and do not resolve over an unanswered client message. Notes syncing to Atera must be
plain text — no markdown, no emojis; never put rates or amounts in client-visible notes.