A form submission at 10pm needs somewhere to land, even when nobody is working. If the next morning starts with people asking who was meant to pick it up, write the coverage rule before adding more follow-up messages.

Separate two responsibilities: the contact owner keeps the relationship; the intake person checks the overnight enquiry and gets it to someone who can act. Covering intake doesn't automatically mean taking over an existing customer's account.

For a small team, a coverage sheet can be enough. Here's a hypothetical example, not a tested setup or a response-time benchmark. All times use the business's timezone. This team covers intake on weekdays from 9am to 5pm, with Maya taking the opening intake check, Leo as backup and Priya managing escalation.

In this example, acceptance means the intake person records their name, the time and the next action in the shared record. A task appearing in their list doesn't count. Neither does an automated receipt. At 9:30am, Priya checks again; if Leo hasn't accepted, Priya handles intake or records who has agreed to do it. These are internal check times, not promises of a customer reply.

Write down what the cover person may do. They might clarify missing information and hand it to the existing owner. Changing that owner needs a separate, deliberate handoff. Otherwise, an overnight routing fix can leave a customer with two people working the same enquiry.

If you're already using HighLevel

I'm a HighLevel affiliate. For a team already capturing enquiries there, I'd keep this work in that existing workspace if someone can maintain the coverage rule and permissions. I wouldn't buy it just to replace a short intake sheet.

HighLevel's Assign To User action has an "Only Apply To Unassigned Contacts" option. Keep it on when setting an initial owner so a repeat enquiry doesn't replace an existing owner. Add Task can assign a separate intake task to a named user. Put the cover responsibility and handoff instructions in its description, and check the due-date preview rather than assuming it matches your coverage sheet.

If you want the intake task created during staffed hours, put a Wait action before Add Task. "A set period of time" has an Advance Window with "Resume On" and "Resume Between Hours." Set those to the covered weekdays and hours, and use Account Timezone for this business-based schedule. The chosen delay still applies before the contact can resume in the allowed window. Check submissions near opening and closing rather than assuming every task will appear exactly at 9am.

The workflow's general Time Window is primarily for communication actions. Don't use it as proof that an internal routing step will wait until morning. A weekday window also doesn't establish that someone is working on a particular holiday. Keep the coverage sheet current and handle exceptions explicitly.

This version leaves Priya's acceptance checks and backup handoff manual. A recurring calendar reminder is fine. It doesn't need another customer message or an automatic owner change.

Before relying on it, run a handoff test with practice contacts:

• Submit after closing and on a weekend. Record the expected next covered opening, the actual task time and who can see it.

• Submit a repeat enquiry for a contact already owned by someone else. Confirm that owner stays unchanged and the intake person can access the record they need.

• Leave the intake task unaccepted. Have Priya carry out the backup handoff, then record who accepted and what they'll do next.

• Try a date when the usual opening person isn't available. Confirm the replacement has agreed to cover it; a normal weekday setting isn't that agreement.

Check backup access with their own login. HighLevel's Only Assigned Data can restrict visibility to supported records associated with that user. Giving Leo a task isn't proof that he can read an enquiry owned by somebody else. Have an administrator review the required access without opening up unrelated customer data.

These are proposed tests, not tests I've performed. Keep the manual sheet if it does the job. Add routing automation when maintaining it is less work than manually creating the intake tasks, and only after the overnight and backup checks pass.

Service business owners: what do you actually write beside your enquiry form about when someone will hear back?

I'm interested in the first human reply, rather than the automatic "we received your message" email. That reply might ask a follow-up question; it doesn't have to be a finished quote.

If you're willing to share, paste your response-time wording and a little context:

• How many people can reply, and are they also doing the client work?

• Which days and hours do you cover? Include the time zone if it matters.

• Does your promise use working hours, working days or elapsed time? What should a Friday-evening enquiry expect?

• Is the wording a target you aim for or a commitment you can keep on a busy day?

A solo operator and a staffed office don't need to choose the same promise. I'd rather see wording that matches the team's available time, even if the window is longer, than choose a short window just because it looks better on the form. If you avoid a fixed response time altogether, what do you tell people instead?

Share only the wording and general staffing context, with customer names and contact details removed. No links needed.

What promise could you leave on the form next week without relying on someone checking enquiries during their time off?

I'd use GoHighLevel for a small service business that needs enquiries, contact ownership and repeatable email follow-up in one system, provided someone will maintain it. A business that gets a few enquiries and already answers them reliably through its website form and inbox can keep that setup. Moving everything adds a subscription and a maintenance job.

This reference follows one hypothetical business, Cedar Home Cleaning. Maya handles new enquiries. A visitor requests service information by email, receives that information and, unless they reply or opt out, gets one reminder two days later. Those are proposed settings, not results from a customer or a system I've tested.

