Built entirely in GoHighLevel

From missed concerns
to clear follow-through.
All in GoHighLevel.

I created a support ticket system that gives every client concern a visible owner, a clear status, and an automated path to resolution.

1Support pipeline
5Stages
5Emails
8Workflows
1Source of truth

The challenge

Good client care
needed a system.

Concerns were coming in, but there was no shared board, no consistent ownership, and no reliable way to make sure every issue was followed through.

01
Issue

Client concerns were missed

Messages could arrive without a consistent record or follow-through process.

02
Gap

No board, no oversight

There was no single view of open concerns, their status, or who was responsible.

03
Solution

A support ticket system

I built a structured board with ownership, stages, notifications, and automated updates.

The process

Four clear parts,
from concern to resolution.

The detailed workflow steps are documented further down. This view shows the operating logic: how a request enters, how GHL decides what to do, what the board stages control, and how replies reconnect to the right ticket.

01

Intake

The client submits the support form

GHL creates or matches the contact, captures the concern, and starts the Intake router.

02

Decision

Does this client already have an open ticket?

Yes

Add the message to the existing ticket, notify its owner, send Email 5, and move it to In Progress if it was waiting.

No

Generate a ticket number, create a new opportunity, copy the form fields, send Email 1, then tag and route it.

03

Board

The pipeline stage controls the next automation

UrgentTag + alert the team
In ProgressStop timers + clear urgency
Awaiting ReplyAsk, remind, then auto-close
ResolvedRecord, email, and open a 7-day reply window
04

Reply handling

Any customer reply finds the ticket again

The Reply handler locates the latest Support ticket, returns it to In Progress when appropriate, and alerts the assigned owner.

Inside GoHighLevel

Everything I set up
to make it work.

The system is built from native GHL objects: one pipeline, two field sets, one form, five emails, and eight focused workflows. Each piece has one clear job.

01

Opportunities

Support Tickets pipeline

The opportunity is the ticket and its stage is the status.

  • New
  • Urgent
  • In Progress
  • Awaiting Reply
  • Resolved
02

Contact fields

Temporary form capture

The form writes here first, then the New sequence copies the data to the opportunity.

  • Request Category
  • Support Type
  • Describe Your Issue
  • Attachment URL
  • Support Ticket Number scratchpad
03

Opportunity fields

The permanent ticket record

Every ticket keeps its own information, even when the same client submits again.

  • Ticket Number
  • Ticket Category + Support Type
  • Ticket Issue + Attachment URL
  • Additional Info Needed
  • Resolution + Date Resolved
04

Form

Submit a Support Ticket

The single entry point that creates or matches the contact and starts the Intake router.

  • Name, email, and optional phone
  • Category and support-type dropdowns
  • Issue description
  • Optional file or attachment link
  • Branded confirmation message
05

Email templates

Five customer updates

  1. Ticket Received
  2. Additional Info Needed
  3. Resolved
  4. Awaiting Reply Reminder
  5. Added to Your Open Ticket

Each uses the opportunity ticket number and Reply-To support inbox so replies return to the same process.

06

Routing

Category tags + team alerts

An If/Else branch tags the concern and notifies the same support team.

  • support-billing
  • support-technical
  • support-access
  • support-onboarding
  • support-product
  • support-general catch-all

Custom fields

Capture on the contact.
Store on the ticket.

The support form writes into contact fields first. The New sequence immediately copies that data onto opportunity fields so every ticket keeps its own issue, category, updates, and resolution.

C

Contact fields

The form capture layer

FieldTypeMerge key
Request CategoryDropdown{{contact.request_category}}
Support TypeDropdown{{contact.support_type}}
Describe Your IssueMulti-line text{{contact.describe_your_issue}}
Attachment URLText{{contact.attachment_url}}
Support Ticket Number scratchpadText{{contact.support_ticket_number}}
O

Opportunity fields

The permanent ticket record

