Operational Inbox

The operational inbox for work that cannot get lost.

Opkivo turns shared support inboxes into owned threads, safe internal collaboration, linked tasks, and searchable knowledge.

Conversation / context / action / closure

  • Email first
  • One owner per thread
  • Public and internal split
  • Tasks attached to context
  • Built for fast mobile use

Built from the same operational surface: shared inboxes, ownership, tasks, context, and knowledge.

  • Inbox
  • Unassigned
  • Mine
  • Thread
  • Public
  • Internal
  • Task
  • Context Index
  • Knowledge Base

The failure mode

Shared inboxes receive work. They do not finish it.

Most support work starts in email. Then it leaks into notes, chats, calls, spreadsheets, memory, and the ritual of assuming someone else handled it.

01

A customer email arrives.

02

Context moves into chat.

03

A task appears somewhere else.

04

No one knows if it is closed.

Operating rhythm

Conversation to context to action to closure.

1

Conversation

Shared addresses flow into one operational inbox.

2

Context

Every thread gets one accountable owner.

3

Action

Use the Internal tab for notes, tasks, and decisions.

4

Closure

Close the thread when the linked work is resolved.

Product surface

Built around the way small teams actually work.

01

Shared inboxes

Handle multiple support addresses in one place without shared confusion.

02

One owner

New conversations start in Unassigned. A team member takes ownership.

03

Public / Internal

Two tabs keep customer replies and internal collaboration visibly separate.

04

Linked tasks

Create tasks where the work starts and keep them attached to context.

05

Standalone tasks

Detach work when it becomes standalone instead of burying it in a thread.

06

Knowledge

Search support history, internal docs, public articles, entities, and tasks.

07

Search

Find operational work without asking people where something was discussed.

08

Entity context

Link a thread to a customer, product, application, server, invoice, or subscription.

09

Settings

Manage inboxes, routes, signatures, and knowledge setup without enterprise clutter.

Inside the work

Public replies stay public. Internal work stays internal.

Opkivo keeps the operational surface close to the thread: communication, internal decisions, task follow-up, and searchable context.

Public

Customer communication

Public is for replies the customer should see: direct, clean, and attached to the thread.

We found the DNS issue and will send the exact records to update.
Internal

Team decisions and tasks

Internal is for notes, system activity, and task work that should never leak into a customer reply.

  • Check SPF record
  • Update delivery article

Close the thread only when the work is closed.

Opkivo keeps thread-linked tasks connected to the conversation. If open tasks remain, the closing flow makes the decision explicit: review the tasks or close them with the thread.

  1. Open thread
  2. Linked tasks
  3. Review or close tasks
  4. Closed thread

Plans

Start with the inbox count you actually need.

Plan limits are public. Commercial pricing is available by request while access is controlled.

View pricing

Starter

For small teams starting with one operational inbox.

Pricing by request Limits shown publicly
  • 3 users
  • 1 inbox
  • 1 IMAP connection
  • Customer SMTP route
  • 500 storage units
  • 10 assets
  • No public knowledge base domain
Request access

Team

Balanced

For teams running support across multiple inboxes.

Pricing by request Limits shown publicly
  • 5 users
  • 3 inboxes
  • 3 IMAP connections
  • Platform SES and Customer SMTP routes
  • 1000 storage units
  • 100 assets
  • 1 public knowledge base domain
Request access

Business

For teams managing more inboxes, people, and knowledge.

Pricing by request Limits shown publicly
  • 50 users
  • 25 inboxes
  • 25 IMAP connections
  • Platform SES and Customer SMTP routes
  • 5000 storage units
  • 1000 assets
  • 3 public knowledge base domains
Talk to us

Trust model

Designed around the mistake teams cannot afford.

Opkivo is designed around a simple risk: internal work must never leak into customer communication. The product favors clear ownership, explicit tabs, and confirmed context over hidden automation.

  • Public and Internal areas separate customer replies from team work.
  • Clear composer states reduce the chance of sending internal notes to customers.
  • Manual entity linking avoids risky automatic context in the current product.

FAQ

Direct answers before a demo.

Is Opkivo a helpdesk?

Opkivo includes helpdesk flow, but it is better described as an operational inbox. It starts with shared email support and adds ownership, internal communication, tasks, context, and knowledge.

Does Opkivo replace Gmail?

For support work, yes. Gmail can still exist as the underlying mail system, but the daily support workflow should happen inside Opkivo.

Is Opkivo a CRM?

No. Opkivo can link context from external systems, but it does not try to become your CRM.

Does Opkivo use automatic email tagging?

No. Email based automatic tagging is intentionally avoided in the first version because wrong context is worse than missing context.

How does Opkivo separate public and internal communication?

Each thread has two tabs. Public is for customer replies. Internal is for notes, tasks, and team activity. The two areas use different backgrounds and composer modes.

What happens when a thread closes?

If the thread has open tasks, Opkivo asks the user to review them or close the tasks with the thread. Work cannot disappear quietly.

Is pricing public?

Plan limits are public. Commercial pricing can be shown if configured, otherwise visitors can request access.

Own the thread. Finish the work.

Stop using email as a memory system.

Use Opkivo to own the thread, finish the task, and keep the answer searchable.