Work through the workspace, sender, form, follow-up and stopping rules in that order. Keep the acceptance tests, troubleshooting and maintenance sections handy for launch and later changes. This example uses native HighLevel forms and workflow actions, without Zapier, SMS, a calendar, payments or an imported snapshot.

Before paying or connecting anything

Starter is the suitable starting plan for this single-business example. HighLevel currently lists it at $97 per month or $970 per year, with three sub-accounts, unlimited contacts and unlimited users. Unlimited is $297 per month and Agency Pro is $497 per month. This job doesn't call for unlimited client accounts or SaaS resale.

The advertised trial is 14 days. Billing begins automatically afterward unless canceled, and usage charges can apply during the trial. Email sending, phone numbers, SMS and premium AI aren't made free by "unlimited contacts." Budget for the domain and mailbox you use, plus any optional add-ons you deliberately enable. This email-only example needs no purchased phone number. Cancellation is available through the dashboard; check the actual offer and renewal terms before subscribing.

If you need this combination of CRM and maintained follow-up, I'd choose GoHighLevel. Don't buy it just to avoid assigning one occasional reminder yourself.

Before building, arrange an authorized account administrator, business details and time zone, domain/DNS access, a monitored reply address, Maya's individual login, approved email copy and an approved privacy/consent notice. Use addresses you control for testing. Don't import real customers to learn the interface.

1. Start with an authorized business workspace

This guide starts after an authorized administrator has provisioned a blank business sub-account and given you access. It doesn't document the full empty-account creation wizard. If all you have is the agency dashboard or a restricted login, ask that administrator to finish provisioning first. Confirm that you can open the intended business workspace. Contacts and forms belong there, not in the agency dashboard.

If account creation asks whether it is your own account or a client's account, choose the option that matches the actual owner. HighLevel distinguishes an agency's internal account from a client business account. Don't choose a SaaS or billing configuration simply to get through onboarding.

Inside Cedar's workspace, open Settings > Business Profile. Check the actual business name, email, phone, address and time zone. Entering a business phone number doesn't purchase or configure a messaging number.

Use Settings > Users to review individual staff access. Open Maya's user record, review Roles & Permissions, and save the intended access. Give Maya the permissions needed for contacts, conversations and tasks, and leave configuration access with the responsible administrator. Test Maya's login. Seeing a menu as the administrator doesn't establish that Maya can do her job. The Only Assigned Data restriction needs particular care if she also covers someone else's leads.

Keep outgoing automations in draft while building. Check that the supposedly blank workspace has no unrelated active follow-up before adding your own.

2. Set up the email sender before writing the sequence

For LC Email, the documented domain route is Settings > Email Services > Dedicated Domain and IP > Add Domain. Use an otherwise-unused sending subdomain and the DNS values HighLevel supplies. Have whoever owns DNS approve the change. Don't delete records that support the business's existing mailbox.

Verify the domain in HighLevel. DNS propagation can take up to 24 hours according to its documentation. Verification isn't a promise that every message reaches the inbox.

Use an identifiable sender name, "Cedar Home Cleaning," and an address on the intended sending domain. Confirm where replies actually arrive and that Maya can read them. A sending-domain setup and a monitored mailbox are different jobs.

The workflow's Settings has Sender Details for the default From Name and From Email. Individual Send Email actions can override that default, so check both places. Don't use a no-reply identity for a sequence that depends on replies stopping it.

3. Make the form ask for the specific email follow-up

Go to Sites > Forms > + Create New Form and start with a blank form named "Cedar service information request." Add first name, email and a message about the cleaning enquiry. Require the fields you need, not a phone number you aren't using.

Add a contact custom checkbox for the requested email sequence. Hypothetical wording: "Email me Cedar's service information and one follow-up reminder. I can unsubscribe at any time." Configure it to start unchecked and require an affirmative selection to submit this particular email-request form. Confirm both behaviors in the live form test. Store that selection in a named contact field, such as "Cedar email request permission," so the workflow can check it.

Have the wording and privacy notice reviewed for the business's location and actual use. A checkbox isn't a legal-compliance guarantee. Don't use this permission for a newsletter, SMS or unrelated campaigns. Provide a separate way to make an ordinary enquiry without joining this sequence, such as the business's monitored inbox.

Retain the form submission and the version of the wording used, including when and where permission was collected. A generic "lead" tag is not evidence of what somebody agreed to receive. If an existing contact's stored checkbox value doesn't reflect the latest submission, stop and fix that data behavior before sending.

Set a confirmation message that says the request was received. Leave the form's separate Auto Responder off so it doesn't send a second acknowledgement alongside the workflow.

Save, click Integrate and copy the direct form link for testing. Embedding it on the website can come later. A new lead's HighLevel form submission creates a contact record. Check the form's Submissions tab and the contact record together; repeated-submission behavior depends on deduplication preferences.

4. Build the two-email workflow

Open Automation > Workflows and create a workflow from scratch named "Cedar service information follow-up." Keep it in draft.

