If the identifying reference is only in the attachment, a rule based on the sender and subject may not have enough information. That is a useful boundary to investigate, not a reason to replace every existing mailbox rule.
What can a mailbox rule actually see?
Rules can use fields such as sender, recipient and subject; some also match words in the message body. They are often included in the mail platform, although configuration and maintenance still take effort.
Keyword matching is different from interpreting an unfamiliar invoice or resolving a property reference inside a scanned attachment. Check what the actual mail platform supports before adding another tool.
Where does the catch-all folder come from?
From everything the rules could not place. An application, a rental enquiry, a purchase enquiry, a price change, a listing meant for a different address, and marketing from everyone who ever found the general mailbox.
Here is an illustrative workload: sixty messages needing ninety seconds of manual routing means ninety minutes a day. A pilot should measure actual volume, review time and the share that existing rules already handle correctly.
Why do those hours appear in no report?
Sorting is preparation, so its time can disappear inside other activities. Record a short sample rather than assuming that a busy-looking inbox needs a complex solution.
Once the work is visible, compare options on the same basis: time saved after review, routing accuracy and the cost of maintaining the process.
What are the options once rules stop working?
Options include better rules, structured intake forms, document parsers and model-assisted classification. Choose the simplest approach that can find the necessary information reliably enough.
Reading an attachment adds testing, access and exception-handling work. The benefit must justify that added complexity. A narrow document type is a useful place to test the idea.
What does an assignment with a reason look like?
Not sender equals folder, but: this attachment carries this property reference, therefore this transaction belongs to that account.
The attachment’s reference helps with routing, but sender and authenticity checks still matter. A document containing a plausible identifier should not automatically be trusted, especially where payments or external messages are involved.
What has to be decided before anything is built?
List the permitted destinations. For example: a property’s invoice queue, a departmental task, an approved folder or a colleague’s mailbox. Define which actions are proposals and which may happen automatically.
Agree ownership, access and routing rules before building. The effort depends on how many destinations and exceptions exist. Test the proposed mapping against real examples with the people who receive the work.
What happens when the assignment is uncertain?
Uncertain cases should stay visible for review. Missing identifiers, conflicting records or unreadable attachments are reasons to stop, not to invent a destination.
A confidence threshold can help, but it is not the whole gate. Validate identifiers, required fields and permitted actions as well. Record why the case stopped and who should resolve it.
Do the existing rules have to go?
No. Keep the rules that already work. Add interpretation only where it solves a measured gap, and preserve a clear way to disable or reverse the new routing.
A sensible first project shrinks the share that needs manual sorting without hiding mistakes. Track routing accuracy, time per message and the age of unresolved exceptions.
