Skip to content

Telephony

One of the smallest modules in the system: one log, four settings — and not a single report. It keeps no records and has no documents of its own, because its job is elsewhere: to tie a phone call to the company's work.

A call by itself remembers nothing — you talk and hang up. What remembers is the task born from it. So telephony here does more than "dial a number": a call from a contact or service order card goes out through Binotel, and the system can leave a task for it in the shared work queue of CRM. Incoming and missed calls are not processed yet: the system accepts no events from Binotel, so no tasks will appear for such calls. On its second floor the module holds the SMS channel — the one service uses to tell a customer the repair is ready.

The route: from a call to a task

Binotel Connection (access keys)
        ↓
Binotel Phones: extension ↔ ERP user
        ↓
Binotel Call Actions: what to create when a call happens
        ↓
Task in CRM  ·  Binotel log (written by the system)

SMS: operator (BSG · TurboSMS · Atompark) → service texts and events → encrypt the secrets
  1. Binotel Connection — the foundation: the Binotel access keys and the "Active" checkbox — without it a call is refused. Until the keys exist, the rest of telephony does nothing. The "Test API" button only checks that the key, secret and path are filled in; whether they work, only a real call will show.
  2. Binotel Phones — the table of "extension = ERP user". Without it a call from the system will not go out: it does not know which handset to dial from.
  3. Binotel Call Actions — which task to create for a call made from the system. A task appears only when all three fields on the "On call" tab are filled in — "Employees", "Description" and "Type". The logins from "Employees" become the task's assignees (an executor group code — all of its members), not the person who made the call: that person is the task's author.
  4. Binotel Log — who called from the system, from which number to which, and when. The records are written by the system; nobody types anything in here.
  5. Turbo SMS Settings — access to TurboSMS, the sender signature and the balance (the "Update Balance" button; there is no threshold or block). Which operator actually sends SMS is decided by the "Sender Service" switch in the SMS Notification setting: BSG, TurboSMS, Atompark, or "Automatically" — then the first one configured, in the order TurboSMS → BSG → Atompark. Only TurboSMS and BSG (its token lives in "SMS Notification") can be set up from the menu: the Atompark settings item is switched off in the menu. Who to write to and when is decided by the service's SMS texts.

What is worth understanding

Nobody stores the call — they store its consequence. That is the module's central idea. If "Binotel Call Actions" do not say which task to create, the conversation vanishes without trace and only the fact of the call stays in the log. Configuring that setting is the very reason telephony is connected. Keep in mind that the task is created as soon as Binotel accepts the call, not after the conversation — the system does not know whether the customer answered. If Binotel does not make the call (for example, the extension is unavailable), the user sees the message "Binotel did not make the call: …" with Binotel's own answer, and no task appears.

The commonest breakage is an empty phone mapping. "The call button does not work" almost always means the user has no extension in the table, not a problem on the operator's side.

SMS and telephony are two channels from one module. Calls go through Binotel, messages through the operator chosen in "SMS Notification". What they share is that both are transport for other modules: service decides what to tell the customer, telephony decides what carries it.

Secrets must not sit in plain text. The system encrypts the passwords and keys of the SMS services itself as soon as the setting is saved — and after every key change too. The maintenance routine is needed only by an old database whose TurboSMS or Atompark password still sits in plain text from the time before the settings encrypted it: run it once. An old BSG token and the Atompark web password are encrypted by another one-off routine — Encrypt integration secrets in the System module.

The module is tied to specific providers. Binotel for calls, BSG, TurboSMS and Atompark for messages (Atompark has no settings item in the menu). It is not a universal gateway: another PBX or another SMS provider would need development.

Where to start in a new database

  1. Binotel Connection — the access keys.
  2. Binotel Phones — one line per person who calls from the system.
  3. Binotel Call Actions — which task to leave for a call made from the system.
  4. Turbo SMS Settings — if you need messages to customers.
  5. Encrypt SMS secrets — only if the database was carried over from an old version: new passwords are encrypted when the setting is saved.

Common tasks

You need Where to go
connect telephony Binotel Connection
let a member of staff call from the system Binotel Phones
make a call turn into a task Binotel Call Actions
check whether a call happened Binotel Log
connect SMS messaging Turbo SMS Settings
hide the SMS service passwords in an old database Encrypt SMS secrets
load the mappings in bulk Xlsx Import

Everything in the module

Logs: Binotel Log

Settings: Binotel Connection · Binotel Phones · Binotel Call Actions · Turbo SMS Settings

Maintenance: Encrypt SMS secrets · Xlsx Import · Xlsx Export

Where to look next