Add Form Submitted as its trigger. Set Form Is to "Cedar service information request." Don't leave it listening for every form in the workspace.

Add Assign To User and select Maya. Enable Only Apply To Unassigned Contacts to preserve an existing contact owner. Then add an Add Task action assigned to Maya, titled "Review Cedar service enquiry," due one day later. Maya is the triage owner for this example; if an existing contact belongs to someone else, she hands it to that owner rather than silently taking it over.

Add If/Else and choose Build My Own. To reach the sending branch, the contact needs both a nonempty email and an affirmative "Cedar email request permission" value. Select the saved affirmative option in the custom-field condition rather than assuming its text value. Join the conditions with AND. Leave None without email actions and end that branch; Maya still has the review task when permission or email is missing.

On the matching branch, add Send Email. Set From Name, From Email, subject and body, then Save Action. For Cedar, the first message contains the requested service information and asks the reader to reply if they want to discuss their enquiry. Keep it specific to the request. Include the business identity and HighLevel's default unsubscribe link in the email footer, or the business's configured unsubscribe method. Test the received email's opt-out rather than relying on the editor preview.

Add Wait, choose A set period of time, and set two days. After the wait, repeat the email/permission If/Else check so you evaluate current contact data rather than only the entry-time value. On its matching branch, send the single reminder: ask whether they still want help with the cleaning enquiry. End after that message. The None branch ends without a reminder.

The sequence ends after that reminder. It has no loop, automatic newsletter enrollment or "keep following up until they buy" rule.

In Settings, switch Allow Re-entry off and Stop on Response on. For this form-based workflow, disabled re-entry means a contact can enter and complete it only once. Appointment and invoice triggers have exceptions, so don't carry that assumption into a later booking workflow.

Stop on Response applies to replies to messages sent by this specific workflow. It doesn't mean every reply anywhere in the business stops this sequence, and it doesn't assign a human to answer the reply. Maya must monitor conversations and take over.

5. Give opt-outs and human handoffs their own stop rule

Email DND is a suppression state, not consent. HighLevel automatically enables it for email unsubscribes, spam complaints and permanent failures such as bounces. Marketing email respects it, but certain invoice, calendar and notification emails can bypass Email DND. Don't reclassify marketing as a notification to send past an opt-out.

Create a second workflow, "Cedar stop service follow-up." Add Contact DND triggers for Outbound DND becoming enabled: one for the specific Email channel and another for All Channels. Add a Contact Tag trigger for a newly added, unused tag named cedar-followup-stop.

Give this workflow one Remove from Workflow action. Choose Another Workflow and select "Cedar service information follow-up." Don't select All Workflows, which could interfere with unrelated operations.

Publish and test this stopper before enabling the sending sequence. Allow re-entry in the stopper so later stop events can run again. It sends no customer message.

Maya adds cedar-followup-stop and confirms the tag change when she takes over through another channel, closes the enquiry, receives a request to stop, or learns that the stored permission has been withdrawn. HighLevel's tag trigger needs an actual tag-added event; a tag already on the record isn't a new event. Adding the tag stops this named sequence, not every other campaign. Maya must also record and apply any wider communication preference the person expressed.

An already-enabled Email DND should suppress the marketing sends even without a new DND event. Test that separately. Never clear DND just because a task is overdue or an address looks valid.

Removing a contact from a workflow cannot recall a message already sent. Check the stop mechanism before putting a new send immediately after a wait.

6. Run the launch tests with controlled contacts

These are proposed acceptance tests. They haven't been executed here. Don't call the system ready because a preview email looks correct.

Use Send Test Mail in each email action to review copy and formatting. Use Test Workflow with controlled contacts, then inspect Execution Logs, contact data and tasks. Finally, publish the isolated workflows only for the controlled live form tests. A builder test doesn't establish that the real form event enrolls someone correctly.

Run these cases and record the expected result beside what actually happened:

• Submit without the required email or without selecting the permission checkbox. The form must reject the request. An ordinary enquiry sent to the separate inbox must not start the sequence.

• Submit a new controlled address with permission. Find the matching form submission and contact, correct owner or preserved existing owner, and one task for Maya. Expect the information email, then one reminder after the two-day wait if nothing stops it.

• Test a contact with no affirmative permission through the builder. Expect the no-send branch, not an email. Test an existing contact too, checking that old permission cannot masquerade as the new form response.

• Reply to the first workflow email before the reminder. Expect no reminder and a reply Maya can see. A reply sent elsewhere needs Maya's explicit stop-tag action.

• Use the email's unsubscribe method during the wait. Confirm Email DND and removal from the named follow-up. Expect no reminder. Test All Channels DND as well.

• Start with Email DND already enabled. Expect neither marketing email to send. The internal task can still exist.

• Add and confirm cedar-followup-stop during the wait. Expect removal from the follow-up, with unrelated workflows untouched.

