Public and Internal separation
Threads separate customer communication from team work. Public is for customer replies. Internal is for notes, tasks, decisions, and system activity.
Security
Designed to keep public replies and internal work apart.
The main risk in support work is not only losing messages. It is sending the wrong thing to the wrong place.
Clear composer states
The interface makes it clear whether a user is replying to the customer or adding an internal note.
Thread ownership
Every active thread has one owner, so accountability is visible and work does not quietly drift between people.
Access basics
Small teams can manage users and inbox setup without enterprise permission trees. Role and access details should be finalized before public launch documentation is published.
Data separation
Operational areas are separated by intent: inboxes, internal notes, tasks, entities, and knowledge. Final hosting and retention details should be documented before broad commercial rollout.
Backups and reliability
Production backup, incident response, and recovery objectives should be documented here once the deployment architecture is finalized.
Responsible disclosure
Security reports should be sent to hello@opkivo.com until a dedicated disclosure address is published.
Manual entity linking avoids risky automatic context in V1.
Opkivo does not auto-tag email context in the current product. Wrong automatic context creates operational risk, so customer, company, product, application, server, invoice, or environment links are manual or confirmed by the user.
Own the thread. Finish the work.
Review Opkivo with the actual support flow in mind.
Request access to evaluate public/internal separation, ownership, and closure behavior with your team.