Chat, meetings, routing and follow-ups in one place

Live chat on a website, meeting scheduling and recording, routing a request to whoever owns it, and the follow-up that goes out afterward. That sentence describes four different jobs, usually done by four different kinds of product.

Each happens in a different place. Chat happens on your website. Meetings are booked through a calendar and held on a call, sometimes with a notetaker recording them. Routing and follow-up handle the requests that arrive afterward, by email and in team chat. You can buy products to handle all four from one vendor. But when researchers traced why companies answer slowly, each cause they found could hold up the handoff after the conversation, while a request waited to reach whoever owned it. That’s why routing and follow-up are the two jobs worth handling in the same place.

The four jobs

Live chat on your website. A script tag puts a widget on your pages. A visitor types and an operator answers, but outside working hours the widget takes an email address instead. Intercom, Crisp, Tidio and HubSpot all sell a version of it. A new visitor stays anonymous until they give their email address, so the conversation starts with no history attached.

Meetings: booking and recording. To book a meeting, you send a link to a page showing your availability, the other person picks a time, and the tool sends both of you a confirmation and a reminder before the call. Calendly, Cal.com and HubSpot’s meetings tool all work this way. Recording is a separate job. A notetaker such as Granola, Fathom, Otter or Fireflies joins the call and emails a summary afterward.

In Microsoft 365 telemetry published as Breaking down the infinite workday, Microsoft found that 57% of meetings are ad hoc calls with no calendar invite. Booking software never sees those, so scheduling touches at most the smaller share of a week’s meetings, while the follow-up problem applies to all of them.

Routing. Routing gets a request to whoever owns it. Usually a person reads the request and passes it on. Automatic routing skips that step: a CRM can hand new leads to sales reps in turn, an on-call rotation sends urgent issues to whoever is on duty, and a shared mailbox tool can assign incoming email by rules you set.

Follow-up. Follow-up is what goes out once the conversation ends, such as the quote, the recap, the answer somebody promised or the nudge to a prospect who went quiet.

Handoffs can delay a reply

In a 2011 Harvard Business Review article, Oldroyd, McElheran and Elkington audited 2,241 US companies by sending each one a web-generated test lead. 37% answered within an hour, 16% within one to 24 hours, 24% took longer than a day, and 23% never answered at all. Among the companies that did reply inside 30 days, the average took 42 hours.

A second study from the same article followed 1.25 million sales leads across 29 B2C and 13 B2B companies. Firms that tried to reach a prospect within an hour of the query were nearly seven times as likely to qualify the lead, which the authors defined as a meaningful conversation with a key decision maker, as firms that tried an hour later. Against firms that waited a day or more, they were over 60 times as likely.

Two caveats apply to both studies. The data is from 2011. And David Elkington, one of the three authors, was chairman and CEO of InsideSales.com, which sold lead-response software, so a vendor had an interest in the finding.

The authors name three causes. Companies pulled leads out of CRM databases once a day instead of continuously. Sales forces put generating their own leads ahead of answering the ones that came in. And leads went out to agents and partners by geography and by rules about fairness. All three can cause failures of routing and handoff.

Customer service email is slow too. SuperOffice sent one customer service email to each of 1,000 companies. 62% never replied, and the average response took 12 hours and 10 minutes.

What belongs in one place

Routing and follow-up both need the same two facts: what the customer asked for, and who owns it now. Neither stays in one tool for long.

A chat widget records the conversation it hosted but has no record of the email thread that continued it after the visitor closed the tab. A notetaker documents what happened on the call but has no record of the contract question that arrives by email the next morning. Routing from either one is routing with incomplete information, which is how a request ends up with somebody who has to ask the customer to repeat themselves.

So the consolidation worth making is one system that reads the inboxes and team chats where requests land, turns each one into a piece of work with an owner, and runs the follow-up off the same record. Chat and meeting tools can stay where they are, because both can feed that system by email. A chat tool can send you the transcript, and the notetaker sends the summary.

What this+that does

• Gmail, Outlook, Slack, Microsoft Teams, and Google Chat in one app. Each keeps its own stream, and a request that arrives in team chat gets handled the same way as one that arrives by email.
• A task with an owner. DoBox reads the conversation, pulls out what it asks for, and puts it on a board with the thread attached. Assign it to one person or several, and reassign it whenever.
• The follow-up as a workflow. Triggers include an email sender, domain or label, a chat message, a DoBox event such as an approval, a new contact, a schedule, or a click to run it by hand. From there it can branch on a condition, loop over a list, use AI to make a judgment call mid-run, draft the reply, update a connected tool over MCP, and hold anything that needs a person in an Approvals section before it goes out.
• A published page with a booking widget on it. A page in your Brain can be made public, and a published page can include a live booking widget so a visitor books against your real calendar.

We hold SOC 2 Type I as of July 31, 2026, with Type II underway, and CASA Tier 2. The security page covers what connecting a mailbox involves.

How a meeting follow-up runs

Your notetaker emails the summary when the call ends, and that email is the trigger. A workflow matches the sender, reads the notes, creates a DoBox task for each action item and assigns it to the person the notes name, drafts the follow-up to the attendees, and waits for your approval if you told it to. It can also write the decisions to a page in the Brain, so the next call with the same people starts from them.

A prebuilt template already pulls tasks out of meeting summary emails, so you can start from that. If you use Granola, a workflow can also reach its notes directly, because Granola is one of the built-in MCP connections.

Meeting follow-ups describes the full process, and lead routing covers the inbound side.

Five questions before you consolidate anything

1. Which of the four jobs is slow? Time the handoff rather than the tool. If the widget answers instantly but the email reply takes days, a faster widget changes nothing.
2. Where does the conversation go when it leaves the widget? If it’s email, whatever reads that email owns the follow-up, no matter what you bought the widget for.
3. Does the routing check who owns the relationship? Geography and fairness rules were among the causes in the 2011 HBR study.
4. Can a person stop it before it sends? Anything that emails a customer on your behalf should have an approval step until you trust what it writes.
5. What happens when a similar request comes in? The same workflow should run again, without anyone setting it up twice.

Frequently asked questions

Can one vendor really do all four jobs? A customer platform such as HubSpot sells chat, meetings, email and automation in one account, and for a team whose inbound all arrives through its forms, chat and shared inbox, that’s a reasonable purchase. Check which of your channels it reads before you assume it’s settled, including the Slack where partners message you and any mailbox nobody has connected.

Does this+that replace live chat? No. It reads what the chat tool emails you and handles what comes next. The conversation with the visitor stays in the widget.

Does this+that transcribe meetings? No. We read the notes email your notetaker sends and work from that.

Can this+that put any of this on our website? One piece of it. A Brain page you make public can include a booking widget, so a visitor picks a slot against your real calendar from a page you wrote.

In this+that, does routing go to a person or to a workflow? Both, and the choice is yours per case. A task lands with a person when a person has to decide, and a workflow takes it when the steps are known. Approving or rejecting what a workflow produced is itself a trigger, so the handoff back doesn’t need anyone to chase it.

If routing and follow-up are the slow part, connect the inboxes and chats where your requests land. Get started with this+that.