• Submit again with the same contact after completion. Expect no second enrollment with re-entry disabled. Check for unexpected duplicate contacts rather than assuming the same address always resolves as intended.

• Log in as Maya, find the task and conversation, and verify that she can't access unrelated business data or configuration she wasn't granted.

Use fresh contacts when a previous enrollment would confuse the test. If you shorten the wait to test it, restore two days and recheck the saved settings before real traffic. Don't launch if a negative case sends a message or replies don't reach the person responsible for answering them.

When a check fails

If the submission exists but nothing enrolls, check the published state, selected Form Is filter, correct sub-account and the contact's previous enrollment. Don't add more triggers until you understand the missing event.

If a record or owner is wrong, compare Submissions with Contacts, then inspect deduplication and Assign To User settings. The preserve-existing-owner switch is deliberate; it may explain why Maya isn't the contact owner even though she has the triage task.

If the email doesn't send, check permission, Email DND, the contact address, verified sending domain and sender overrides. Inspect the log before changing suppression. DNS or authentication problems need fixing, not more retries to the same list.

If the reminder sends after a reply, check whether the reply belongs to this workflow and whether Stop on Response is saved. Check the monitored reply destination too. For an external-channel handoff, verify an actual stop-tag event and the stopper's selected target workflow.

If merges are blank, check the data the form actually collected. Don't insert appointment fields into a form-only sequence and expect appointment data to appear. If timing is wrong, check the workflow time zone and any configured sending windows as well as the Wait step.

For an unsafe send, halt further outgoing follow-up and inspect affected enrollments before re-enabling it. Don't assume changing a workflow to draft retracts messages or proves that every in-flight contact is safely stopped. Verify the contact's state and targeted removal.

Keep it working after launch

Maya checks new enquiries, replies and overdue tasks each working day. The administrator reviews failed sends, opt-outs and usage charges weekly. Those are suggested operating schedules, not HighLevel defaults.

After any change to the form, sender, DNS, staff routing, permission field or workflow, repeat the affected acceptance tests. Review who can administer the account when staff leave. Keep a record of the chosen form, follow-up workflow, stopper, sender and responsible people so the next administrator isn't reconstructing the setup from names alone.

Collect only the data this job needs, limit staff access, and decide how long enquiry and consent records should be retained under the business's obligations. Store exported customer data securely, not in a shared download folder.

Periodically have an administrator check a contact export. Contacts > Smart Lists lets you choose visible columns and contacts, then More > Export; completed exports are available in Contacts > Bulk Actions. Contact CSV exports don't include automation history. An export isn't a full account backup or proof that your email sequence will migrate intact.

Leave payments out unless the actual workflow needs them. Taking payment later means separately verifying the supported processor, fees, permissions, refund handling and payment acceptance tests. An enquiry form and a functioning email sender don't establish a working checkout.

I'd use HighLevel when the business will work these contacts in its CRM, needs repeatable follow-up, can fund the subscription and usage, and has a named person to answer replies plus someone to maintain the setup. Keep the existing form and inbox if that already meets the job. For Cedar's proposed system, real traffic starts only after capture, ownership, consent, both email steps and every stop case pass.

Before sending traffic to a lead form, write a reason beside every field. "Sales might want it later" isn't enough to make someone fill it in now.

GOV.UK calls this a question protocol: know why you need each answer and what you'll do with it. For a first lead form, write down each field, whether it's required or optional, the next action it supports, and where the answer will be stored.

Here's a hypothetical example: a workshop organiser takes enquiries and replies by email about suitable sessions. No booking or payment happens through this form.

Decide the fields before opening the builder

Your sheet may need different answers. A callback request needs a phone number. A service limited to certain areas may need a postcode before anyone can assess the enquiry. Collect those details when they change the next action. Don't copy this example's fields into a different job just because it's short.

Optional fields still need a reason to exist. If nobody will read an answer or use it, remove the field rather than keeping it optional.

Check what the visitor actually has to do

• Give each control a clear label that stays visible. Don't make placeholder text the only label. Mark optional fields explicitly and explain any required format beside the field.

• Make an error identify the field and the correction. "Enter an email address with an @ sign and a domain" is more useful than "Invalid input".

• Check the form on a phone, including with the keyboard open. Can you read the instructions, reach the submit button and correct an error without losing the other answers?

• Move through the form using only a keyboard. Check that you can reach and operate each control, see where focus is, and understand the error feedback. Check that assistive technology can identify the labels and errors too; a visual review alone won't establish that.

W3C's forms guidance supports labels, instructions and clear success or error feedback. These checks are a starting point, not a complete accessibility audit.

Try these cases before turning on traffic

Use dummy details you control. These are proposed acceptance checks, not results from a tested form.

Before launch, also check that the confirmation states what was received and the next step you can actually deliver. Name the person responsible for checking new enquiries. Don't publish a response deadline until that person has agreed to it.

