Ticketing in BlueHill — SLA tracking, multi-assignee, email-to-ticket

What BlueHill ticketing does

Ticketing in BlueHill is built on a single Ticket model that lives alongside the customer record. Every ticket is automatically enriched with the customer's contact data the moment it's created — so the agent who picks it up sees the full account context, the related onboarding plan, the time entries, and the prior interaction history without leaving the screen.

This is different from running a help desk in a separate tool. There's no foreign-key bridge, no sync lag, no "where do I look up this customer's plan?" Everything connects to the same customer object.

What's in the data model

The fields that matter for support teams:

• Status — Open, In Progress, Pending, Waiting on Customer, Resolved, Closed
• Priority — Low, Medium, High, Urgent
• Assignees — an array of users plus an optional assigned_team
• SLA fields — due_date, first_response_at, resolved_at, sla_breach_at (stamped automatically)
• Tags — free-text array for taxonomy (billing, integration-help, feature-request)
• Category — single-select field for higher-level routing
• Source tracking — source (email, portal, web, manual) and source_email
• Email threading — email_thread_id links inbound and outbound emails into one thread
• Customer linkage — contact_ids array plus primary_contact_id

How email-to-ticket works

When an email arrives at your support inbox:

1. BlueHill ingests the message via the inbound email connector.
2. The thread is matched (by email_thread_id) — if it matches an open ticket, the message appends to that ticket's timeline; otherwise a new ticket is created.
3. Customer data is auto-enriched from the sender's email address. If the sender's domain matches an existing customer, the ticket is auto-linked to that customer record.
4. The thread continues bidirectionally — replies sent from BlueHill carry the original thread headers so the customer sees a clean conversation in their inbox.

You don't lose context in transit. Every email lives on the ticket, the ticket lives on the customer, and the customer's whole interaction history is one click away.

Interaction types and the visibility split

Every touchpoint on a ticket is one of these types:

| Type | Visible to customer? | |---|---| | EMAIL_INBOUND | Yes (it came from them) | | EMAIL_OUTBOUND | Yes (it goes to them) | | PHONE_CALL | No (internal log) | | SMS | Yes (if sent) | | MEETING | No | | NOTE | No | | INTERNAL_NOTE | No — explicitly hidden | | SYSTEM | No (status changes, assignments) |

The two-layer separation means your team can debate next steps, escalate to a manager, or share a customer-account password in the internal-notes layer without any risk that the customer will see it.

SLA tracking in practice

The SLA fields run automatically:

• When a ticket is created, due_date is set based on customer tier or rule (or left null for low-priority work).
• The first outbound EMAIL_OUTBOUND stamps first_response_at.
• Status transition to Resolved stamps resolved_at.
• If due_date passes without resolution, sla_breach_at is set.

Reports group by SLA-met vs SLA-missed, by team, by priority, and by customer tier — so you can answer "are we hitting SLAs for Enterprise customers" in one chart.

Multi-assignee and team routing

Tickets aren't owned by a single person. The assigned_to field is an array, which means a frontline agent and a specialist can both be on a ticket without one of them losing visibility when they reassign. The assigned_team field rolls tickets up to a queue (e.g. "Billing", "Integrations", "Trust & Safety") so managers can balance load across teams without micromanaging individuals.

What you'd typically pair with ticketing

• Customer portal — customers submit tickets from a branded portal with their own login, and watch status update in real time.
• Forms — intake forms (e.g. "Report a bug") auto-create tickets with the structured data attached.
• Team collaboration — internal notes, mentions, and role-based access decide who sees what.
• Automation — webhook + API hooks fire on ticket events for any downstream integration.

Built for

• Support teams running reactive ticket queues.
• Customer success teams folding ticket workload into the broader account view.

Try it

Start a 14-day free trial — no credit card required.