Complaints submitted through sales forms
How to route a complaint that arrives through a sales form
By ByTomorrow · Published
A customer uses the contact form to complain about an existing job. If the form automatically starts a sales sequence, the next message can ask them to book a consultation instead of addressing the complaint.
Treat the message meaning as a separate decision from the form name. The routing and suppression worksheet below is a proposed operational process, not legal advice or a promise about how an existing workflow behaves.
What to distinguish
Avoid these misleading shortcuts
The form label decides the intent
A form called New Lead can receive existing-customer requests, complaints and unrelated messages. The trigger records an arrival, not its business meaning.
Routing changes but messages keep running
Assigning a service owner may leave the original sales workflow active. The suppression behavior must be part of the design and test.
Working worksheet
Make the rule and evidence explicit
Preserve the original submission
Keep the submission reference, accepted time, original wording and the customer's stated contact preference in the inquiry record. Avoid replacing the complaint with a generic negative-sentiment label.
Classify without claiming resolution
Use complaint, possible complaint requiring review, ordinary inquiry or unrelated. A request about unsatisfactory work should reach the service-review route. An ambiguous message remains reviewable; do not demand that the customer use a particular keyword.
Hold the inappropriate sales path
For complaint and possible-complaint states, design the workflow to withhold unsent promotional follow-up while an owner reviews the case. Inventory every enrollment and message path. A classification field alone does not cancel queued actions.
Assign a service case owner
Record named owner, acceptance status, next action and any approved response expectation. The case remains unaccepted until its owner acknowledges it. Sending a notification to a group does not establish responsibility.
Fictional response example
A fictional submission says an existing appointment was missed. Suggested acknowledgment: “We received your message about the appointment. I am passing the details to the service team for review.” Use that wording only when the routing occurred; do not promise a refund, admission or deadline the responder cannot authorize.
Run the suppression test
Submit a marked test complaint, then inspect the sales enrollment, queued messages and service task. Repeat with an ambiguous complaint and a genuine new inquiry. The complaint paths should receive the agreed hold; the ordinary inquiry should retain its correct workflow.
Use and verify
Check the result in the actual workflow
Map all form-triggered work
List immediate responses, delayed messages, owner assignments and linked workflows.
Add classification and review ownership
Define the categories and who resolves uncertainty.
Verify suppression at send time
Test a message already waiting when the complaint state changes, not only a fresh submission.
Review the case outcome
Only the authorized owner decides resolution and any future sales-contact eligibility. Avoid reopening a sales sequence merely because a service task was closed.
Questions
Straight answers.
Do not assume it. Inspect the actual workflow rules and queued actions, then prove the intended behavior with a test.
Its documentation covers form triggers and conditional branches. The particular classification, ownership and suppression behavior needs implementation and verification.
This procedure adds a specific hold on inappropriate sales communications and tests the race between a complaint and an already queued message.
Sources and further reading
- HighLevel form-submitted trigger
HighLevel documents form-triggered workflows and filters. A submitted sales form does not by itself establish sales intent.
Checked .
- HighLevel If/Else workflow action
HighLevel documents conditional workflow branches; business-specific complaint classification and suppression rules require separate configuration and tests.
Checked .
Bring one process to review
Use the worksheet with your existing records and tools. Agree on the expected behavior, owner and verification before making a change.
Discuss your workflow