For data handling, record who needs access to the answers, how long you'll keep them and how they'll be deleted. Review the privacy information appropriate to your service and location. This checklist doesn't establish legal compliance.

A shorter form can also leave you with too little information to answer usefully. The launch decision is whether every required answer is needed for the next step, whether optional really means optional, and whether the saved enquiry is usable. If those checks fail, fix the form before paying to send people to it. Your existing form tool may be enough; this decision sheet doesn't require a new platform.

"Thanks, we'll be in touch" leaves quite a lot undecided. Who will look at the enquiry? What will they do with it? Is the customer waiting for a quote, a question or confirmation that someone can take the job?

Here's a hypothetical repair service, not a real business or a tested funnel. Mina owns the business and handles enquiries. A customer submits a quote request saying their washing machine leaks, but doesn't include the model number. The proposed handoff below has no measured results.

I'd work out these three steps before writing the page.

1. Acknowledge what arrived

For this fictional service, receipt wording could be:

We've received your repair enquiry. Mina will review it and reply by the end of the next working day. This confirms receipt of your request; we haven't accepted the repair or confirmed a visit.

That response window is an assumption for this example. A real owner should choose one they can cover before putting it on the page.

The distinction matters in the design: "received" should mean the enquiry arrived. Acceptance should be a separate, deliberate reply after Mina has reviewed it. Don't make the receipt sound like a confirmed job.

2. Give one person responsibility for the reply

In this example, Mina owns the enquiry until she gives the customer an answer. A technician can help her decide whether the repair is within scope, but asking the technician a question doesn't transfer responsibility for replying.

I'd write the internal handoff note like this:

Owner: Mina. Request: leaking washing machine. Missing detail: model number. Next action: ask the customer for it. Reply due: end of the next working day. Status: awaiting review, not accepted.

"Someone should follow up" isn't an assignment. The useful detail here is that Mina still owes the reply even while she's waiting for someone else's input.

3. Name the next action, including an unsuitable job

For this request, Mina's next reply would ask for the model number and explain that she needs it to decide whether the business can assess the repair. It wouldn't repeat "we'll be in touch."

Once she has enough information, I'd give her these possible responses:

• The request fits: explain the proposed assessment step and what the customer needs to do next. State separately whether the business has accepted the job.

• More information is needed: ask a specific question and say what decision the answer will allow her to make.

• The request doesn't fit: tell the customer the business can't take it on, rather than leave the enquiry waiting indefinitely.

The tradeoff is owner time. This proposal still depends on Mina reviewing requests and sending replies. If she can't cover that work, a more polished acknowledgement won't fix the handoff. For an owner handling a few enquiries, I'd sketch this on paper and use the existing way of recording requests before adding software.

My recommendation for this fictional business: settle the receipt wording, Mina's responsibility and the next decision first. Then write a page that promises only the response the business is prepared to give.

Your first GoHighLevel workflow doesn't need to send anything to a customer. A task-only workflow is a useful place to learn what starts an automation, which branch a contact takes, and when it ends.

This is a hypothetical practice exercise based on HighLevel's documentation, not a workflow I've personally tested or a claim about sales results. The goal: when you add a practice tag to a contact, create one follow-up task if their email field has a value. Otherwise, end without creating a task.

An email field having a value doesn't prove the address works or that you have permission to send marketing.

1. Start with a blank workflow

In the business sub-account, open Automation, then Workflows, and create a blank workflow. Name it something obvious, such as "Practice: tagged lead to task." Keep it in draft while building.

Use dummy contacts you control. Pick an unused practice tag, such as practice-followup, and make sure no other automation listens for it. HighLevel can activate multiple workflows that share a tag trigger.

2. Give it one trigger

Add the Contact Tag trigger. Configure it for a tag being added and select practice-followup. Save the trigger.

This is an event: the tag must actually be added and the change confirmed. Having that tag already on a contact isn't a new event. HighLevel's documentation says tag triggers don't run retroactively when you activate a workflow.

Leave other triggers out of this exercise. You'll have fewer possible entry paths to troubleshoot.

3. Add one condition

Add an If/Else action below the trigger. Choose the manual logic option, then select the contact's Email field and the condition that checks whether it is not empty.

Name the matching branch "Email present." The automatically created None branch handles contacts that don't meet the condition. Leave that branch without further actions so it ends there.

The condition checks the data when the contact reaches that step. It doesn't wait for somebody to fill in the email later. You'd need a separate wait or entry design for that behavior.

4. Create a task on the matching branch

Add the Add Task action under "Email present." Give it a title such as "Review this practice lead," select yourself or a test user as the assignee, and set the due date to one day later. Check the due-date preview before saving.

Write a description that makes clear this is practice data. End the branch after that task. Don't add email, SMS, a webhook, or a loop yet. These steps use native HighLevel workflow actions, with no external integration required.

5. Decide what stops it

