Email and conversations

Ask any small organisation where the record of what was agreed with a customer lives and the honest answer is email. Not the CRM, not the file, not the notes. The substance of the relationship, the promises, the caveats, the thing somebody said they would do by Friday, is in a thread.

That has three consequences and every organisation of a certain size has met all three.

It is invisible. Whoever was on the thread knows. No one else does, including the person covering for them next week and the person who takes over the account next year.

It is unsearchable in practice. Technically an inbox can be searched. Practically, finding what was agreed eighteen months ago requires knowing roughly when and roughly who, and the person who knows both is the one who is not available.

It leaves with people. When somebody goes, their mailbox goes with them, and what the organisation knew about those customers reduces to whatever happened to be written down somewhere else.

Putting the conversation on the customer

Correspondence about a relationship belongs on that relationship. It appears in the timeline in order with the stage changes, the notes, the files and the appointments, so reading a customer record means reading what actually happened rather than a summary somebody wrote afterwards.

The test is the same one the timeline is built for: someone picking up a customer for the first time should be able to read down and know where things stand. Without the conversation, that test fails for most customers, because the interesting part of the history is precisely the part that was in an email.

Without asking anyone to work somewhere new

People keep using their normal mail application. This is not a second inbox to live in, and a product that requires everybody to change where they read email will be abandoned by the third person who is busy.

What changes is that correspondence with the people in your records also lands on those records. The behaviour that used to be a discipline, remembering to copy the important thread into the CRM, becomes something that happens without anyone deciding to do it.

It is worth being explicit about this, because a page arguing that conversations should be shared can easily read as arguing that everything should be.

Correspondence about a customer belongs on the customer. A colleague's private view of a difficult client, a negotiation with a supplier that is genuinely confidential, a conversation with an employee that happens to involve a customer name: those are different, and a system that pulls everything in indiscriminately produces two outcomes, both bad.

The first is that people start using a different address for anything sensitive, which moves the important conversations further out of reach rather than closer. The second is that the record fills with material that should not be visible to everyone who can see the record, at which point sensitivity is doing work it should not have to.

So the judgement stays with the person. What lands on the record is correspondence with the people in your records, and there is no obligation to put everything there. That is a deliberate limit instead of a missing feature, and it is the one that keeps the record trustworthy enough to be shared widely.

There are two things here, not one. A conversation is the unit people work with. A message is one email inside it. Keeping them separate is what lets a thread be assigned, closed and attached to a relationship as a single object, while each message keeps the facts that only belong to it.

What a conversation holds

A subject, taken from the first message. The relationship it concerns, which may be empty. The piece of work it concerns, if somebody has filed it against one: a job, a deal, a matter or a catalogue entry, so the correspondence about a thing sits with the thing. Whether it is open or closed. Who it is assigned to, if anybody. Whether it is sensitive. When the last message arrived, whether that message came in or went out, and how many there have been. Nothing else, because everything else is a property of one message rather than of the exchange.

The direction of the last message is the one field that earns its place twice. It is what the list uses to say that something needs an answer, and it is the reason the inbox can be read at a glance rather than opened one row at a time.

What a message holds

Which way it went. The identifier the mail system gave it. The identifier of whatever it answers. Three addresses. The subject. The plain text body and the markup body. A note of whether it arrived carrying attachments. The verdict the receiving system reached about whether it was spam. And when it happened, which is when it was sent rather than when it was taken in.

Why three addresses

The first version of this stored one. That was the envelope sender: the address the sending server declares, which is the right thing to trust, because it is the address the authentication checks are made against and it cannot be freely chosen by whoever wrote the message.

It is also the wrong thing to reply to. Real mail relayed through a sending service arrives with an envelope of the form bounces at somewhere, which exists to collect delivery failures. A reply addressed there reaches no one at all. That was found by sending a real message through a real relay, which is the only way it could have been found, and it is the reason there are now three fields with three jobs: the envelope is what is trusted, the From header is who the person is and what is shown on screen, and the reply address is where an answer is sent. When a sender gives no reply address, the From header is used. The envelope never is.

What is on screen

The list is conversations in order of what happened most recently, filtered to open or closed, showing the subject, the number of messages, when the last one was, and who has it or the word anyone. Anything whose last message came inbound is marked as needing an answer. Two hundred rows at a time, which is more than any organisation of this size has waiting.

Opening one gives the subject, whether it is open or closed, and either a link to the relationship it belongs to or a line saying that it is not yet matched to anybody you hold a record for. Then the messages in order, each marked as received or sent with the address it came from or went to, and the body shown as plain text.

As plain text deliberately. An email is the one place where a stranger can put markup in front of your staff, and rendering it faithfully is a courtesy extended to the wrong person. The markup body is stored, so nothing is lost, and it is not what is shown.

One thing is recorded and not displayed anywhere today: the spam verdict. It is written down rather than acted on, because deciding what is spam is a judgement an organisation should be able to see and disagree with, and at present it can do neither. What a message arrived carrying is no longer in that category: attachments are listed on the conversation and can be downloaded from it, as files against the record.

Consider a six person joinery workshop. They have a shared address that belongs to their organisation, and two of the six have connected their own mailboxes. A builder they worked with last year is already a record, because somebody made one at the time.

Wednesday morning: the message arrives

The builder writes to the shared address. The address is looked up to find which organisation it belongs to, which is the same check a request from a browser goes through, and nothing in the message itself is allowed to name a database. It is under the size ceiling, so it is accepted. Had it been over, it would have been refused at the door with a reason, so the sender is told, rather than accepted and quietly dropped.

