Customer correspondence inside the project, not only in a mailbox

Correspondence with the customer is the largest part of a project that the project itself knows nothing about. Decisions, requests and files sit in one person's mailbox, and whoever was not on the thread simply never saw them.

One mailbox, and a choice by who is writing

A Gmail mailbox is connected through an ordinary consent: no passwords, no handing over an account. Then you choose what exactly comes in: a full address or a whole domain. Each rule has its own direction (incoming only, outgoing only or both) and a date below which nothing is pulled.

Direction follows the mailbox owner, not the rule

A detail that looks technical and is not. A letter from an outside person on a shared thread, where the mailbox owner sits only in copy, looked to the @domain rule as if it were ours, and was marked outgoing. Since then direction follows the owner: they are in From, so it went out; otherwise it came in, no matter which rule brought the letter.

This is not code tidiness. «We wrote and they never answered» and «they wrote and we never answered» are two different jobs, and the second is the embarrassing one.

Files come in with the letters

An attachment is usually the substance of the letter, so it is stored and read. Content is extracted from PDF, Word, Excel and text; a scan with no text layer goes through character recognition.

And the file name alone is not enough. Gmail hands over a letter's embedded images named attachment with no extension at all (5,853 of them on the live project, all PNG), and while the type was decided by extension only, they were not read at all, silently. Now the name is asked first, and when it says nothing, the declared type is asked.

There are three outcomes rather than two: either there is content and we know how to get it, or it is decoration from a signature, or it is a format we do not read. The last two are both «not processed», but for different reasons, and adding them together in a reconciliation hides which one to fix.

Loading again does not create duplicates

The same mailbox is loaded more than once: a rule is added, a date corrected, a month that looks incomplete fetched again. Every letter carries the provider's identifier, and on our side that identifier is unique: a letter already in does not come in a second time.

Without that, every correction to a rule would double a whole month, and the mailbox would grow by itself each time somebody touched the settings.

Loading also resumes where it stopped: a cursor is kept, so a break halfway through does not start everything over.

A letter attached to a task

A letter does not have to stay in the mailbox: it can be attached to a task, and then it is read alongside that task's history. «The customer asked for this by email» stops being a claim and becomes a link.

Who spoke, not only what was written

Every participant on a thread is stored as a person rather than an address string. From there the reverse direction opens: open a contact and see which threads they were on.

Sifting: what is worth reading at all

Not every letter is work. A list of subjects that are known noise is kept (18 at present), and incoming letters get a tone assessment: what is being asked and how urgently. Orders of magnitude: 2,209 letters marked.

Before any call to a model the text passes through identifier masking: national id, phone, address. The model sees the letter without the details that identify a person.

What the customer sees

Nothing. The mail screens belong to the provider, and the customer portal has no mail screen at all. This is not a setting anyone can forget to switch: there is no such page there.

How this differs from a shared inbox

A shared inbox asks you to move your work into it. Here the mailbox stays yours, and only what you chose enters the project, together with its files, its people and its threads. You go on writing from the same place you wrote from yesterday.