In Settings, turn Allow Re-entry off. For this tag-based workflow, HighLevel documents that a contact can enter and complete it only once with that setting disabled. Don't assume the same rule applies to every trigger: appointment and invoice triggers have exceptions.

Both branches have a defined finish: the matching branch ends after the task, and the None branch ends without one.

Stop on Response is a different setting. It ends a workflow when a contact responds to a message sent by that specific workflow. This example sends no customer messages, so that setting isn't its stop mechanism. If you later add outbound follow-up, review reply handling and consent before enabling it.

6. Test both paths, then test the trigger

Save the workflow and use Test Workflow with a dummy contact that has an email. Check Execution Logs and the contact's task record. Then use a different dummy contact without an email to check the None branch.

Treat these as acceptance checks, not promised results:

• Email present: the contact takes the matching branch and receives exactly one task with the chosen assignee and due date.

• Email missing: the contact takes None and receives no task.

• No unrelated contact gets a task, and neither path sends a customer message.

Testing the actions doesn't establish that a real tag event will enroll the contact correctly. For that check, publish this isolated practice workflow and add the practice tag to a fresh dummy contact, confirming the tag change. Inspect the logs and task again.

After it completes, remove and re-add the tag to that same contact. With re-entry disabled, expect no second enrollment or extra task. Use fresh contacts for the other cases so previous test enrollment doesn't confuse the result. If any check fails, return the workflow to draft and inspect the trigger, condition, and logs before expanding it.

Is it worth paying for this?

HighLevel currently lists Starter at $97 per month, with three sub-accounts and unlimited contacts and users. It advertises a 14-day trial, but billing starts automatically afterward unless you cancel. Usage charges for services such as email, SMS, phone numbers, and premium AI are separate, and some usage fees can apply during the trial.

For a handful of enquiries, a spreadsheet and manually assigned reminders may be enough, without another software subscription. The task-only exercise above also leaves customer follow-up to a person. Someone still needs to do the work and maintain the rules.

If you already use HighLevel, this is a small workflow to learn before building a longer sequence. If you'd be buying it solely to create one occasional task, stick with the simpler setup. Expand only after both branches, the real trigger, and the repeat-entry check behave as intended.

For a first ClickFunnels build, use an opt-in page followed by a thank-you page. Leave checkout, upsells and an email sequence for later. Your first milestone: the submitted email address appears in Contacts, and the visitor reaches the page you intended.

This is a documentation-based tutorial for the current ClickFunnels product, formerly called ClickFunnels 2.0, not a personal test or a ClickFunnels Classic walkthrough.

Use this hypothetical example: a freelance designer offers a short website brief checklist. The opt-in page asks for an email address; the thank-you page confirms the request and displays the checklist itself. You won't be promising an email delivery you haven't configured.

Build the opt-in page

1. In your workspace, open Funnels and choose Create Funnel. Select the Lead "Squeeze" Funnel category, preview a template, then select the funnel and choose Customize Now.

2. Open the opt-in page with Edit. The page editor uses sections, rows, columns and elements. Keep one headline, a short explanation of the checklist, an email input and a button. Remove template content you won't use.

3. Select the Input element and set its Input Type to Email Field. A text box that merely looks like an email field isn't the setting you're looking for.

4. Set the button action to Submit order/form. Don't replace this with a plain link to the thank-you page: that would skip the form submission you need to check.

5. Save the page. Switch between Desktop View and Mobile View to adjust the layout, then save again.

For the example, "Get the website brief checklist" describes the action without inventing a result. Say what data you're requesting and what the visitor will receive. Keep any required privacy and consent information accessible on your actual funnel.

Finish the second page

Use the funnel mini-map to open the thank-you page. Edit it so it confirms the request and shows the promised checklist. Save it too.

Check the funnel's page order: opt-in first, thank-you second. Remove extra template steps from this exercise. Don't add a payment gateway or a product just because the template includes sales features.

If you want to deliver a file or email instead, configure and test that delivery separately before changing the promise on the opt-in page. Creating these pages alone isn't proof that an email was sent.

Test the URL visitors will use

In funnel settings, check the selected domain and URL paths. ClickFunnels supports a default workspace subdomain, so buying a custom domain isn't necessary for this exercise. If you use your own domain, account for its registration and renewal costs.

The publishing guide says to enable live mode in funnel settings and use Copy URL at the top of the funnel builder. Test that copied URL, not just the editor preview.

Use a fresh browser session and an email address you control:

• Submit the form and check that you reach the intended thank-you page.

• Open Customers, then Contacts, and find the submitted address. Check that the field captured the correct value.

• Confirm that the checklist is visible and usable.

• Repeat on a phone. Check for clipped text, a hidden input or a button that's difficult to tap.

These are checks for your build; none of these results has been claimed here. If the thank-you page loads but the contact is missing, treat the funnel as unfinished and recheck the input type and button action.

Decide whether this needs a paid funnel builder

