A client writes wherever it is convenient for them: email, a messenger, the site chat, or they call. The usual trouble is that these approaches scatter across different windows and nobody sees the whole picture. Here everything converges in one place: an approach from any channel becomes a conversation, and the channel itself is merely its property. You look into one shared list and see who is waiting for an answer and for how long.
One conversation model
An approach is a conversation: correspondence with a person that has a beginning, a continuation and a result. It does not matter whether it is an email, a messenger message or the site chat: the conversation has one history, one set of participants, one owner. Thanks to this the client does not have to repeat themselves: you see everything they wrote to you in one place.
The shared inbox
The shared inbox is the whole team’s workplace: all approaches in one list, with the marks “mine”, “unclaimed”, “by channel”, “by client”. A conversation has a state — new, in progress, waiting for the client, resolved. It shows who answered last and when, so there are no two replies to one email and no abandoned approaches: if nobody took it, that is visible.
There is honesty about availability too: it is visible who is at the screen right now and who is not — so an approach does not land on a person who is away. All state changes and decisions are recorded, so any post-mortem always shows what happened.
Reaction deadlines
The clock starts at the moment the approach arrives, not at the moment somebody decides to take it. This is a matter of principle: the client waits from the first minute, and the metric must reflect exactly that. A breached deadline becomes a separate fact with a history entry, not “just an overdue line in a report”.
Mailboxes connect over the ordinary IMAP and SMTP protocols (the standard ways of receiving and sending mail that every mail program uses). Once connected, the correspondence appears in the conversations by itself: emails attach to clients, reply chains merge into one thread, and attachments land in the card. There can be several mailboxes — one for sales and one for service, for example; and the channel shows it is alive: when the last synchronization ran and whether there was an error.
Mailbox passwords are stored encrypted and cannot be read back. Senders you do not want to see go on the deny list. There are also mail parsing rules: by which sign an email counts as a service approach, and by which as ordinary correspondence.
Telephony
About calls it is most honest to say it straight: the product does not call by itself. It carefully joins with your telephony service — the call log, cards with the talk history, a “call” button in the interface. Call recordings and the text transcript are drafts for a human check: the automation can be wrong, so the final word always belongs to the employee who listened or read.
The legal part is kept separately: why we record, how consent was obtained, how long we keep. And access to the recordings is not uncontrolled: it is visible who listened to a talk and when. This is needed both by law and by common sense.
Messengers
Messenger correspondence goes both ways: messages arrive into the shared list and leave from it too. WhatsApp is arranged as configurable data: the channel’s rules, the window when the client may be answered, the cost of messages — all of it lives as settings, not wired into the code. There are fuses too: bulk or too-frequent messages do not go out blindly; every attempt has a record with the refusal reason.
Let’s be honest: the product does not support unofficial ways of working with WhatsApp (through automating the web version) — only legal ones. It is a limit, but there is no risk of losing the account.
The site widget
A small chat is installed on the site — one line of code. It is built honestly: it first asks consent to process the data, sets no third-party tracking files and sends nothing outward. A visitor can write before becoming a client — the approach lands in the shared list and links to the person as soon as they can be identified. The look and the greeting are configurable too.
Bots
The first thing a visitor sees can be answered automatically: hint the prices, the working hours, the address, collect the first details. Such auto-replies (usually called bots) are built honestly: every step offers an exit to a live human, and no conversation is held in automatic mode against the visitor’s will. It is visible at which step people most often give up and leave — a ready list of what to finish or fix.
Calendar
Meetings live where the approaches live: the client and the deal show all the upcoming work. Separately there is meeting booking: the client picks a free slot themselves, and the product makes sure two people do not sit in the same slot — a booking is indivisible, there is no “half a booking”.
An honest boundary: exchange with external calendars (Google, the corporate one) is one-way — you can pull busy slots from another calendar, but there is no full two-way synchronization. Said up front, so nobody is surprised.
Notifications
All important events gather in the bell at the top of the screen — a list, not pop-up hints that vanish. What was read stays read: the product does not “guess” for you. What to report about and where is configurable — inside the product or as a digest email.
Conversation privacy
Clients’ correspondence is sensitive data, so access to it is limited on all screens, not just the main one. Addresses and phone numbers can be hidden from part of the staff; there is a shared deny list and an access log: to whom and when the closed details were shown. All of it is stored on your server, not on ours.
Social networks
Social networks connect as message sources: approaches can be taken from there and answered within what the platform itself allows. An honest boundary: not everything and not everywhere — different platforms have different rules, and part of the capabilities needs external services. The product does not promise “one window into all the world’s social networks”: it gives what works reliably and honestly lists what is missing.
Add-ons
Communications are eight independently switchable add-ons: the shared inbox, email, calls, messengers, the site widget and chats, the calendar, notifications and privacy. You can take only email and the shared inbox and switch the rest on later; a disabled add-on stops being shown, but the data stays. How this works is described in Add-ons & Product Composition.
An important property of this arrangement: even without these add-ons the product does not break — it simply works the old way. Email and correspondence keep writing into the client’s timeline as before, and the conversations and the shared inbox appear when you switch the add-on on.