From web form and email to CRM: automating inquiry handling

Inquiry handling automation collects every incoming request from your web form, email and messaging apps into one queue, lets an AI model qualify each one and draft a reply, and sends nothing until a person approves it. It is for small companies where inquiries land in several inboxes, get answered differently depending on who is on duty, and are sometimes forgotten.

Key takeaways

• Capture first: one queue for every channel is worth more than any AI step.
• Qualification is a draft, not a verdict: the model proposes type, urgency and what is missing; a person confirms.
• The reply is drafted in your voice from your past replies and approved before it is sent; CRM updates and follow-ups run after approval.
• State a response time you can meet; do not promise what the system cannot guarantee.
• Inquiry data is personal data: decide purpose, retention and access before the first inquiry is stored.

Step one: capture every inquiry in one place

Most small companies receive inquiries through several doors: the website form, a general email address, WhatsApp, the owner's personal inbox and phone, each with its own way of being lost. The first step is a single intake:

• The web form posts to the system directly, or the form service forwards each submission.
• The shared mailbox is connected so that messages matching simple rules (not newsletters, invoices or internal mail) become inquiries.
• WhatsApp is connected through the official WhatsApp Business Platform or a provider built on it; messages become inquiries with the conversation attached.

Each inquiry is stored with its source, timestamp, contact details and full text. Duplicates are matched by email address or phone number, so the same person writing twice becomes one conversation. If this is all you build, you have already improved on the inbox.

Step two: AI qualification as a draft

Once an inquiry exists, the model reads it and proposes a qualification: a short, fixed set of fields the owner defined in discovery, for example:

• What is being asked for: a quote, a product question, a support request, a partnership.
• Which product or service it concerns, matched against your list.
• What is missing to answer it: quantity, location, deadline, budget, a file.
• A suggested priority, based on rules you set, such as existing customers first or deadlines mentioned.
• A short summary for the person who will handle it.

Every field is a proposal, shown to the reviewer next to the original message and changed with a click. The point is to save reading and sorting time and to give every inquiry the same first look whoever is on duty. An inquiry the model cannot classify goes to the top of the queue marked for a person.

Step three: a drafted reply the owner approves

The model then drafts a reply from your own material: past replies you were happy with, your product descriptions, your standard questions for a quote, and your rules about what not to promise.

The draft acknowledges the request in your tone, answers what can be answered from your own data, and asks for the missing information identified in qualification. It does not quote prices or delivery dates unless those come from your systems as data and you have allowed them.

In the approval queue the reviewer, usually the owner or the person who handles sales, sees the inquiry, the qualification, the draft and the proposed CRM changes on one screen, and can approve, edit, or take over personally. Only after approval is the reply sent, through the channel the inquiry arrived on.

This is where the time is saved: reading, sorting and writing a first reply are the slow parts; approving a good draft takes seconds. Because the reviewer sees every reply, the voice stays consistent and nothing is promised that the owner would not promise.

Step four: CRM update and follow-ups

After approval, the deterministic steps run:

• The contact and the inquiry are created or updated in the CRM, whether a dedicated CRM, a shared spreadsheet or an operations tool.
• The qualification fields become CRM fields, so the pipeline can be filtered by type, product and priority.
• A follow-up is scheduled: if the customer has not answered within a period you set, a reminder goes to the owner or a short follow-up draft is prepared for approval.
• Every action is logged with who approved it and when.

Follow-ups are where many small companies lose business, not from lack of care but because nobody remembers. A scheduled reminder with the conversation attached changes outcomes.

Response-time expectations

Automation changes what you can promise, but be careful. We suggest two commitments:

• Acknowledgment. An automatic confirmation that the inquiry was received, with the time frame in which a person will reply. It needs no AI and should never pretend to be a personal reply.
• Reply. The approved, drafted reply. The time frame you state should reflect when your people actually review the queue; if that is twice a day on working days, say so.

Do not state a response time in minutes if no one reviews the queue at night. After a month the system can report your actual times; set expectations from those.

GDPR basics for inquiry data

An inquiry contains personal data: a name, contact details, often details about the person's needs. Processing it falls under the GDPR (Regulation (EU) 2016/679, https://eur-lex.europa.eu/eli/reg/2016/679/oj). Settle these basics before the first inquiry is stored:

• Purpose and legal basis. You process the data to answer the inquiry and, if it leads somewhere, to do business with the person. Document this; do not add the person to a newsletter because they asked a question.
• Information. The privacy notice linked from your form should say what you collect, why, how long you keep it and who processes it on your behalf, as Articles 12 to 14 require.
• Data minimization. The model receives only what it needs to qualify and draft, not the person's full history.
• Storage limitation. Decide how long inquiries that led nowhere are kept, and have the system delete them after that.
• Processors. The form, mail, messaging, AI and hosting providers are processors. Each needs a processing agreement under Article 28, and you should know where they store data.
• Access. Only the people who handle inquiries see them; the approval queue should respect that.

How we do it at Hot Skulls Labs

Inquiry handling is where we usually suggest a company starts, and it is the pattern our own product, Strady, was built around: a pipeline, an approval queue and an AI assistant that briefs the owner on what is waiting.

In practice:

• Discovery maps your actual channels and past replies; without written replies, we start from how you answer on the phone.
• Capture is built first and can run before any AI step is added. Qualification fields are the ones your pipeline needs, not a generic lead score.
• Every reply is approved by a person at launch; automatic sending for specific low-risk reply types is a choice you can make later.
• We connect to the CRM you have, including a spreadsheet; a different tool is your decision, not a prerequisite.
• Systems are hosted in the EU, and the data flow is designed with the GDPR in mind from the first session: what the model sees, where data lives, when it is deleted.
• We keep running the system after launch and adjust qualification and drafts from what reviewers edit and reject.