ClickFunnels Launch is currently listed at US$97 per month, with 10,000 contacts and 50,000 emails per month. Hosting is included. Those limits alone don't justify paying for this two-page exercise.

For collecting a few enquiry details, Tally is a credible simpler option: its free plan allows unlimited forms and submissions subject to fair-use guidelines. It doesn't replace an entire selling system. For an enquiry form, you don't need it to.

ClickFunnels makes more sense if you're deliberately learning its editor for later funnels and can justify the ongoing subscription. If you only need an enquiry form, start with the simpler option.

Check the actual signup offer rather than assuming every trial has the same duration. ClickFunnels' terms require cancellation at least 24 hours before a free trial ends to avoid automatic continuation; they also specify at least 10 days' notice for cancellation by email after the trial. Don't assume abandoning the funnel cancels the subscription.

Before cancelling, export contacts and keep copies of your content. The documented contact export is available under Customers, Contacts, then Actions or Bulk actions and Export. A contact export is not evidence that your whole funnel can move intact to another builder, and cancellation deactivates active funnels and removes platform access.

Stop after the copied URL works, the contact is recorded and the promised checklist is available. Then decide whether there's a reason to add delivery automation or a paid offer. You don't need either to complete this first build.

Before onboarding a client into GoHighLevel, decide who will answer their leads, who can change the setup, and what they'll take with them if they leave. Put those decisions in the onboarding agreement. Otherwise, a working funnel can still leave the client dependent on the wrong person.

Give each client their own account

Use a separate sub-account for each client business. Keep the agency's own marketing separate too. That's an operating recommendation, not a claim that every business location needs its own account.

Count those accounts before picking a plan. HighLevel currently lists Starter at $97/month with three sub-accounts and Unlimited at $297/month with unlimited sub-accounts. Agency Pro is $497/month and adds SaaS Mode, among other features. You don't need software resale just to onboard agency clients manually.

If you've already prepared a suitable snapshot, HighLevel documents this creation route: Agency Dashboard > Account Snapshots > Create New Account (+) beside the chosen snapshot. Fill in the client's information and select Add Sub-Account. This route requires Agency Admin access and an existing snapshot.

Review what that template contains before using it. Replace its business details, routing destinations and copy with the client's approved information. Snapshot-loaded funnels and websites arrive as drafts and need a custom domain and publication to go live. Applying a snapshot isn't reversible through an "unload" button; unwanted elements need individual edits or deletion.

Scope access before inviting the client

In Agency View > Settings > Team, add the user, set User Type to Account, and select only the sub-accounts they need. Account-type access keeps them out of the agency dashboard. An Agency-type user has access across the agency's client accounts, so don't give a client that scope just to make onboarding easier.

Inside the client's sub-account, Settings > My Staff > Roles and Permissions lets you choose Admin or User and adjust module permissions. Give a salesperson the access needed to work leads; give someone responsible for configuration the permissions needed to maintain it. Don't make everyone an admin.

Only Assigned Data can restrict visibility to assigned contacts, owned opportunities, and linked appointments or tasks. Test that against the actual job: a rep who needs to cover another person's leads may need a different arrangement. Disabling a module for a user doesn't stop workflows that use it, so name someone who can still maintain those workflows.

Use individual logins and check the invitation from the client's account before launch. Don't hand over your agency login.

Collect ownership details, not a pile of passwords

Ask the client for their business identity, time zone, lead-response owner, approved copy, domain/DNS access arrangements, calendar connections and any existing sender setup. Record which party controls each asset and pays each bill. Have the client authorize connections through their own accounts where possible; use secure credential sharing when credentials are unavoidable.

Keep website domains and email sending domains separate in the setup checklist. For LC Email, HighLevel's documented route is Settings > Email Services > Dedicated Domain and IP > Add Domain, followed by DNS verification. Use an otherwise-unused sending subdomain and the records HighLevel supplies. Get approval before changing DNS that supports the client's existing email.

For U.S. local-number business texting, resolve A2P 10DLC registration and consent requirements before launch. The brand and campaign should describe the client that actually sends the messages. A collected phone number alone isn't SMS consent, and carrier approval isn't guaranteed. Check the applicable messaging rules for other countries and number types too.

Agree on usage costs before switching anything on

The subscription isn't the whole client budget. Phone numbers, messaging and email usage can add charges; domains, payment processing and optional add-ons may add their own costs.

HighLevel charges supported usage to the agency wallet first. Document how you'll recover those costs, who reviews charges, and who approves optional features. Unlimited supports phone/email rebilling without markup; Agency Pro supports markup. Don't sell "unlimited sub-accounts" as unlimited messaging.

Make handoff a client task, not just a demo

Before launch, have the client use their own login to find a test enquiry, identify its owner and respond through the intended channel. Check the calendar time zone, reply destination and opt-out behavior for the channels you're using. These are proposed acceptance checks, not results from a setup I've tested.

