Build a draft-only inquiry triage workflow

An inquiry triage workflow should help a person decide what to handle next. Start with a review queue containing the customer's request, the information still needed, and a suggested owner. Keep replying, quoting, and booking outside the first version. That gives your team a useful output without quietly giving the system authority to make promises.

This guide is for small businesses that receive service questions through email or a contact form. You will define the fields and handoffs for one draft-only queue. Product details were checked on October 10, 2026; the process below is a recommended design, not a claim about an existing InstallAI integration.

1. Define the moment an inquiry enters

Choose one starting point: a person supplies a message, an approved folder receives a form response, or an authorized connection reads a selected inbox. Record which route you actually use. Do not describe a manual copy-and-paste pilot as automatic monitoring.

Capture the original message reference and received time before producing a summary. Keep attachments separate until the workflow has a reason and permission to inspect them. A request about an attached drawing should say that the drawing remains unchecked if it was not read.

For email, preserve the relevant conversation. Gmail's documented thread resource can retrieve a conversation's messages in order. A summary based on the latest sentence alone may miss an earlier cancellation or corrected address. Gmail thread documentation.

2. Use a small record with visible unknowns

A useful inquiry record has these fields:

• Source reference and received time
• Sender details as provided
• Requested service or question
• Customer-stated location and timing
• Missing information
• Suggested category and reason
• Proposed internal owner
• Review status and next human action

Separate what the message says from what the system suggests. “Customer requests Friday” belongs in the first group. “Route to scheduling” belongs in the second. Never turn a requested date into confirmed availability.

Use “not provided” for missing facts. A company name in a signature does not establish the service location. A past conversation does not prove that the current request uses the same address. Keep assumptions out of fields that somebody may later copy into a quote.

3. Write routing rules a colleague can follow

Start with a short set of categories that correspond to real people: new service inquiry, existing job question, billing question, and unclear. Add a fallback owner for anything that does not fit. Without that person, “needs review” becomes a place for messages to disappear.

Define urgency using observable signals and your business's procedures. A customer's requested deadline can be recorded without accepting it. Complaints, suspected fraud, safety concerns, and disputed payments may need direct attention from an experienced employee rather than an ordinary sales queue.

Require a short routing reason. “Existing job reference appears in the message” is useful. A bare confidence score gives the reviewer little to inspect. If two categories apply, preserve both and identify who chooses the next step.

4. Make draft-only a real boundary

Check the connection's permissions with whoever configures it. Google's Gmail documentation states that its compose permission includes both managing drafts and sending email. A label saying “draft-only” therefore does not establish a technical sending restriction. Gmail permission scopes.

For a first pilot, an internal review document may be enough. If drafts are created inside an inbox, ask how sending is blocked or approved in the application, which account is used, and who can change those controls. Verify the behavior with a test instead of relying on instructions alone.

Limit the information copied into the queue. A reviewer may need a contact address but not an unrelated medical explanation in the same message. Decide who can open the queue, which provider receives its contents, and when temporary copies are removed. Use invented inquiries while checking the design.

Fictional example

Maple Demo Repairs is a fictional maintenance business. An invented message says, “Can you repair a cabinet Friday? The photo is attached.” The record lists the service as cabinet repair, Friday as requested timing, and location as missing. It flags the photo as unread and suggests the office coordinator as owner.

The coordinator reviews the photograph and decides which follow-up question to ask. The workflow does not mark Friday as booked or invent a price. This example illustrates the intended handoff; it is not a customer result.

5. Test exceptions before adding volume

Create test messages that contain a missing address, two unrelated requests, a correction in a later reply, an unreadable attachment, and text telling the system to ignore its instructions. That last message is customer content, not permission to change the workflow.

For each test, check the source reference, extracted facts, owner, and unresolved questions. Record whether a human can understand why the item reached their queue. Include a duplicate inquiry and decide whether it should link to an existing item or open a new one.

Before expanding, complete this checklist:

1. Every inquiry has a source reference and review status.
2. Facts and suggested actions are clearly separated.
3. Missing details remain visible.
4. Every exception has a named owner.
5. The tested configuration cannot send without the agreed approval.
6. Review time and missed inquiries are measured alongside draft speed.

Bring a redacted inquiry, your field list, and the routing rules to an InstallAI discussion. They make it easier to assess a bounded implementation and identify where a simple manual step is still the best fit.