Initial situation
The workbox collects everything at once: customer requests, invoices and acts, monitoring notifications, contractor responses, mailings, bank letters, automatic reports. Analysis occurs twice a day - morning and evening - and is based on the person’s memory.
Typical passage: the letter is read, the action is postponed “for later”, the task is not entered into the tracker. After three days the client reminds. Second option: the task has been created, but in one line - “Response regarding integration.” A week later, no one remembers what kind of integration they were talking about or what exactly they asked, and the letter went to the second page of the search.
Losses are collected from three places. The first is the time it takes to sort: identical movements across dozens of letters, of which a minority require action. The second is a disconnected context: the task lives in the tracker, the content is in the mail, there is no connection between them, and every return to the task begins with a search for the letter. Third, late replies: a letter caught between two analyzes remains until the next day, and for an incoming question it is already too late.
What did you watch?
Sorting is automated only after the census. They take two to four weeks of history, a selection of letters, and mark them by hand according to the sender’s intention.
Intent, not keywords. The word “urgent” in the subject line appears more often in newsletters than in letters requiring action. Dictionary classification falls apart within the first hundred letters.
Four baskets: action required, response required, note, trash. Next they consider:
- Share of emails requiring action from the total flow. Usually it is small, and this is the main argument for the filter.
- How many of these letters actually reached the tracker.
- How many tasks in the tracker have a link to the source letter. Checked by searching for a link or letter identifier among cards.
- Median of time from receiving a letter to starting a task.
- How many letters remained unanswered for more than a day.
Separately look at the breakdown by senders: several addresses and domains usually give a noticeable share of the flow and are cut by one rule without any model.
An analysis of the structure is also needed. Are there service headers (List-Unsubscribe, Auto-Submitted, Precedence) that formally separate mailings and auto-replies? Are customer requests sent to a separate address? Does the letter have an anchor identifier - account number, client ID in the signature or in the footer link - by which the letter is linked to a record in the system. Having such an anchor solves half of the matching problem.
What was changed
1. First, deterministic rules. Everything that is cut by the sender's address, domain, service headers and exact subject templates is cut by the rules. Cheap, predictable, debugged in one pass. Mailings, monitoring notifications, automatic reports go under the tags immediately and do not reach the model.
2. The remainder is for analysis by the model. The input includes the subject, sender, text of the letter (trimmed to a reasonable length), attachment names, and the “first in thread or reply” attribute. The output is a rigid scheme: type, urgency, whether a response is required, the essence in one sentence, proposed task title, extracted identifiers (account number, client name, ticket number). The scheme is fixed: there is nothing to parse a free retelling.
3. A draft, not a task. The result is not placed in the working column of the tracker, but in a separate one - “for analysis”. The card contains the gist, a link to the letter, and a suggested title. A person goes through the column once a day and with one movement transfers what he needs, and removes the rest. The decision to create a task remains with the person.
4. A link to the letter is required. The card contains a permanent link to the thread and message ID. Without this field, the card will not be created - otherwise, after a week, again “what kind of integration are we talking about?”
5. Idempotency by thread. Key is the identifier of the thread, not a separate letter. A new message in an already resolved thread does not produce a second card, but adds a comment to the existing one. Running it again using the same email does not duplicate anything, and this allows you to safely restart the parsing after editing the prompt.
6. Attachments are a separate thread. Invoices, acts, contracts are saved in the specified place, the path is placed on the card. There is no need to parse the contents of the attachment in the first step: just deliver the file and not lose it.
7. The schedule is more often than manual analysis. Once every 15–30 minutes instead of twice a day. It is the frequency that shortens the response time, not the quality of classification.
8. Weekly reconciliation. They compare: which cards a person took into work, which ones he deleted without looking, which letters were put into “note” and turned out to be important. An extra card is cheap, a missed letter is expensive, and the threshold is adjusted in this direction: when in doubt, a draft is started.
What was not touched
Sending replies. Parsing, but not responding. An automatic response to a letter whose meaning was misunderstood is worth more than all the savings on sorting.
Deletion and archiving. Maximum action is label or folder. The automation does not send anything to the basket.
Forwarding rules on the side of the mail provider. Permanent forwarding rules, autoresponders and mailbox level filters remain under manual control: they survive the shutdown of any automation and then behave unexpectedly.
Spam filter of the provider. Your classification is placed after it, and not instead.
Priorities and deadlines in the tracker. They are placed by a person. The urgency indicated in the letter is the sender's opinion about his task.
Reversibility
- Tags are removed en masse by searching by tag - a minute operation in any email client.
- Draft cards live in one column, which is cleared entirely.
- The removed schedule returns to the previous manual parsing: mail has not been changed, tasks are in place, nothing needs to be restored.
- Storing intermediate data is limited to what is needed for idempotency: thread identifier, processing time, result. Texts of letters are not written to logs.
- Access to write to the tracker is issued with a separate key with the rights to create cards in one column. Revoking the key is one click, and the analysis stops creating anything, continuing to read.
Boundaries
Boxes with personal data. Before the contents of the letters go into the model, we need answers: where is it processed, what is logged, what is written in consents and contracts. Sometimes the answer closes the topic entirely.
Legally significant correspondence. Claims, notifications, correspondence with government agencies are dealt with manually, without intermediate layers.
Solutions inside a long thread. The model responds well to “what the letter is about” and poorly to “what was ultimately decided” in a thread of forty messages with citations. The mention of the topic and the decision made look the same on the outside.
The meaning is in the attachment. If the essence of the letter is a table in the appendix, and in the body “see. attachment”, classification by text is useless.
Low flow. A dozen letters a day are sorted faster than setting up a conveyor.
A box where everything is important. The personal address of the head of a small company is often exactly this: there is nothing to filter, the entire flow is addressed.
One line rule: mail generates a draft task with a link to the letter, and a person creates a task.