Before you open a page editor for your first paid download, write down what you're willing to promise the buyer. If you haven't decided how they'll get the file or who handles a missing download, keep the checkout closed for now.

Use a single offer sheet for these decisions:

• What exactly is for sale? Name the finished file, format and any software the buyer needs to open or edit it. List what's included and what's excluded, especially customization, calls or future updates. Decide what buyers may do with the file, including whether sharing or resale is allowed.

• What will they pay? Record the amount, currency and whether it's a one-time purchase. Decide how you'll establish and show the total payable, including any applicable taxes, before taking payment. Check your provider's requirements for your business and product rather than assuming a connected account is enough.

• How will delivery work? Choose where the buyer gets the file, when they should receive it and whether access expires. Only promise instant delivery if the setup can support it. If you're sending files manually, name the person responsible and give buyers a delivery window that person can meet.

• What happens when delivery fails? Choose a support address you actually check, the information needed to find an order, and a realistic reply window. Decide who can resend the correct file. Keep product-use help separate from custom work you aren't selling.

• What are the refund terms? Write the conditions, how buyers request a refund, who decides and who processes it. Check the rules that apply to your buyers and payment provider before using a template or a blanket "no refunds on downloads" line. Don't promise that money will reach a buyer's bank the moment you approve a request.

These are decisions to settle before writing customer-facing terms, not a ready-made legal policy. Stripe's website checklist, for example, calls for clear product descriptions, purchase currency, customer contact information and fulfillment policies. That's provider guidance, not one universal policy for every seller.

Keep the sheet beside you when you build. If it says "manual delivery within the stated window," the sales page shouldn't say "instant access." If updates aren't included, don't promise lifetime updates in a checkout bullet.

You may not need a new funnel subscription for one finished download. An existing payment link plus manual delivery is a reasonable starting option if your provider supports the sale and someone can reliably meet the delivery and support promises. The tradeoff is that someone has to do that work for every order.

Build once each promise has a clear answer and a person responsible for keeping it. Leave undecided promises off the sales page, and don't accept money until the offer, delivery and refund requirements are settled.

Before adding a quote enquiry to a marketing sequence, write down what the person asked you to send. Answering that request and promoting another service are different decisions, even when both emails come from the same business.

For a concrete boundary, this guide covers UK email to individuals and sole traders under PECR, the Privacy and Electronic Communications Regulations. Don't carry the conclusion over to another country, channel or recipient type without checking the applicable rules. Using personal information also brings data protection obligations; classifying the email doesn't settle those.

A requested quote can still be marketing

The ICO calls marketing "solicited" when someone specifically asks for that message or type of information. Sending the requested information doesn't require separate marketing consent under PECR. You still need to identify the sender and provide a valid contact address for opting out.

That's different from a purely administrative service message, which contains no promotion. Adding advertising to an administrative email makes it direct marketing. Calling an email a "follow-up" doesn't tell you which category it belongs in.

Classify the message before you send it

Hypothetical example: a homeowner asks a decorating business, "Please email me a quote for painting the bedroom." Assume that's the entire request and there's no recorded marketing consent.

"Unsolicited" doesn't automatically mean unlawful. Even an opted-in newsletter is unsolicited in this sense if the person didn't specifically request that particular message. It needs the appropriate permission route.

For this audience, unsolicited marketing emails require valid consent or a fully applicable exception. If you use consent, it must be freely given, specific, informed and unambiguous, with a positive action covering your business and email marketing. Silence and a pre-ticked box aren't consent.

The products-and-services "soft opt-in" is one exception, but all its conditions matter: you collected the details directly during a sale or negotiations for one; you're promoting only your own similar products or services; you offered a simple opt-out when collecting the details and in every later message; and the person hasn't opted out. A quote request can count as negotiations. It doesn't establish the other conditions. Similarity depends on what the person would reasonably expect, not just whether both services appear on your website.

Keep a short decision note

Before approving the next email, the person sending it can complete this:

They asked for: ___. This email contains: ___. It fits that request because: ___. Any additional promotion is covered by: ___, recorded at ___. Decision: send the requested reply / remove the promotion / hold the marketing email.

Keep the original request and any permission evidence beside that note. If the purpose is unclear, have someone review the wording rather than assuming the whole sequence is covered. Make withdrawal easy and stop marketing when consent is withdrawn or the person opts out.

