One category of shared inbox tool is easy to overlook, because it adds no new app. It is the extension that installs into Gmail and adds team features to the interface your people already open. Gmelius, Drag, and Keeping are the best known. They are priced from about $12 a seat, they install in an afternoon, and nobody has to learn a new screen.
The first half of this article describes what that design covers. We build Sektra, so weigh our own section accordingly. Sektra is not an extension, and the second half describes the job that sits outside the extension design.
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 and your team does not switch apps. The shared inbox features appear as extra controls on the screen they already stare at all day. Those cover 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 architectural bet. It separates this group from 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 widest feature set of the three
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 at roughly $19 to $40 a seat, at the top of the extension group and overlapping the bottom of the standalone platforms. The sequences and automation are aimed at outreach, which is a different job from keeping track of the clients who already write to you.
Drag: boards first, and the cheapest way in
Drag turns the inbox into a kanban board, with emails as cards and stages as columns. Work in progress is shown by column rather than as a list of threads. It is priced from around $12 a seat, the lowest entry price in the category. The board shows which stage a thread is in, not what was promised inside it.
Keeping: support desk shaped, inside Gmail
Keeping is the most support-shaped of the three. Tickets, assignment, statuses, response tracking, and reporting, all rendered in Gmail rather than in a separate helpdesk. It is built for a small team fielding customer requests as tickets. Pricing starts near $12 a seat with agent caps on the lower tier.
What the layer approach is built around
Three things. The first is adoption. The failure mode that kills most shared inbox rollouts is half the team drifting back to their personal inbox within a month. An extension avoids that, because there is nowhere to drift back to. Sektra takes the same risk off the table by syncing with Gmail, so a teammate who has not moved yet still works from the inbox they already open.
The second is price. This is the lowest-priced tier of the market, and for a five-person team the annual difference against a standalone platform is thousands. The third is setup time. Install, configure shared labels, and the extension is running the same day, with no migration and no data project. Sektra's setup is a Google sign-in of about 90 seconds, with nothing migrated either.
If your problem is that two people keep replying to the same customer email and nobody knows who owns what, this category covers it. So does Sektra, with assignments, mentions, internal notes and collision detection in every plan. The difference is what happens after the thread is marked done, and that is the second half of this article.
The job that sits outside the layer
This is a design boundary rather than a defect, and it needs naming 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, meaning the thread, the label, the card, the status.
It organizes what is in front of you. What it does not carry is a second model of the relationship behind the thread, because the architecture is thin by design.
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 there in Gmail. 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. It is a description of what the category was built for. These tools organize today's mail across a team. Holding two years of a relationship in a form someone can use on the way into a call is a different product. That product is Sektra.
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 and this boundary is nowhere near you. Assignment and shared labels are the whole requirement, and every tool on this page covers them, Sektra included.
If the same forty or fifty names write to you month after month, year after year, your inbox is a book of relationships delivered as email. 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, assignment and collision detection fix it. Every tool here has them.
Other misses look different. A promise nobody remembered, a question that aged inside a thread that looked handled, a client who drifted for two months before anyone noticed. The information needed to catch those was never on the screen, and no amount of labeling puts it there.
Where Sektra fits, and where it does not
Sektra takes a third architectural option, neither an extension nor a migration. It is its own workspace that syncs two-way with your team's Gmail accounts. 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. Sektra reads the Gmail history you already have and maintains a live record for every client. It holds 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.
It holds client questions still waiting on an answer, including the ones sitting inside threads that already got a reply and therefore look handled. Ask the assistant to watch a relationship and it alerts you the day the client has been quiet for longer than you set. That is the one event no inbound-triggered tool can see.
On top of that record, the assistant answers any question about any client, which removes the need to know what to search for. Where do we stand with this account, what did we promise them this quarter, why has that client gone quiet. Those are questions you would otherwise take to whichever colleague has been here longest.
Because the record is read backward through mail you already have, it arrives populated, including for relationships years older than the tool. A new joiner opens an account they have never heard of already briefed.
The tradeoff is that Sektra is a separate workspace, a larger behavioral ask than an extension and a smaller one than a migration. It is also priced above Drag or Keeping, because the plan price includes the client record and the assistant. The two-week parallel run playbook is the cheap way to find out what that buys you, since running both costs nothing when the mail lives in Gmail either way.
Which one should you pick?
- Drag is priced from about $12 a seat and shows the inbox as boards. Sektra shows the same threads by client, with what was promised and what is still open attached.
- Keeping runs tickets and statuses inside Gmail for small-team support. Sektra keeps assignments and statuses too, and adds the record of the client behind the ticket.
- Gmelius adds outreach sequences to the shared inbox at a higher seat price. Sektra is built for the clients who already write to you rather than the ones you are chasing.
- Sektra is the pick if your inbound is repeat clients and your expensive misses are forgotten promises, aging questions, and accounts going quiet.
- Front routes mail across departments with SLA policies attached, on a tier that needs configuring. Sektra assigns and tracks without a workflow to design.
The extensions are not a budget version of the platforms. They answer a different question, and the only mistake available here is answering the question you did not have.
