A quote request form that reaches the sales inbox

A quote request form that reaches the sales inbox

To have a quote request arrive as an email in a shared sales inbox, set the workflow's output to email and give it the address. Each accepted submission is then sent as a message from your own connected Gmail account to that inbox, carrying the answers and any attachment the customer sent.

The distinction that makes this useful is that the email is the record rather than a notification about one. A notification tells you something arrived somewhere else and gives you a link to go and look. This arrives complete, in the place your team already works, and can be replied to.

Delivery, not notification

Most form tools send you an alert when a submission lands. That is a different thing, and the difference shows up on the day you are busy.

A notification is a message about a record. It is usually sent from the vendor's own address, it often summarises rather than includes, and replying to it does nothing useful — it goes back to a no-reply mailbox or to the tool. To act on it you follow a link, sign in, and read the real record somewhere else. That is three steps between a customer's question and your answer, and each one is a place the enquiry sits overnight.

An email output has none of those steps. The message contains the submission, it comes from an address at your own domain, and hitting reply composes a message to the customer from your own account. Nobody signs in to anything. The enquiry can be answered by whoever opens it first, which is exactly how a shared sales inbox is supposed to work.

The mechanism is worth stating plainly because it explains the behaviour: Webtzm holds a narrow authorization to send mail on your behalf, and sends through your Gmail. So the address is yours, the sending reputation is yours, and the sent message is subject to your own retention and discovery rules like any other mail your business sends.

The form

<form action="YOUR_SUBMIT_URL" method="POST"
      data-webtzm-form="YOUR_WORKFLOW_ID">
  <input name="company" placeholder="Company" required>
  <input name="name" placeholder="Your name" required>
  <input name="email" type="email" required>
  <input name="phone" type="tel">
  <select name="service">
    <option>Installation</option>
    <option>Maintenance contract</option>
    <option>Something else</option>
  </select>
  <textarea name="detail" placeholder="What do you need?" required></textarea>
  <input name="drawings" type="file" accept=".pdf,.jpg,.png">
  <p data-wtzm-send-status></p>
  <button>Request a quote</button>
</form>
<script src="YOUR_SCRIPT_URL"></script>

A quote request is the one enquiry form where an attachment earns its place. A photograph of the thing that needs fixing, or a drawing of the space, removes an entire round trip of questions before anyone can quote. Attached files that are not executables ride along with the email, and everything goes to the workflow's Drive folder as well, so a large drawing is still reachable when the message has scrolled away.

Make the subject line do work

This is the highest-value ten minutes available here, and it is the part people skip.

A shared inbox is triaged from the subject line alone. A subject of "New form submission" forces every message to be opened before it can be sorted, which in practice means they are opened in the order they arrived rather than the order they matter. Put the fields that decide priority into the subject — the company, the service, and anything that separates a maintenance renewal from a new installation. Whoever is on the inbox can then act on a screen of subjects without opening any of them.

The body deserves the same restraint. Lead with the answers that decide the reply and put the rest below. A quote is written from four or five facts; the message should present those first.

What an inbox is bad at

Being honest about this is the difference between a workflow that lasts and one you regret in six months.

An inbox has no state of its own. There is no status, no owner, and no reliable way to answer "how many quotes are open" or "which of these has nobody replied to". Teams work around that with flags, labels and folders, and those work exactly as long as everyone applies them consistently, which is until the first busy week.

An inbox is also poor at counting. How many requests came in last month, which service they were for, how many converted — these are spreadsheet questions, and reconstructing them by searching a mailbox is miserable work that people quietly stop doing.

And an inbox forgets. A message that scrolls off the first screen during a busy morning is, for practical purposes, gone. A row in a list is still there.

A workflow delivers one output, so this is a genuine choice. If your team answers quickly from a shared mailbox and nobody is asked to report on volumes, email is the right answer and a spreadsheet would be an extra place to look. If anyone tracks or reports on these enquiries, deliver to a Sheet and let notifications tell people to go and look. Two workflows on two forms is fine; one workflow cannot do both.

Send to a group address, not to a person

Point the workflow at a shared address — sales@, quotes@, a Google Group — rather than at whoever currently handles quotes. It costs nothing to do at the start and is tedious to undo later.

The reason is turnover of every kind: someone goes on holiday, changes role, or leaves. A workflow addressed to a person keeps delivering to that person's mailbox long after they stopped being the right recipient, and the failure is silent — the mail arrives successfully, into a mailbox nobody is reading. A group address is changed by whoever administers your mail, without touching the form, the workflow, or the page it sits on.

It also makes the enquiry visible to more than one person, which is the entire argument for a shared inbox. A quote request sitting unanswered in an individual's mail is invisible; the same request in a group inbox is somebody's to pick up.

Two things that go wrong

• Filters and the shared inbox. Mail sent from your own domain into your own shared inbox sometimes lands somewhere unexpected, because rules written for internal mail catch it. Send a real test through the live form and confirm where it arrives before you trust the route.

• Reply-to expectations. The message comes from your connected account, not from the customer, so a reply composes to whoever the workflow sends as. Check that the address your team hits reply against is the one you want the customer to see, and put the customer's own address in the body where it is easy to copy.

When to use something else

Use a CRM if quotes are a pipeline. Stages, owners, follow-up reminders, a value against each opportunity and a forecast at the end of it are a real product, and a shared inbox is not a substitute once more than a couple of people are selling.

Use a helpdesk if the volume is high and the work is queue-shaped. Assignment, SLAs and a record of who answered what are exactly what an inbox lacks, and they are what those tools are for.

Use a form builder's notification emails if you already have one and the alert-plus-link pattern genuinely suits you. Plenty of teams are happy with it.

Take this route when a small team answers quote requests directly from a shared mailbox, wants the enquiry to arrive complete rather than as a link, and wants the reply to come from their own address so the customer sees a person rather than a tool.