An email answered by a chat message stays one conversation in Point. The context stays in one place. Your mailbox holds threads together with identifiers written into message headers, and a message on another channel never carried one, so Point makes the join a level above the mailbox.
- The mail, the answer that came back on chat, the deadline that fell out of it and the meeting it produced all sit under one heading. One conversation instead of two half-records.
- Point makes the join on who the conversation is with and what it’s about. That’s why it holds when the conversation moves.
- Your addressing stays as it is. A chat message is answered as a chat message, an email as an email, from your own address on the account your clients already write to.
- Two channels, named plainly. Your mail, on the Gmail or Microsoft 365 account you already have. Your firm’s own chat, which runs inside Point rather than through an outside service.
- The limits are honest ones. A message you lock stays sealed and unread, and a channel Point can’t see stays outside the thread.
What one conversation looks like when it changes channel
Here’s the ordinary version. It happens most weeks, and it stays in your head rather than on paper.
A client emails on Monday about moving a deadline. You need a number from your colleague before you can answer. You ask on chat, and the answer comes back there, two lines and a date. On Wednesday the three of you settle a time to talk it through. By Thursday there’s a task with your name on it, and it came out of the chat rather than the mail. Four objects, three surfaces, one piece of work.
On Friday morning you want to see that as one thing. In Point you do. An email answered by a message stays a single conversation, and the context stays in one place. The mails stay with the answer that arrived on the other channel. The task with its date and the meeting they were all about stay there too. They’re held together rather than filed as strangers.
In practice you see a summary with one phrase in it doing more work than the rest. One click on that phrase opens a short brief drawn from every source: the mails behind it, the task Point pulled out with its due date, and the meeting one click further on. Mail, task and meeting, in one account of what’s going on, instead of four fragments you assemble in your head each time you come back.
That assembling is the cost nobody bills for. It happens every time you open one of the four and try to remember the other three. It’s worst on the mornings you’re already behind. It’s why a job that’s going fine can feel like it’s slipping.
Why your mail app cannot do this by itself
Every mail client you’ve tried gets this wrong. The reason sits in the standard rather than in anyone’s effort.
An email thread is a chain of receipts written into the messages themselves. The rules are public, and your mailbox follows them rather than inventing them. RFC 5322 is the standard that defines what an internet message is. It asks each message to carry a unique identifier of its own. “Though listed as optional in the table in section 3.6, every message SHOULD have a ‘Message-ID:’ field” (RFC 5322, section 3.6.4, checked September 6, 2026). A reply quotes that identifier back, and the standard spells out how. “The ‘In-Reply-To:’ and ‘References:’ fields are used when creating a reply to a message. They hold the message identifier of the original message and the message identifiers of other messages”. The standard says outright that “the ‘References:’ field may be used to identify a ‘thread’ of conversation” (same section, checked September 6, 2026).
So a conversation, in email, is a rope made of quoted identifiers. Both providers build their own idea of a conversation on top of it. Google’s is that “The Gmail API uses the threads resource to group email replies with their original message into a single conversation or thread” (Google for Developers, checked September 6, 2026). A thread is defined simply as “A collection of messages representing a conversation” (Google for Developers, checked September 6, 2026). Microsoft’s mailbox holds the same idea in two fields on the message. A conversationId is “The ID of the conversation the email belongs to”, and a conversationIndex “Indicates the position of the message within the conversation” (Microsoft Graph, checked September 6, 2026). The same page records the underlying identifier as internetMessageId, “The message ID in the format specified by RFC2822” (same page, checked September 6, 2026).
Two things follow from that. The second is the one this page is about.
The first is how narrow the conditions are even inside email. Google’s own criteria for a message joining an existing thread are that “The References and In-Reply-To headers must be set in compliance with the RFC 2822 standard” and that “The Subject headers must match” (Google for Developers, checked September 6, 2026). You’ve watched that fail. Somebody edits the subject line to add a client’s name, and Thursday’s reply arrives looking like a conversation that started on Thursday.
The second is that the rope is made of email and only email. RFC 5322 spells out the consequence. “If there is no ‘Message-ID:’ field in any of the parent messages, then the new message will have no ‘In-Reply-To:’ field” (checked September 6, 2026). A line of chat has no Message-ID for a reply to hold on to, and it never did. Your mailbox is doing its job when the two halves sit apart. It has one field for the header chain and none for the join, and the chat message has none either.
That settles where the work has to happen. The join is made above the mailbox, out of the two things both halves genuinely share. The same people, and the same subject.
The two channels this actually covers
Worth being exact about, before you rely on any of it.
Your mail, on the Gmail or Microsoft 365 account you already have. Your mail stays where it is and your address stays your address. What a connection actually does to each provider is published in full: connecting Gmail, and what stays exactly as it was for Google, and the Outlook path, from mailbox to calendar for Microsoft.
Your firm’s own chat, which runs inside Point rather than through mail or an outside chat service. It’s live and two-way. A message is on the other person’s screen the moment you send it. Groups work the same way, and even a thumbs up travels. It’s the channel your team already uses for the two-line questions that are too small for an email, sitting where the mail is instead of one application over.
Two other things arrive in the same conversation. A meeting that gets settled becomes a real event on the calendar the account already owns. An ask that lands in either channel becomes a dated task. Both are sources the thread draws on rather than channels people reach you on.
Now the boundary, stated once. Point covers those two channels and stops there. There is no WhatsApp lane, no SMS lane, no third-party team chat piped in. If your clients reach you on WhatsApp or by text as often as by mail, you’re shopping in the wrong category here. Point vs Missive lays out what a many-channel inbox gives you and what it charges you elsewhere. The argument for running mail and one internal channel in a single ranked list, instead of two applications that each think they’re the important one, belongs to chat and email in one ranked feed.
The person the thread belongs to
The join is made on who a conversation is with, so it’s only as good as the answer to who that is. Your address book is the wrong place to ask.
Most owners have the same client stored three or four times. The work address, the address at the firm they left, the phone contact, the misspelled fourth entry from an import somebody ran in 2019. Connect an account and those collapse into one person on the way in. Your own records stay exactly as you left them. That resolution, what it leaves alone, and what it costs to correct when it guesses wrong is merging duplicate contacts, and what your address book keeps. It’s the load-bearing piece under this page. A conversation stays whole across two channels because there’s one person for it to stay whole around.
The other half of the join is the subject. That’s the part a header chain was never able to carry. Three emails, a task and a meeting about the same order are one piece of work, even though no two of them share a Message-ID. Point marks the concept inside the summary and tracks it across every source. The brief you read is drawn from all of them rather than from whichever one you happened to open. Every line of it has a source behind it, and the source is one click away.
That’s a judgment rather than a lookup. It’s the honest way to describe it, and it’s also the reason it can be wrong. What that failure looks like, and why it’s cheap here, is further down.
Same reading, whichever pipe it came down
One thread is only worth having if the whole of it has been read. Both halves have been.
A chat message lands in the feed like any other message, weighed and placed rather than queued in a second application. The row you see carries Point’s own summary of it rather than the raw chat text. Open it and the summary card is there in context, with the original one click away. The same treatment the email above it got.
The commitment gets the same handling too. An ask typed into chat, order the spare converters by Thursday, comes out as a task. It carries a due date, a priority and where it came from, tracked exactly like a deadline that arrived by mail. One tap takes you back to the words that produced it. Triage, summary, task: the channel never mattered.
On a working day, the pipe stops setting your priorities. A colleague’s two lines and a client’s letter are placed by what they’re worth and when they’re due, rather than by which application made the louder noise. That’s chat and email in one ranked feed in full. And what an obligation becomes once it’s lifted out of the sentence that carried it is turning an email into a task.
Answering something that arrived two ways
Once you believe the first part, the next question is the same every time. Which channel does my reply go out on?
The one the message came in on. A chat message is answered as a chat message. An email is answered as an email, with its subject line, its recipients and its place in a thread. Somebody may have to produce that thread in eighteen months. The addressing conventions stay exactly as they are, because those conventions are what makes an email producible later.
What the single thread buys you is the part you were holding in your head. Point holds the two halves while you write. With the conversation open, a short instruction is enough. Point already knows which thread you’re looking at, so a line from you comes back as a full draft. It’s addressed to the right person, on the right thread, in your voice. It goes from your own address rather than from anything of Point’s. If you run more than one business, every card names the business it belongs to. The reply leaves inside that one, and the account is already chosen for you, which is keeping two businesses apart.
Whether a draft like that waits for you is something you set. You set it per kind of action rather than once for everything. The dial runs from suggest-only through review to handled outright, and replying starts on review. The words are ready, and the send is still a decision you make. Where each position leaves you, and where the dial stops, is setting how much your inbox does on its own.
Putting it away, and finding it again in March
One conversation is one decision when you’re done with it. And one place to look when it comes back.
Filing works on the whole conversation. The conversation leaves the feed, and the email half is archived in your real mailbox in the same moment. Nothing is deleted, and nothing moves into a folder with a product’s name on it. That write, in both directions, is filing a thread in Point archives it in Gmail too. The chat half has no mailbox to be archived into, and that costs you nothing, because your mailbox never had a row for it in the first place.
Finding it again is where the join pays for itself a second time. One search box covers mail, tasks, calendar and files together. A client’s name returns the messages, the task, the meeting and the file side by side, instead of four searches in four places. Ask a plain question rather than guessing at keywords, and the answer comes back as an answer, with the receipt attached. One click and you’re on the original message, checking the number yourself.
There’s also a switch for the days you want less. The feed drops out of ranked order into plain time order, mail and chat together. A filter narrows it to mail only, and the chat threads drop out. A small dot on the filter reminds you something is switched off. That’s the right shape for this. One thread by default, and one channel at a time when a particular hour calls for it.
Where one thread stops
Four of them, worth reading now rather than discovering one on a bad morning.
A message you lock stays sealed. Sealing a message in the composer encrypts it on your device before it leaves, and it opens on the other person’s. Point reads none of it in between. The cost is stated rather than hidden. That message gets no summary, no new judgment and no task lifted out of it. It still sits in the conversation, carrying a lock where the rows around it carry summaries. A thread with one in it has a deliberate gap in what Point can tell you about it. When that trade is worth making is confidentiality and the AI in your inbox.
A channel Point can’t see stays outside the thread. The call you took in the car, the text to your cell phone, the corridor conversation. None of it reaches Point, so none of it joins the thread. The durable move there is the old one. Put the obligation somewhere dated rather than trusting anyone to remember it. A task you create yourself sits in the same list as the ones Point pulls out of messages.
Two people can read as one. A married couple who run a business together, or two people at a client with the same surname, can be resolved into a single person on evidence that genuinely points that way. Then a thread joins something it should have left apart. You tend to notice weeks later, as a summary mentioning a project the client has never heard of. The repair is cheap, because the resolution is a reading rather than a rewrite of your records. What changes is Point’s view, and everything at Google and Microsoft stays exactly where it is.
A two-line agreement is still a two-line agreement. Joining the halves puts both sides of it on one screen, and what saves it is the obligation coming out as a dated task. What that costs a firm of five when it goes wrong is when an email falls through the cracks between you.
What the mailbox keeps and what only Point holds
The last question is the fair one to ask about any layer. What does your account look like underneath if the layer goes away?
Your mail is untouched by any of this. A Gmail thread is still a collection of messages held together by the header chain. A Microsoft conversation still has its conversationId. Both are exactly as complete as they were before anything was connected. Every message, in order, with the Point triage name on it, readable by somebody who has never heard of the product.
The join is the one thing that stays behind, and the reason is structural rather than a decision anybody made. Neither mailbox has a field meaning this email was answered on another channel, so there’s nowhere to record it. Your team’s chat stays in Point for the same reason. The email half is whole, and it’s whole on its own terms. That’s all a mailbox was ever asked to be.
So Point holds exactly one thing here, and every other part is yours already. What Point holds is the conversation as a single piece of work. It’s assembled out of mail your provider keeps, chat that lives in Point, a calendar you own and tasks pulled from both. End the connection and the mail sits where it always sat. The calendar keeps its events, and the assembling stops. Losing that is a genuine loss, and it takes nothing of yours with it. That’s the trade you want from any layer. What the layer does while it’s there is set out in everything Point does.
Common questions
What counts as a channel here?
Two of them. The mail on the Gmail or Microsoft 365 account you already use, and your firm’s own chat, which runs inside Point rather than through an outside service. A meeting and a task are sources rather than channels, and both are drawn into the same conversation when they belong to it. Anything else a business can be reached on, including WhatsApp, SMS and third-party team chat, sits outside this and outside Point.
Can Point pull my WhatsApp or text messages into the same thread?
No. Point is a layer over the mailbox you already have, and a channel Point can’t see stays outside the thread. If a real share of your inbound arrives by text or on WhatsApp, that’s a different category of software, and it’s worth choosing on purpose rather than hoping an email client grows into it. What does work is putting the obligation from that call or that text into a dated task. It then sits in the same list as everything the messages produced.
Does a chat message really get the same treatment as an email?
Yes, and the row in the feed is the check. What you see is Point’s own summary rather than the raw chat text. It’s placed by what it’s worth and when it’s due, rather than by which channel carried it. The summary card and the original are one click away. An ask inside it comes out as a task with a due date and a link back to the words that created it, tracked exactly like a deadline that arrived by mail.
If I file a conversation that has both email and chat in it, what happens in Gmail?
The email half is archived. In a Gmail mailbox that means it leaves the inbox and waits in All Mail, with nothing deleted and no new folder created. The chat half has no mailbox to be archived into, and it never appeared in one. Your inbox count drops by the conversation, and the two piles still agree with each other by Thursday.
What happens to a message I have locked, inside a thread like this?
It stays in the conversation, and it stays unread by Point. A sealed message is encrypted on your device and opened on the recipient’s. It gets no summary, no new judgment and no task extraction, and the row carries a lock where the others carry a summary. The thread is still one thread. It simply has a section in it that Point leaves alone, and that’s the trade you made when you locked it.
If I stop using Point, does the conversation come apart again?
The email half never depended on Point, so it stays a complete thread in your own mailbox. In order, with the labels or categories still on it. What goes is the join, because no field in a Gmail or Microsoft mailbox could ever hold it. Everything of yours stays. Your address, your history, your calendar and your contacts were on your provider’s account the whole time.