Connect your software, or use ours
Three modes exist, and each promises something different. One system stays master of your calendar, and Zenvox does not build a second one behind your back.
Do you have to change software?
No. If a tool already holds your customers, your work orders or your appointments, it stays master: Zenvox reads there and writes there, within limits qualified for that particular product.
Three modes exist, and they are named so you know which one applies. Native confirmed: an action happens inside Zenvox, which is its source. Connected confirmed: an action happens inside your software, with its confirmation. Request only: an action is not yet possible at that vendor, so a request is captured, documented and handed to your team.
One rule runs through all three: a single master per object. A calendar, a price catalogue, a file, an order, a payment, a customer-relationship state each have one system of record, and only one.
Where you probably are
Either you run a management tool and fear a second system will contradict it. Or you run nothing, working from a shared calendar and text messages, and fear having to buy full software before starting.
Both fears are sound, and both have an answer. In one case your software stays the reference. In another, a native tool is enough to begin: contacts, requests, tasks, availability and simple follow-up.
Three modes, and what each promises
Native confirmed: Zenvox holds an object. A native calendar handles resources, durations, buffers between visits, service zone and time zone, with a lock preventing two appointments from overlapping. Booked means an appointment truly exists.
Connected confirmed: your software holds an object, and Zenvox acts inside it. Booked then requires confirmation from your system rather than from ours. Google Calendar or a Microsoft calendar can hold that role for a simple flow; a practice system holds it whenever it owns appointments.
Request only: writing is unavailable at that vendor. A request is captured in full, attached to a correct file, and handed to your team along with whatever is missing to finish it. Less convenient, and honest.
One master, even when things break
An outage in your software creates no second calendar and no parallel order behind your back. Zenvox keeps a request and displays a state actually known, including pending reconciliation whenever a write was lost on its way.
After an interrupted write, a system looks for a receipt at your vendor before retrying, so one appointment is not created twice. Where an answer stays undecidable, it is shown as such rather than guessed.
A read-only calendar is documentary availability, not permission to write. Permission to read does not become permission to book, to charge or to cancel.
Why some actions stay a request
Every product is qualified by vendor, edition, region, account and operation, action by action: read, create, change, cancel. An authorised connection qualifies no set of writes on its own, and only an operation actually tested gets promised.
A trades example: Jobber publicly documents its interface and its authorisation mechanism, yet no Zenvox grant, schema contract test or app review is established to date. A page for that product says so action by action rather than showing a logo.
A health example: an official Jane article on its partner programme currently excludes AI scheduling tools and direct calendar posting. In a clinic running Jane, a receptionist therefore qualifies a request and hands it to staff, instead of writing into a schedule.
If you run no software
A native tool covers essentials: contacts, incoming requests, tasks, availability and simple follow-up. Many businesses stay there for months, and that is a reasonable decision.
Moving to a richer tool should answer an identified need rather than an anxiety. Replacing full accounting, a practice record, an advanced dispatch system or an enterprise CRM is a separate programme, and integration is not a word that covers it.
Either way, one criterion holds: you must be able to configure, test, use, change, stop and export your data without anybody building your flow by hand.
Related pages
Pages detailing where each product stands.
Frequently asked questions
Do we have to change software to get started?
No. Native mode exists exactly for that: the receptionist keeps requests, customers and appointments in your workspace, with nothing plugged in. You connect later, if and when a connection genuinely adds something. Nobody has to migrate a history in order to receive a call.
Why do some actions stay a plain request?
Because a read permission does not become a booking permission. Every qualified software has its own page, and that page states action by action what is possible: read a record, create a request, move an appointment, cancel one. Where an action is not qualified, the receptionist notes the request and your team carries it out — rather than pretending.
What is the master system, and why choose one?
It is the software that wins when two systems disagree. Without that rule, a cancellation made on one side comes back to life on the other, and nobody knows which version is right. You choose it when connecting, and the rule holds even when the connection drops.
What if our software is not on your list?
Tell us. A connection is qualified action by action, with real trials, and that work takes time: we prefer a short true list to a long vague one. Meanwhile native mode does the job, and your data exports so it can be picked up elsewhere.
Does a connection give access to all of our software?
No. Each authorisation is bounded and you grant it yourself from your account. The receptionist reads what serves the conversation and writes what you authorised. Anything outside that perimeter stays out of reach, and the authorisation is removed in the same place it was granted.
What happens when the connection drops?
Reception carries on. The call is answered, the request is written, and the action that depended on the software is held rather than lost. When the connection returns, the action resumes where it stopped, and an action already performed is not replayed twice.
What if we have no software at all today?
That is a common case and the product is built for it. Requests, customers and appointments live in your workspace, readable by your team. You do not buy a management system in order to answer the phone, and you stay free to take one later.
Can we use both, software and native mode?
Yes, and it is often the right intermediate step: the receptionist reads your software to recognise a customer, and writes into your workspace what the connection cannot write yet. The master-system rule then stops the two from contradicting each other.
Do we have to import our customer history?
No, and nothing requires it to get started. The receptionist recognises a customer by their number and by what they say; a record is created at the first conversation. If you later connect software holding the history, reading that software enriches what the receptionist knows — without you having had to move anything.
Who decides what a connection is allowed to write?
You do, action by action, when you authorise it. Each qualified software page states the real status of all four actions — read, create, modify, cancel — and that status comes from trials run on the software, not from a commercial wish. An action that is not qualified is not offered in your settings.