It answers nothing, so it opens a conversation. His address matches a record, so the conversation belongs to that record from its first message. Three things then happen that no one asked for: an entry appears on the builder's timeline saying an email was received and naming the subject, the follow up sequence he was in stops, because he has answered and chasing him now is the fastest way to look automated, and an event is raised that a workflow could act on.

Wednesday afternoon: someone answers

The inbox shows one conversation marked as needing an answer, with nobody assigned. A colleague who has never dealt with this builder opens it, follows the link to the record, reads what happened last year, and replies.

The reply is written into the record first and sent second, and the screen says which of those two things happened. If the sending fails, there is a message sitting in the conversation that visibly did not go, which is something to chase. The alternative, sending first and recording on success, produces a reply that nobody can see and that the organisation therefore never sent either. It goes out from the shared address, so the answer comes back to the inbox rather than into one person's mailbox, and the builder's timeline gains a line saying an email was sent.

Friday: the builder replies and copies his client in

The reply threads, because the builder is already part of the conversation. His client is copied in, and the workshop holds no record for the client. That does not matter for this message: it is taken because somebody known is involved in it.

On Monday the client writes separately, about the same job, from the same address. He is not part of the existing conversation and there is no record for him, so his message opens a conversation of its own with nothing attached to it. Somebody notices, creates a record for him, links the two, and the correspondence appears on his timeline from that moment. Nobody was told to notice. That is the honest half of this example.

The following week: the joiner who handled it is away

A question comes in that needs an answer today. Someone who was not involved opens the builder's record, reads down the timeline, and finds the exchange in order with the appointment and the quotation. They answer without ringing anyone and without asking a colleague on leave to search their own mailbox.

That is the whole return on this feature, and it arrives in one moment rather than continuously. When the job finishes the conversation is closed. Three months later the builder writes again on the same thread, which reopens it, because someone writing back is the clearest possible signal that a matter is not finished.

Three permissions, deliberately separated

Reading a conversation, replying to one, and managing one are three different permissions. Managing covers assigning, closing, reopening and attaching a conversation to a relationship. Templates carry their own pair, viewing and editing, and connecting a mailbox is a permission of its own again.

In the roles the product starts with, a manager and an ordinary member hold all three across the organisation. A restricted member reads and replies but cannot assign, close or attach, which is the right shape for someone who should answer customers without deciding what the queue means. A read only member reads and does nothing. All of these are defaults, and an organisation may change every one of them.

A connected mailbox is always somebody's own

Connecting is granted at the scope of the person's own account, and the list of connected mailboxes is filtered to whoever is asking, always. Disconnecting someone else's is refused, and a mailbox that is not yours answers exactly as a mailbox that does not exist. That is not a permission an organisation can widen its way around, because the filter is applied whatever the role says: a connected mailbox is a personal account, and the list of them is not organisation information.

Sensitive conversations follow the relationship

A conversation on a relationship marked sensitive is only visible to people who may reach sensitive records, and that applies to the list as well as to the conversation itself. A search will not return it either. The point of marking a relationship is defeated entirely if the correspondence about it stays in plain sight.

Which plan

The shared inbox and email integration both begin at Standard, and that is stated on the pricing page rather than discovered. Below Standard, mail sent to your organisation is still received and still recorded. It is reading and replying that are refused. Bouncing a customer's message to punish an organisation's plan would cost that organisation something nobody can give back, so the history accumulates and is there the day they buy the inbox.

A connected mailbox counts against the integrations allowance, which is one on Free, two on Starter, ten on Standard and uncounted above that. Both the feature and the count were once unchecked, which meant a Free organisation could connect a mailbox and as many more as it liked. One person may connect one mailbox per provider per address, because two connections to the same mailbox would take everything twice.

What stays on every plan, including the free one

Every reply sent, every conversation closed, every mailbox connected and every mailbox disconnected is an entry in the audit trail, on every plan, permanently. Consent records and their whole history are on every plan. The complete export carries your conversations and your messages out with everything else. What it leaves behind is credentials: the mailbox tokens, the calendar connection with the tokens that sit on it, and the signing secret on a webhook, which is emptied out of a row that is otherwise carried in full. It also carries what the person running it may reach, so an export run by somebody who holds the export permission without the grant for sensitive records comes out short by exactly the number its manifest declares.

Retention, if you want it

An organisation may set a rule that conversations older than a stated age are cleared: the subject is replaced with a line saying it was removed under the retention policy, the messages are deleted, the relationship is detached and the search entry goes. The shortest rule the product will accept is thirty days, because a rule shorter than that is almost always a mistyped figure and the consequence of a mistyped retention rule cannot be undone.

What the audit trail records is a count rather than a list. An entry naming every record removed under a retention policy would preserve the very identifiers the policy existed to remove, which would make the trail the thing that defeats it.

The feature pays for itself in one moment: someone covering for a colleague opens a record and knows what was promised. That moment arrives most often in construction, where a variation is agreed in a reply and priced from it months later, and in professional services, where the caveat someone attached to advice is the part that matters afterwards.

It matters for a different reason in travel, where one booking is a long exchange of amendments and the person who took it is frequently the person who is away, and in maintenance and facilities, where a problem is reported by email and then reported again by somebody else.

In all four the correspondence is the record, and the ordinary condition is that it leaves with whoever wrote it.