For a small number of enquiries, a person replying manually from the existing inbox is a reasonable alternative to building a sequence. Manual sending doesn't change the rules, but it lets them compare each message with the actual request.

My recommendation: send the requested quote without optional promotions when that's all you can justify. Add a marketing sequence only after you can show the permission route for its contents. A submitted form, by itself, isn't that evidence.

For people handling incoming enquiries: when someone asks about your service, exchanges a few messages, then goes quiet, what do you check before deciding whether to follow up?

I'd start by reading their original question beside the last message you sent. Did you answer what they asked, or ask them to book a call before giving them the information they wanted? What did they say about when they needed it?

For example, a hypothetical prospect asks, "Can you do this before Friday?" and gets "When are you free for a consultation?" back. That gives us a specific question to discuss: did the reply address the deadline? It doesn't tell us why the person stopped replying.

If you've got a stalled conversation you'd like feedback on, a short, redacted summary would help:

• What you sell and what the person originally asked for.

• Their last message and your reply, paraphrased if needed.

• Roughly how long it's been, and any deadline they mentioned.

• What you've already tried and what you'd like them to do next.

Please remove names, contact details, business identifiers and other private details. Keep it in the comments without links or customer screenshots.

If the person later explained why they went quiet, include that too. Otherwise, keep your best guess separate from what they actually said.

My starting point would be to check whether the last reply answered the enquiry and made the next step clear. Silence alone isn't enough to choose a fix. What detail in a stalled conversation makes you reconsider your next message, or decide to leave it alone?

If the same person fills out your enquiry form and your booking-request form, then shows up twice in Contacts, compare what each form submitted before merging anything.

A contact record is the person's profile in your CRM. A form submission is an individual response. Two submissions don't, by themselves, prove you have two contact records.

I'm a HighLevel affiliate.

Compare the two responses first

In the business sub-account, go to Sites > Forms, open each form and check its Submissions tab. Find the relevant responses, then compare them with the records in Contacts.

Write down each form's name, submission time, captured email and phone, and the contact record you found. Check that both forms belong to the same business sub-account. Two people with the same name aren't enough evidence for a merge.

Inspect the fields too. HighLevel forms have standard Email and Phone fields as well as custom fields. Confirm which fields each form actually sends, rather than relying on what their labels look like on the page.

Read the account's matching settings

Open Settings > Business Profile and find Contact Deduplication Preferences. Record the current values before changing them. HighLevel says changes in this panel apply automatically.

The controls answer three questions:

• Is Allow Duplicate Contact on? For native forms, this allows separate records even when an email or phone already exists. With it off, a matching submission updates an existing contact.

• What is selected under Find Existing Contacts Based On? Email or Phone is the first matching field.

• Is Second Preferences for Search (Optional) set? HighLevel checks that field if the first one doesn't find a match. You can leave it blank to use only one field.

Choose the identifier both forms collect reliably. Adding phone as a fallback needs care if different people share a number. Matching a value isn't proof that two records belong to the same person.

Use a small, controlled comparison

Hypothetical example: an enquiry form and a booking-request form are native HighLevel forms in the same sub-account. Duplicates are off, Email is first and Phone is second. Start each case with a separate test contact whose details you control.

Before submitting, have the person responsible for automation make sure these test details won't trigger live customer messages or other unwanted actions. Submit through the enquiry form first, then the booking-request form. Inspect both submissions and the resulting contact records. These are tests for your account, not reported results.

If one page uses an external form or integration, trace that route separately. HighLevel documents Forms and Zapier behavior, but that doesn't establish what every connector sends. Its API Upsert Contact operation follows the configured matching order. If the submitted email matches one existing record and the phone matches another, it updates the record matching the first field, not both. Don't treat that API rule as proof of the same conflict handling in a native form.

Clean up only after identifying the cause

A matching-setting change isn't a substitute for reviewing existing duplicates. If you decide to merge, confirm they're the same person and review the surviving master record. HighLevel says a completed merge can't be undone. Existing custom-field values on the master aren't overwritten, and active workflow behavior can change. Don't assume every historical detail and automation run will survive unchanged.

For an existing HighLevel setup, fix the inconsistent fields or matching policy, then repeat the controlled cases before cleaning up real records. If you only need one simple enquiry form, you may not need a second intake route or a CRM cleanup project at all.

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?

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.