← SOP Library

Technical SOPs

SOP — New-Customer Setup in Syncro (Organization + Email-to-Ticket)

Updated 2026-05-30

SOP — New-Customer Setup in Syncro (Organization + Email-to-Ticket)

Purpose

Stand up a newly-signed customer in Syncro (our RMM/PSA) so that:

  1. The customer exists as an Organization record with the deployment data we need, and
  2. Inbound email from anyone at the customer’s domain automatically opens a Ticket in CyberSuite’s shared support queue, and the sender gets a branded acknowledgement with their ticket number.

This is the Syncro technical procedure behind the Day 0 setup in SOP 6 — Customer Onboarding (operations-only/strategy/06-operations-sops-manual.md) and complements the customer-facing Onboarding Plan. Run once per new customer at Day 0. It does not restate the 14-day plan.

Method note: the email-to-ticket mechanism below is CyberSuite’s validated pattern — a per-customer Email Rule keyed on the customer’s domain, routed to our support mailbox, with a branded auto-acknowledgement. Vendor-documented mechanics carry a citation; CyberSuite conventions are stated as ours.

Open one-time setup (platform-wide — not yet built; do before the first live customer)

These are set-once and reused for every customer. Per operator (2026-05-30) they are not yet stood up in Syncro:

Prerequisites

Procedure

Part A — Create the customer Organization

  1. Organizations tab → +New Organization (opens on the Information subtab; also reachable from the global New menu). Work with Organizations | Create a Customer

  2. Business Name = the customer’s exact billing/legal name (the name we invoice). Keep it consistent — this is the canonical org name everything routes to. Best Practices for Creating Organizations

  3. Email field = the customer’s exact primary domain (e.g. smithlaw.com). Create a Customer

  4. Stamp the standard custom fields on every new org (used for SLA tracking + deployment) via Custom Fields for Organizations & End Users:

    FieldValue
    CS Client IDUniversal CS-#### key from HubSpot (the firm’s Company → cs_client_id). Same number identifies this customer in HubSpot, PandaDoc, reports, and billing — look them up by it anywhere.
    MSP PlanTier — Standard / Defense / Sentinel
    SLAThe notification/response SLA owed at this tier (e.g. Defense+ = 1-hour customer notification)
    PlatformM365 or Google Workspace
    Primary domaine.g. smithlaw.com
    Main POCPrimary contact name + email
    HubSpot Deal IDLinks the org back to the CRM record
    Go-live dateTarget/actual go-live
    HUNT_A-KEYHuntress agent/account key (endpoint deployment)
    HUNT_O-KEYHuntress org key (endpoint deployment)

  5. End User Portal: email-only for now — do not create a Portal User. (Revisit later if we offer a customer portal.) Create a Customer

  6. Apply the customer’s Syncro policy set (patch / monitoring / automation) — assign the Windows and/or Mac policy per the asset OS, defined in the RMM Policy Set SOP ✅ (patch SLA Critical 7d / High 30d / Standard 60d; after-hours maintenance window).

  7. Save the Organization.

Part B — Email-to-ticket via Email Rule (CyberSuite’s validated pattern)

Each customer gets an Email Rule keyed on their domain so any email from @theirdomain opens a ticket against their org. This is the method we’ve proven in production.

  1. Confirm the master switch is on: Admin > Tickets - Preferences → “Create Tickets from Leads (If Valid)” checked. Automatically Create Tickets from Inbound Emails
  2. Confirm the CyberSuite support mailbox is Active (Open one-time setup). Configure a Custom-branded Email/Mailbox
  3. Create the customer’s Email Rule (Emails/SMS / Mailboxes → Email Rules). Rules run top-down, first match wins — order matters. Automate Tasks with Email Rules
    • Condition: From email domain = @customerdomain.com.
    • Action — Assign to Organization: the new org (routes the ticket into our shared support queue; triage owner, not a fixer — SOP 13).
    • Action — Auto Create Contact Under Above Customer: ON. Because the contact is only created when the sender matches a known-customer rule, spam from unknown domains never creates contacts.
  4. Multiple sending domains: add one Email Rule per domain, each assigning to the same Organization. (Keeps each domain explicit and the routing auditable.)

Part C — Acknowledgement + staff alert

  1. Branded auto-acknowledgement: sender receives the CyberSuite-brand reply with their ticket number (our standard). Built once as a reusable template — see Open one-time setup. Maps to the SOP 13 acknowledge-within-SLA expectation. Work with Ticket Automations
  2. Internal staff alert on a new customer ticket — built once (Open one-time setup).

Part D — Schedule recurring deliverable tickets (per tier)

  1. Per the Deliverable Cadence & Triggers table, create a recurring Syncro ticket for each deliverable the customer’s MSP Plan tier owes (Monthly Report; Defense+: QBR, Tabletop, Compliance Posture/Mapping; Annual Renewal + Delta). Each ticket:

    • Opens at the deliverable’s lead time before its due date (the trigger).
    • Assigns to the Account Manager (the alert that it’s coming due).
    • Closes on delivery with the artifact attached — the proof-of-delivery record.

    This is what makes every recurring deliverable fire on its own and leave a documented trail — even automated ones still close a ticket. (Event-driven deliverables like the Incident Report fire from the incident, not a schedule.)

Verification

  1. Org exists: Organizations tab → search the billing name → record opens with the customer’s domain in Email and all custom fields populated. About the Organizations Tab/Page
  2. Mailbox Active: Admin > Emails/SMS - Mailboxes → support mailbox green/Active.
  3. Master switch on: Admin > Tickets - Preferences → checked.
  4. End-to-end test — with the customer at kickoff. Have the customer send a test email from their domain to our support address; confirm a new Ticket appears against their Organization in the shared queue, the contact auto-creates, and the sender gets the branded acknowledgement with ticket number. (Our existing rule pattern has tested clean.)

Rollback / if it goes wrong

Status: draft — the per-customer procedure is validated, but four Open one-time setup items must be built before a customer can go live (support mailbox, branded auto-ack, staff alert, per-tier policy templates). Move to done once those exist. Re-verify cited Syncro UI paths against docs.syncromsp.com when they change.