Gmelius, Drag, and Keeping: what a layer over Gmail is built to do, and what sits outside it

There is a category of shared inbox tool that gets less attention than it deserves, mostly because it is unglamorous: the extension that installs into Gmail and adds team features to the interface your people already live in. Gmelius, Drag, and Keeping are the best known. They are inexpensive, they install in an afternoon, and they have the highest adoption rate in this entire market for one plain reason. Nobody has to learn anything.

That is a real virtue and not a compromise, and we will spend the first half of this article saying so, which is unusual for a vendor's comparison page. We build Sektra, which is not an extension, so the second half is where we describe the job that sits outside this design. Judge the first half on its merits and the second half with the appropriate raised eyebrow.

What are Gmail layer tools?

A Gmail layer tool is a browser extension or add-on that renders new functionality inside the Gmail interface rather than replacing it. Your mail does not move, your team does not switch apps, and the shared inbox features appear as additional controls on the screen they already stare at all day: assignment, status, shared labels, internal notes, and a view of who is handling what. Underneath, it is still Gmail, and if the extension were uninstalled tomorrow the mail would sit there unchanged.

That is the whole architectural bet, and it distinguishes this group from both the standalone platforms, which ask your team to move into a new app, and from tools that sync with Gmail while keeping their own workspace. Three tools dominate the group and they are less interchangeable than the category label suggests.

Gmelius: the most feature-complete, and the most ambitious

Gmelius is the one that grew past the category. Alongside shared inboxes and shared labels it carries email sequences, automation rules, and kanban boards, which pulls it toward outreach and sales workflows as much as team support. It is priced accordingly, roughly $19 to $40 a seat, at the top of the extension group and overlapping the bottom of the standalone platforms. If you want one Gmail add-on that does collaboration and sequences and you would rather not run two tools, it is the obvious pick in this group.

Drag: boards first, and the cheapest way in

Drag turns the inbox into a kanban board, and for teams that already think in pipelines the fit is immediate: work in progress becomes visible at a glance, which is something a list of threads never quite manages. It is also the least expensive serious option in the category, starting around $12 a seat, which makes it the straightforward answer for a small team that wants shared assignment without a budget conversation.

Keeping: support desk shaped, inside Gmail

Keeping is the most support-flavored of the three. Tickets, assignment, statuses, response tracking, and reporting, all rendered in Gmail rather than in a separate helpdesk. It suits a small team fielding customer requests who want helpdesk discipline without asking anyone to log into a helpdesk. Pricing starts near $12 a seat with agent caps on the lower tier.

What the layer approach genuinely gets right

Three things, and they are not small. Adoption, first: the failure mode that kills most shared inbox rollouts is that half the team drifts back to their personal inbox within a month, and an extension is immune to it because there is nowhere to drift back to. Cost, second: this is the cheapest tier of the market by a wide margin, and for a five-person team the annual difference against a standalone platform is thousands. Speed, third: install, configure shared labels, done before lunch, with no migration and no data project.

If your problem is that two people keep replying to the same customer email and nobody knows who owns what, this category solves that problem completely, at the lowest price and the lowest risk available. A team in that position should buy one of these three and stop reading comparison articles, including this one.

The job that sits outside the layer

This is a design boundary rather than a defect, and it is worth naming precisely because it is easy to mistake for something a future release will cover. An extension's unit of work is the thing on the screen: the thread, the label, the card, the status. It organizes what is in front of you, and it does that well. What it does not carry is a second model of the relationship behind the thread, because the architecture is deliberately thin. The layer renders the mailbox, which is exactly what it set out to do.

Three things follow from that choice, and they show up in the same order for every team that grows past this category.

• Resolution is the end state, by design. A thread marked done leaves the board, and the commitment inside it leaves with it. That is correct behavior for a queue, where finishing is the goal. It becomes a gap when the promise to send revised numbers by Friday was a clause in paragraph two of a message that every system you own now considers complete.
• Retrieval is search, and search starts with already knowing. Everything about the relationship is genuinely there in Gmail, which is a real strength of keeping mail where it lives. It becomes available the moment someone thinks to look and knows the phrase to look for. The context that costs you is the context nobody knew to search for.
• The trigger is always an arriving message. Every feature in this category responds to inbound, which covers the work that shows up. It leaves one event unrepresented: a client who wrote every Tuesday for two years and then writes nothing generates no message, so no label, board, or status has anything to react to.

None of this is a criticism of the engineering, which is good, or the pricing, which is fair. It is a description of what the category was built for. These tools organize today's mail across a team and they do it at the lowest cost and risk available. Holding two years of a relationship in a form someone can use on the way into a call is simply a different product.

Which side of that boundary are you on?

Pull last quarter's inbound and check how much of it came from people who had written to you before. If most of your mail is new names with solvable problems, you are running a queue, this boundary is nowhere near you, and the cheapest tool that does assignment well is the correct answer. If the same forty or fifty names write to you month after month, year after year, then your inbox is a book of relationships that happens to be delivered as email, and the boundary is the thing you have been running into.

The second test is to name your worst miss from the last six months. If it was two people answering the same thread, or a request that sat unassigned for a day, an extension fixes it outright and fixes it cheaply. If it was a promise nobody remembered, a question that aged quietly inside a thread that looked handled, or a client who drifted for two months before anyone noticed, then the information needed to catch it was never on the screen in the first place, and no amount of labeling puts it there.

Where Sektra fits, and where it does not

Sektra takes the third architectural option: not an extension, and not a migration either. It is its own workspace that syncs two-way with your team's Gmail accounts, so mail stays in Gmail, nothing is exported or imported, and setup is a Google sign-in that takes about 90 seconds. You get the same collaboration essentials the extensions offer, including assignments, mentions, internal notes, and collision detection.

What the extra architecture buys is the model that a thin layer has no room to hold, and it is worth being concrete about it. Sektra reads the Gmail history you already have and maintains a live record for every client. Commitments in both directions, extracted from the prose rather than from anyone remembering to log them, with what is coming due surfaced before it slips. Client questions still waiting on an answer, including the ones sitting inside threads that already got a reply and therefore look handled. And each relationship's own contact rhythm, so an account falling below its personal baseline is flagged while the silence is still recoverable, which is the single event no inbound-triggered tool can see.

On top of that record, an AI Copilot answers any question about any client, which is precisely the part that removes the need to know what to search for. Where do we stand with Meridian, what did we promise them this quarter, why has Aldrin gone quiet: questions you would otherwise take to whichever colleague has been here longest. And because the record is read backward through mail you already have, it arrives populated, including for relationships years older than the tool, so a new joiner opens an account they have never heard of already briefed.

The honest tradeoff is that Sektra is a separate workspace, which is a larger behavioral ask than an extension and a smaller one than a migration, and it costs more than Drag or Keeping. If your requirement really is shared labels at the lowest possible price, buy the extension. The two-week parallel run playbook is the cheap way to find out which description fits you, since running both at once costs nothing when the mail lives in Gmail underneath either way.

Which one should you pick?

• Pick Drag if you want the cheapest credible shared inbox in Gmail and your team thinks in boards and pipelines.
• Pick Keeping if you are running small-team support and want helpdesk structure without a helpdesk.
• Pick Gmelius if you need collaboration and outreach sequences in one add-on and can carry the higher seat price.
• Pick Sektra if your inbound is repeat clients and your expensive misses are forgotten promises, aging questions, and accounts going quiet.
• Pick a standalone platform like Front if your mail genuinely has to route across departments with SLA policies attached.

The extensions are not a budget version of the platforms. They are a good answer to a different question, and the only real mistake available here is answering the question you did not have.