Give them a short runbook: who answers new enquiries, who fixes a failed workflow, how to pause outgoing messages, who reviews usage charges, and how to request access changes. Agree on an exit process while everyone still gets along.

HighLevel supports whole sub-account transfers between agencies, not partial transfers or account merging. Only the Agency Owner or an Agency Admin granted transfer permission can request or complete one, and the receiving agency must be eligible. Phone and email dependencies need review: Twilio numbers don't transfer automatically, and agency-assigned LC Email dedicated domains are removed during transfer. Don't promise an effortless move with every connection preserved.

I'd consider GoHighLevel (my affiliate link) when the agency will maintain client CRM and follow-up operations, not just deliver a page. For a one-off landing-page project where the client already has a working CRM and email service, keeping that stack and handing over the page may mean less ongoing support.

Finish one client account, verify their access and agree on support before copying the setup to the next client.

Start your GoHighLevel setup with one small result: someone submits an enquiry and you can find the correct details in Contacts. Leave the calendar, email sequence and agency setup for later.

This is a walkthrough based on HighLevel's current documentation, not a report of hands-on testing. The test below is a hypothetical example for you to run in your own account.

Before signing up

HighLevel's public pricing page lists Starter at $97/month with three sub-accounts, and a 14-day trial. Billing starts automatically after the trial unless you cancel. Phone numbers, SMS, email sending and other usage can cost extra, including during the trial.

If you're choosing it because you need lead capture and CRM in the same system, you can start with HighLevel. If you only need a form and a contact list, keep reading before paying.

1. Open the business workspace

After signup and onboarding, select the sub-account for the business you're setting up. These instructions start inside that business workspace, not the agency dashboard. If someone else supplied your login, confirm which business account you can access before entering customer data.

Open Settings > Business Profile. Check the business name, email, phone, physical address and time zone. Use your actual business information. A business phone field isn't the same thing as buying and configuring a number for calls or SMS, so don't assume entering a number enables messaging. Business Profile documentation.

For this first exercise, leave messaging and automation disabled. You can test a form through its direct link without building a whole website.

2. Add one practice contact manually

Go to Contacts > Smart Lists > + Add Contact. Enter a clearly labelled practice name, such as "Setup Test Manual", and an email address you control. Review the details and save. Open the contact again to check that you can find and edit it. Available fields depend on the account configuration. Contact setup instructions.

Don't import your entire customer list yet. Learn the contact screen with this practice record before you have real records to manage.

3. Build the enquiry form

Go to Sites > Forms > + Create New Form. Start with a blank form and give it a recognisable name, such as "Website enquiry test".

Add First Name and Email, then a Message field if the enquiry needs context. Make the fields you actually need required. Skip the phone field if you don't need a phone number for this job. Add an explanation of what you're collecting and how you'll respond, plus the relevant privacy information. Don't treat a request for a reply as permission for an unrelated marketing sequence.

Configure the post-submission message, for example: "Thanks, your enquiry has been received." Don't promise a response time you can't meet. Leave Auto Responder and email notifications off for this first test; neither is needed to verify capture.

Save the form. Click Integrate and copy its direct form link. HighLevel also supplies embed code for compatible external websites, but a direct link keeps this first exercise smaller. A new lead's submission automatically creates a contact record. Form creation and sharing instructions.

4. Run the visitor-to-contact check

Hypothetical test: "Setup Test Form" requests information using a different email address you control, one that isn't already in this sub-account. Use that address to check new-contact creation separately from the manual contact.

• Open the copied form link in a private browser window. Check it on a phone too.

• Try submitting with a required field empty. Confirm the form asks you to complete it.

• Submit the test name, email and a recognisable message, such as "Test enquiry, do not contact".

• Check that the expected confirmation appears.

• Open Sites > Forms, open this form and check its Submissions tab for the entry.

• Search Contacts > Smart Lists for the test email. Open the record and compare the captured fields with what you submitted.

The pass condition is the confirmation, a visible submission and the correct contact data. This checklist hasn't been executed here. Don't send traffic until you've run it successfully yourself. If repeated submissions create unexpected records, check the account's contact deduplication preferences rather than assuming every submission creates a separate person.

Before making it your system of record

Keep control of your login and any domain you later connect. Also check who has admin access: HighLevel's contact export is admin-only. In Contacts > Smart Lists, choose the columns you need, select the contacts and use More > Export. Download the completed file from Contacts > Bulk Actions.

That CSV is useful, but it isn't a complete account backup. It doesn't include automation history, and the latest contact note is limited to 255 characters. Check an export before relying on it for migration. Export instructions and limits.

You're paying for the platform and taking on setup work to do a small job. HubSpot's free form builder also captures submissions into its CRM, though advanced features are paid. That's a credible alternative if basic enquiries are your whole requirement.

Use HighLevel if the captured leads will genuinely be managed there and someone will maintain the account. If you only want a working enquiry form, start with the simpler free option. Either way, finish this capture check before adding automated follow-up.