FieldTypeMerge keyFilled by
Ticket NumberText{{opportunity.ticket_number}}New sequence
Ticket CategoryText{{opportunity.ticket_category}}Copied from contact
Ticket Support TypeText{{opportunity.ticket_support_type}}Copied from contact
Ticket IssueMulti-line text{{opportunity.ticket_issue}}Copied from contact
Ticket Attachment URLText{{opportunity.ticket_attachment_url}}Copied from contact
Ticket Additional Info NeededMulti-line text{{opportunity.ticket_additional_info_needed}}Support agent
Ticket ResolutionMulti-line text{{opportunity.ticket_resolution}}Support agent
Ticket Date ResolvedDate{{opportunity.ticket_date_resolved}}Resolved sequence

Custom value

company_nameThe business name used across all emails.

Custom value

support_slaThe promised response time, updated in one place.

Important: GHL generates merge keys from the exact field name. After creating every field, I confirm the generated key before using it in emails or workflows.

The workflows

Eight focused automations.

Each workflow is small enough to troubleshoot on its own. Stage changes trigger the right sequence, while the router and reply handler keep tickets connected.

03

Stage automation

Urgent sequence

  • Trigger when stage changes to Urgent.
  • Add the priority-urgent tag.
  • Alert the team; optional SMS escalation.
04

Stage automation

In Progress sequence

  • End the Awaiting Reply timer.
  • Clear the urgent flag.
  • Optional “we’re on it” email.
05

Stage automation

Awaiting Reply sequence

  • Send Email 2 with the information needed.
  • Wait three days, then send Email 4.
  • Wait two more days.
  • Move the ticket to Resolved if there is still no reply.
06

Stage automation

Resolved sequence

  • End any active reply timer.
  • Stamp Date Resolved.
  • Send Email 3 with the resolution.
  • Start the seven-day reopen window.
  • Optional CSAT request one day later.
07

Cross-stage

Reply handler

  • Trigger on an inbound email or SMS.
  • Find the latest Support ticket.
  • If Awaiting Reply, move it to In Progress.
  • If recently Resolved, reopen it to In Progress.
  • Notify the assigned owner.
08

Timer

Reopen window

  • Started by the Resolved sequence.
  • Keep a reopen tag active for seven days.
  • After seven days, remove the tag so unrelated future replies do not reopen the old ticket.

Required settings

The switches that make repeat tickets work.

These are easy to miss because the first ticket works without them. The failure only appears when the same client submits again.

01

Allow more than one opportunity

Settings → Objects → Opportunities → enable multiple opportunities per contact in the same pipeline.

02

Allow multiple opportunities in the workflow

Turn it on in the New sequence so Create Opportunity opens a new card instead of updating the previous one.

03

Allow re-entry on all eight workflows

The same client can return with another concern, and reopened tickets can fire In Progress again.

04

Keep contact deduplication on

Match by email or phone so the team sees one complete client history without duplicate contacts.

Quality check

How I tested the build.

The setup was not considered finished until the complete client journey worked, including repeat submissions and replies.

  • Submit one ticket per category and confirm the ID, opportunity, email, tag, and team alert.
  • Submit again from the same email and confirm the message is added to the open ticket, not a second card.
  • Drag a ticket through every stage and confirm each stage workflow fires once.
  • Reply while Awaiting Reply and confirm the card returns to In Progress.
  • Resolve, then reply within seven days and confirm the ticket reopens.
  • Resolve, submit a new concern, and confirm a second opportunity opens for the same contact.

The outcome

Support became visible and accountable.

The system replaced scattered concerns with a shared operating view that the team can oversee from intake to resolution.

01

Every concern is captured
Requests become trackable tickets instead of loose messages.

02

Ownership is visible
The team can see who is responsible and what needs attention.

03

Follow-through is built in
Stage-based updates and reminders keep both team and client informed.

04

History stays intact
Every ticket keeps its own concern, updates, and resolution.