Accepting applications from the site: from the form to the task of the person in charge

Initial situation

The form on the website sends a letter to a common mailbox - info@ or sales@. Two or three employees had the box open: whoever saw it first answered. Sometimes two people answer, and the client receives two different offers. Sometimes no one responds, because everyone decided that a colleague took the application.

There are other channels nearby. The manager records the call in a notepad and transfers it to CRM in the evening. The message in the messenger is copied by hand. The landing page, which was made by the contractor, is sent to a third address - it was faster to set up.

Time is running out in four places:

• Between form submission and a person's first glance. At night and on weekends - until Monday morning.
• Between “saw” and “took”. There is no responsibility, there is a common box.
• On reprint. From a letter to CRM, from a notepad to CRM, from a messenger to CRM.
• On the search for history. The client calls back a week later, and no one remembers what they talked about.

A separate problem is silence during a breakdown. If the form stops sending emails (the SMTP password has changed, the emails have gone to spam, the endpoint returns 500), they will know about this by a drop in sales in two weeks.

What did you watch?

Diagnostics begins with checking two numbers that must match: how many times the form was sent and how many applications were entered into the system.

• Form submissions —from web analytics (sending target) and from the logs of the endpoint itself. Two sources, because analytics is cut by blockers, and logs do not see cases when the request did not reach the server at all.
• Requests opened —unloading from CRM or tracker for the same period and in the same time zone.

The gap between the numbers is the size of the hole. Then it is disassembled into its components.

It is useful to go through the application path manually once: send a test form and track it through logs, mail, spam folder, CRM. Half of the problems are at this step without any analytics.

What was changed

The order of steps matters: first a reliable technique, then a smart analysis.

1. Own reception point. The form sends a POST to its endpoint. The first step is to write the request to the database in its entirety, as it came - along with headers, UTM tags, page address and time. Everything else is done only after successful recording.

2. Idempotency. The key is calculated from the contact, text hash and time window. A repeated request with the same key does not create a second request. This covers double clicks, browser retries and repeated webhooks.

3. Screening out bots without captcha. Hidden from humans honeypot field and checking filling time. Captcha is enabled only for suspicious requests, so as not to kill the living.

4. Normalization. Phone is brought to a single format, mail is reduced to lower case, UTM is laid out in separate fields. These fields are then used to search for duplicates and create reports.

5. Parsing free text. The model sorts the message into fields: request type, product, urgency, city. A prerequisite is an explicit refusal. There is no certainty - the application receives the “manually sorted” category and ends up in the general queue, and not in a random basket.

6. Routing by rules. A table of the form “category plus attribute → responsible and first response time” is in the config. It is ruled by the head of the department, not the developer. The model prepares the signs, the table makes the decision.

7. Creating a task via the tracker API. The card contains the entire source text, parsed fields, a link to a record in the database, and the deadline for the first response. The original text is required: the parsing may be wrong, the original is not.

8. Automatic response to the client. Request number and response time. The client receives a confirmation; the company receives a common identifier for correspondence.

9. Escalation over time. The card was not touched within the allotted time - notification to the person in charge, then to the general channel, then to the manager. The notification is targeted, mentioning a specific person, otherwise it is read as background noise.

10. Queue and dead letters. Tracker is unavailable - the request remains in the database with the status “not delivered”, sending is delayed with an increasing pause. The retrays are exhausted - an alert to the person. The application is not lost in case of any external system failure.

11. Silence monitor. Separate check: there is not a single request for several hours of working time during normal traffic - signal. Cheaper than any analysis after the fact.

What was not touched

• The form itself. The fields remain the same. Each new required field reduces the number of submissions, and text parsing already provides the necessary attributes.
• Letters to a common mailbox. They are leaving in parallel throughout the entire transition period. Until the new path has worked for a month without failures, the old one remains an insurance policy.
• CRM and tracker. The tool has not changed, only login via the API has been added. Changing the tracker simultaneously with restructuring the reception gives two sources of problems instead of one.
• Manual entry of orders. The manager still creates the card by hand - through the same endpoint, so that the data is in one place.

Reversibility

• Classifier - behind the flag. When disabled, all requests go to a common queue with default routing.
• Auto-create tasks - a separate flag. It turns off, letters continue to flow, work does not stop.
• Routing rules - config for versioning. Rollback is equal to reverting to the previous version of the file.
• Auto answer is the third flag, independent from the others.
• The database of accepted applications remains regardless of any rollback. The data accumulated during the experiment survives the shutdown of automation.

The order of shutdown in case of problems: first auto-response, then classifier, then auto-creation of tasks. Reception and storage are never disabled.

Boundaries

• Few applications. With units of hits per week, the mail filter and discipline give the same result without development.
• Application requires qualifications. When the decision depends on the conversation, routing will speed up the transmission, and the bottleneck will remain in the person.
• Site builders without webhooks. You will have to parse letters, and the mail parser breaks if the template is changed. Works, but requires supervision.
• Personal data regulated. Consent, retention period, field composition and auto-reply content are checked before launch, and not after.
• Responsible people do not respond. Automation will speed up the accumulation of overdue payments and make it visible. Visibility is useful, but the problem is organizational, and it cannot be solved with code.

Rule: the application is first recorded in its own storage, and only then parsed, routed and sent out.