Custom automations
Triggers, conditions, delays, approvals, versions, tests and a stop; authorised client apps, limited tokens and signed web callbacks — under the same action rules as everywhere else, with a readable diagnostic when something jams.
My software is not in the list
Your tool has no page here: the result is written into Zenvox, in full native mode. What it takes to qualify it, and why a portal is not automated by default.
7 days, 20 answered calls, no card
Where your result lands in the meantime
The result is written into Zenvox: the request, the appointment, the reason for calling, the recording and the transcript. Native mode is complete — it is not a reduced version waiting for something better — and it runs with nothing connected at all. Your software keeps the truth of what it already holds, and the receptionist hands you the work where you are.
What an owner is not asked for comes down to three things: no key to create, no connector to program, no development written to order. When a published interface does exist, the clean road runs through an authorised client app, limited tokens, signed web callbacks and your own rules — not blanket access to all of your objects.
One rule guides what follows: a general category is not enough to qualify anything — you need a named product, its edition, and the person who holds the account. And a portal that opens in a browser is not an interface: a screen built for a human being is not a permission.
Read, create, update, cancel
As long as a product has not been named and qualified, this matrix describes a method rather than a connector. It says, action by action, what a qualification looks at and what happens in the meantime — because that is the real question an owner asks when he does not see his tool in the list.
| Action | Status | What that means |
|---|---|---|
| Read | To qualify | This is the first thing a qualification examines: does your software publish a documented interface, does your edition give you access to it, and who holds the account that would authorise it? Three answers are enough to know whether the rest is worth doing. |
| Create | To qualify | Writing is qualified after reading, in that order. What gets checked at that point: which objects can genuinely be created, how the interface behaves when the same request is sent twice, and what happens when your software refuses it. |
| Update | Zenvox native mode | Until the contract with your software is established, updating lives in your workspace: the request changes state there, with its history, and you carry it across to wherever you work. That also avoids the worst case, which is two tools editing the same file without knowing about each other. |
| Cancel | Zenvox native mode | Cancelling touches states that your software controls, and sometimes that carries billing consequences. Zenvox records the cancellation request, flags it and passes it to you. Driving a portal built for a human being automatically is not the default behaviour: an approved import or a human step is planned instead. |
What is included, what needs an add-on
Your whole base works without connecting anything at all: answering, qualifying, taking the appointment, sending the summary, routing it to the right person. No capability in the base depends on third-party software, and that is deliberate. What does need an add-on is assembling your own rules and wiring up your own applications.
The authorisation, and what holds the truth
Here is what you will be asked for if you want your software qualified, and the limits that are set in advance.
- Name the product, its edition and the person who holds the account: a general category cannot be qualified
- A portal that opens in a browser does not count as an interface: it takes a published interface and an authorisation that can actually be granted
- Your vendor may be a competitor, a customer, or simply closed to outsiders: that is a possible answer, and we say it rather than work around it
- When no interface exists, an import you approve or a human step replaces the automation, and that remains a good outcome
- Your workspace holds the truth for the request and its history; your software keeps its grip on whatever it already runs
- Buying an interface does not open access to every object: the rights stay the ones your scope gives you
A business whose order tracking lives in an in-house system with no published interface. Nothing is connected: the receptionist works in native mode and routes.
CustomerHi, I am calling to find out where my order stands.
ReceptionistLet me take your name and a callback number first, in case we get cut off. Do you have an order number or a date?
CustomerI ordered about three weeks ago, I do not have the number.
ReceptionistNo problem, I am writing down what you have given me and passing it right away to the person who has the file in front of her. I will not commit to a date myself — she is the one who will confirm it.
The request reaches the right person with the name, the callback number, the order period and the exact question. The in-house system is not touched; the person who opens it answers with the real status, and the customer gets a call back instead of a wait.
If no connection is possible
That is an ordinary situation at the start, and it stops nothing. Native mode is complete: it is not a reduced version waiting for something better.
- The requests, the appointments and the messages live in your workspace, with their history and their register
- You see them in the app on your phone, and you answer from there
- An export lets you carry the data into your own software at your own pace
- The day your software is qualified, it is added on top without changing your setup or your habits
Questions about this connection
My tool is not on the list — can I still start?
Yes. Native mode is complete, not a reduced version waiting for something better: the request, the appointment, the reason for calling, the recording and the transcript live in your workspace, with nothing connected.
What does it take to have my software qualified?
A named product, its edition, and the person who holds the account: a general category cannot be qualified. Three answers are enough to know whether the rest is worth doing.
My software has a web portal — does that count?
No, a portal that opens in a browser is not an interface. A screen built for a human being is not a permission, and automating a portal is not the default behaviour.
What if my vendor says no?
That is a possible answer, and we say it rather than work around it: your vendor may be a competitor, a customer, or simply closed to outsiders. When no interface exists, an import you approve or a human step replaces the automation, and that remains a good outcome.
Do I have to program anything?
No: no key to create, no connector to program, no development written to order. When a published interface does exist, the clean road runs through an authorised client app, limited tokens and signed web callbacks.
Does buying an interface open access to everything?
No: the rights stay the ones your scope gives you. Blanket access to every object because an interface was purchased is not part of the deal.
Where to next
See the software already studied, how your own data feeds the receptionist, or your own workflows.
My software is not in the list