Maintenance and vendors
The maintenance request follows its vendor, its status and its answer back to the tenant. That is what turns a voicemail into work done and proven.
Buildium
A tenant call becomes a request written into Zenvox, attached to the right unit, the right owner and the right spending limit. Buildium keeps its accounting.
7 days, 20 answered calls, no card
Where your tenant call lands
The request is written into Zenvox: address, unit, occupant, nature of the problem and urgency under your rules, with the mandate and spending limit that apply. Buildium keeps the truth of buildings, residents and per-owner accounting. Cancelling a maintenance request stays with you: it is not written from Zenvox.
On access, the research is precise: reading building, resident and accounting data is confirmed at documentation level, on an eligible subscription — so your edition decides before any install. Maintenance writes are unverified endpoint by endpoint. The key is generated from your account, per company; until it is in place, the receptionist works in native mode.
Buildium holds buildings, units, residents and per-owner accounting; a tenant calling about a water leak does not announce their unit number, and a request with no unit is a request that waits.
Read, create, update, cancel
The status below comes from vendor documentation re-read at checking time, and from the absence of an authenticated trial from Zenvox.
| Action | Status | What that means |
|---|---|---|
| Read | To qualify | Access to building, unit, resident and accounting data is documented and rests on a key you generate. The exact header and schema contract has to be inspected before any read is announced as settled. |
| Create | To qualify | Creating a maintenance request with its attachment is described but unverified endpoint by endpoint. Until it is, the request is created inside Zenvox, complete, and your team carries it over. |
| Update | To qualify | Changing a request status or assigning a vendor touches the spending ceiling in the mandate. Permissions, repeated sends and owner separation get tested first: two owners can use the same vendor under different ceilings. |
| Cancel | Zenvox native mode | Closing a request commits the reconciliation between work done, invoice and owner report. Platform events are unverified; closing therefore stays a decision of your team, recorded inside Zenvox. |
What is included, what needs an add-on
Answering, attaching a call to an address and a unit, sorting an emergency from an ordinary request under your rules and passing everything on belong to your real estate base. Vendor coordination and mandate tracking with its ceilings are named add-ons.
The authorisation, and what holds the truth
In third-party management, technical authorisation and spending authorisation are two separate subjects, and both get settled before go-live.
- The key is generated from your account, per company, and Zenvox asks for no password
- Owner separation is verified before install: a badly scoped key mixes two portfolios
- The spending ceiling comes from the written mandate; beyond it, the owner is asked and the decision is recorded with its date
- Your platform stays the system of record for unit, resident and accounting
- An operation is confirmed to a tenant only after a validated write in the system of record
Ten at night, a tenant calls the management line. Nothing is written into the platform.
TenantHi, water is coming through my bathroom ceiling and it is getting worse.
ReceptionistLet me take your name, a callback number, the building address and your unit number. Is the water reaching any electrical fixture?
ReceptionistI am filing this as an emergency under the management rules and alerting the person on call. They will call you back; I cannot confirm a plumber arrival time myself.
The on-call line gets the alert with building, unit, tenant, nature of the damage and time of the call. The manager knows at once which mandate applies and what ceiling it carries. No vendor was committed on an owner behalf outside their written frame.
When the connection is not there
The platform keeps its truth, and the receptionist works in Zenvox native mode.
- The request is created inside Zenvox with building, unit, occupant and nature of the problem
- Emergency sorting follows your written rules and raises the on-call alert
- You find the call, its transcript and its reason in the app
- No capability in your base depends on third-party software
- The day a write becomes qualified, it is added without redoing your setup
Questions about this connection
Does Zenvox create the maintenance request in Buildium?
Not yet: creating one with its attachment is described but unverified endpoint by endpoint. Until it is, the request is created inside Zenvox, complete, and your team carries it over.
Does my edition allow the connection?
That is the question that decides before any install. Reading building, resident and accounting data is confirmed at documentation level, on an eligible subscription, and the key is generated from your account, per company.
Two owners, two ceilings — can they get mixed up?
Owner separation is verified before install, because a badly scoped key mixes two portfolios. Two owners can use the same vendor under different ceilings, and the ceiling comes from the written mandate.
What do we tell the tenant?
An operation is confirmed to a tenant only after a validated write in the system of record. Meanwhile the request is taken, attached to the building and the unit, sorted under your rules and passed to the on-call line.
Who closes the request?
Your team. Closing a request commits the reconciliation between work done, invoice and owner report, and platform events are unverified: closing stays a management decision, recorded inside Zenvox.
Where to next
See the practice concerned, or the full list of software studied.
Buildium