Lead capture and sales follow-up
Assigns an owner, follows up by stage, keeps the reason for a loss and measures performance by source. This is the add-on that needs a pipeline, and that knows what to do with one.
HubSpot
The request is written into Zenvox, then filed into HubSpot as a contact or a deal under your rules. The authorisation sits on your account, and it can be revoked cleanly.
7 days, 20 answered calls, no card
Where your request lands when a CRM already exists
The request is written into Zenvox: who is calling, what they want, the qualification done on the phone. HubSpot keeps the truth of your commercial activity, and the connection files a contact or a deal there under your rules. All four actions can be addressed in the vendor’s current interface; no app has been authorised on a real account yet, and this page does not announce them as settled.
Access goes through an authorisation you install on your own account, with read and write rights that are scoped: no key to create, no connector to program. A private app stays possible where it is authorised and appropriate, but it is not the default road: a per-account authorisation can be revoked cleanly, and that is what counts when you are handing over your client book.
HubSpot is a CRM: contacts, companies, deals filed into pipelines. When one is already in place, the question is not whether to replace it, but who writes what — a seller wanting a valuation and a buyer wanting a viewing enter a pipeline differently.
Read, create, update, cancel
This is the best documented of the seven files: the routes exist, they are described in the vendor's current interface, and all four actions can be addressed. What is missing is of a different nature — no app has been authorised on a real account, and the exact scopes and a customer's configuration have not been put to the test.
| Action | Status | What that means |
|---|---|---|
| Read | To qualify | Reading and searching a deal, together with the pipeline and stage identifiers, are documented in the current interface. Reading a contact or a deal on the owner's behalf does not depend on an acquisition add-on; its first job is simply to recognise who is calling. |
| Create | To qualify | Creating a deal and associating it with a contact and a company are documented. A Zenvox identifier is kept on the deal, so that a callback from the same customer does not produce a second record of the same file. |
| Update | To qualify | Updating a deal and its associations is documented. One rule is settled in advance: a custom stage is addressed by its internal identifier and not by its label, otherwise a stage renamed in your portal breaks the flow silently. That behaviour has to be tested against your own configuration. |
| Cancel | To qualify | Archiving or deleting a deal is not the same as marking it lost, and neither of them is a withdrawal of consent: three different things, modelled separately. Until that distinction has been proven on a real account, the receptionist archives nothing and simply records a reason. |
What is included, what needs an add-on
Answering, qualifying, taking the appointment and passing the request along belongs to your base, CRM or no CRM. Reading a record to recognise a customer who is calling back is part of that too. The pipeline, assigning an owner, following up by stage and sending the outcome back are the work of the acquisition add-on. The CRM's own paid automations are not presumed: they depend on the plan you hold with them.
The authorisation, and what holds the truth
Handing over your client book deserves rules that are written down. Here are the ones that are set before the first installation.
- The authorisation is installed on your own account with scoped read and write rights, and your password does not go through Zenvox
- A private app stays possible where it is authorised and appropriate, but the per-account authorisation is the normal road, because it can be revoked cleanly
- A deal created from a call keeps a Zenvox identifier and its source, so that two tools do not produce two files for the same customer
- Custom stages are addressed by their internal identifier, not by their label
- The CRM holds the truth for the commercial state: it is what decides whether a deal is won, lost or still open
- The reason for a loss is written down, because a pipeline with no reasons in it helps nobody understand a bad quarter
A real estate brokerage team. The CRM holds the seller and buyer pipelines. The authorisation is not installed yet, so the request is prepared in the workspace with everything the deal will need.
CallerHi, I would like to know roughly what my house might be worth.
ReceptionistLet me take your name and a number to reach you on first. What is the address of the property?
CallerIt is a semi-detached, and we are thinking of selling in the spring.
ReceptionistGood. Is it already listed with another broker? I do not give an opinion on value over the phone — the broker establishes that on site — but I can book you a seller meeting.
The request goes to the seller queue with the address, the type of property, the timeline and where the call came from. That is exactly what is needed to open a deal in the right pipeline, at the right stage, the day the authorisation is installed.
If the connection is not there
A team that would rather not open its CRM — or that does not have one — keeps the same reception and the same follow-up. The workspace carries its own intake and its own pipeline.
- The request is created in your workspace with the same fields and the same qualification as on the phone
- An owner is assigned, the follow-ups run by stage, and the reason for a loss is kept
- You copy the record into your CRM if you want to, with its origin intact
- The day the authorisation is installed, the source of every deal is preserved and there is nothing to redo
Questions about this connection
Can the authorisation be revoked cleanly?
Yes, and that is why the per-account authorisation is the normal road: it is installed on your own account, with scoped read and write rights, and your password does not go through Zenvox. A private app stays possible where it is authorised and appropriate.
Will I end up with two records for the same customer?
A deal created from a call keeps a Zenvox identifier and its source, so two tools do not produce two files for the same customer. A callback from that customer therefore produces no second record of the same file.
Our pipeline stages are custom — is that a problem?
They are addressed by their internal identifier and not by their label, otherwise a stage renamed in your portal breaks the flow silently. That behaviour has to be tested against your own configuration.
Does she archive a lost deal?
No. Archiving or deleting a deal is not the same as marking it lost, and neither of them is a withdrawal of consent: three different things. Until that distinction has been proven on a real account, the receptionist archives nothing and simply records a reason.
Do I need the acquisition add-on to recognise a customer calling back?
No: reading a contact or a deal on the owner behalf does not depend on it. The pipeline, assigning an owner, following up by stage and sending the outcome back are the work of the add-on.
Where to next
See sales follow-up, the trade concerned, or open the full software list.
HubSpot