The call is part of the client history, so it should be on the client record.
CubeMSP and Wildix
Call activity against the client record, and a click-to-dial that starts from the contact rather than from a handset.
- Telephony
- No per-connector licence
- 01234 672 617
A great deal of what a managed service provider does happens on the telephone, and almost none of it ends up on the record. Wildix exposes a well-documented API and Crushed Ice has been building against it for years, so bringing call activity onto the client and incident record is familiar ground rather than speculative. Inbound calls identify the client from the number, calls can be logged against an incident, and click-to-dial starts from the contact you are already looking at.
What moves
Exactly what is synced, and which way
Being specific about this up front avoids the single most common integration disappointment - discovering after go-live that one field never travelled.
- Into CubeMSP
Call activity
Inbound and outbound calls logged against the client and contact identified from the number, with duration and outcome.
- Into CubeMSP
Caller identification
The client, site and open incidents for an inbound number surfaced as the call arrives, so the person answering already has the context.
- Out of CubeMSP
Click to dial
Dial from the contact record on screen rather than typing a number into a handset, with the call logged automatically.
How it behaves
The detail that decides whether it is actually useful
Context before you answer
Who is calling, which client, which site and what is currently open for them - on screen as the phone rings rather than after asking.
Calls attached to incidents
A call about an open incident logged against it, so the record of what was discussed is where the work is rather than in somebody’s memory.
History that includes the phone
The client record shows calls alongside incidents, notes and projects. For accounts where most contact is by telephone, this is the difference between a record and a fiction.
Call volume per client
How much telephone support an account actually consumes, which is frequently the missing figure when a fixed fee looks unprofitable and nobody can say why.
Setting it up
Three steps, done during implementation
Provide API credentials for your Wildix PBX.
Map extensions to CubeMSP users so calls attribute to the right person.
Enable caller identification and click-to-dial per user rather than for everyone at once.
Questions
What people ask about this one
No - it is planned. We are being specific about it because the group has built Wildix integrations before and the API is well understood, but it is not shipped and we will not imply that it is.
No. Call recording is a PBX function with its own legal and retention considerations, and it should stay there. CubeMSP records that a call happened, with whom, and about what.
The same pattern applies to any PBX with a usable API. Wildix is named because it is the one the group knows best, not because it is the only one possible.
It can. Logged call duration can be turned into a time entry against an incident, which is how most telephone support ends up billed correctly rather than not at all.
Related
Usually set up at the same time
- Microsoft 365Single sign-on through Entra ID, licence counts reconciled per client, and incidents raised from mail without leaving the tenant you already manage.
- REST API & WebhooksA documented REST API and webhooks on every meaningful event - included in the platform, not licensed per connection.
- Microsoft TeamsAssignment, escalation and breach notifications in the channel your engineers already have open, without another application to watch.
Wildix
Check the Wildix detail before you commit
Send us the specifics - your chart of accounts, your tax treatment, your product structure - and we will tell you exactly how it maps rather than promising it will be fine.