Your phone system is the single richest source of "what's actually happening with this client" that you have — and on most days nobody on the team looks at it.
Think about the trail a call leaves. Who called, from which extension or DID, how long they waited in queue, who picked up, how long the call ran, whether it was recorded, and — if your phone system is doing its job — a transcript and a summary of what was said. That's a full account of a support interaction, generated automatically, sitting in a system that almost nobody opens unless a customer complains about hold times. We built the VoIP layer of Morton Command Center specifically to drag that data out of the phone admin console and put it next to the tickets and clients it actually belongs to.
A note up front so we set expectations right: every telephony integration is custom-built for your stack as part of your engagement — that's the headline advantage over rigid all-in-one suites that force you onto their pre-wired connectors. This post walks through 3CX in detail because it's a concrete, end-to-end example — but it isn't a requirement. Because the platform is API-driven, any phone system with an API — RingCentral, a hosted PBX, whatever you run — gets the same treatment, built to fit your exact setup. If your tool has an API, we build the integration for it. We'll come back to off-3CX shops at the end; everything in between describes the kind of phone integration we build, using 3CX as the working example.
What the 3CX layer actually surfaces
When we connect 3CX, you get a VoIP section in the dashboard with a handful of views, each reading live from the 3CX Call Control API:
- Call log and history — inbound and outbound calls with caller, extension, direction, duration, and timestamp. This is the searchable record of every call, not a once-a-month export.
- Active calls and agent presence — who's on the phone right now, who's available. Useful when you're deciding whether to escalate a P1 or just walk over.
- Call queues — your hunt groups, with the agent roster in priority order. You can reorder agents in a queue directly from MortonCC — handy for weekly on-call rotations where position 1 shifts every Monday.
- Extensions and phonebook — the directory, so a number on a call log isn't just digits.
- Recordings — the call recordings 3CX already captures, with playback.
- Routing — visibility into how calls flow.
None of this is a copy of your phone data living in some other database. The adapter talks to 3CX and reflects what's there. We're not a phone system and we're not trying to be one — we're the pane of glass that puts 3CX's data where your techs already spend their day.
Click-to-call, so the phone follows the ticket
The smallest feature here is the one people end up using the most. When a contact's number shows up in MortonCC — on a ticket, on a company page, in the call log — it's clickable. Click it and 3CX rings the call out through your registered device. No copying the number into a softphone, no fat-fingering a digit, no tabbing between four windows to return a missed call.
It sounds trivial until you count how many times a day a tech places a call. Each one was a context switch out of the ticket and into the phone app. Click-to-call keeps the workflow in one place: read the ticket, click the contact, talk, log your time, close the ticket. One requirement worth flagging — the calling extension needs a registered device for 3CX to place the call. That's a 3CX setup detail, not a MortonCC one, but it's the usual "why won't it dial" gotcha.
AI transcription and summaries, surfaced — not invented
This is the part that genuinely changes how a support team works, and it's also the part where I want to be careful about who deserves credit. 3CX has a native AI transcription feature. When it's enabled, recordings come back with a transcript, a summary, and a sentiment read on the call. Morton Command Center surfaces that — we pull the transcription, summary, and sentiment from 3CX and show them next to the recording. We didn't build a speech-to-text engine; we built the plumbing that makes 3CX's output visible in the same place as the rest of the client's story.
Why that matters in practice: a tech who picks up a ticket can skim the summary of the related call instead of listening to nine minutes of audio. A manager auditing a rough month can scan sentiment across a client's calls without playing a single recording. And the transcript is searchable text, so "what did we promise them on the phone in March" stops being an archaeology project.
The honest caveat: transcription and sentiment are only there if you've turned them on in 3CX, and recordings access depends on the 3CX client holding the System Owner role. If those aren't configured, the views still work — you just won't see transcripts until 3CX is producing them.
Why "next to the ticket" is the whole point
Most MSPs already have all of this. The call log is in the 3CX admin console. The tickets are in Freshdesk or NinjaOne. The billable time is in eBillity or in native timecards. The client record is somewhere else again. Each tool is fine in isolation. The cost is the swivel-chair tax — the tech who opens three browser tabs and a phone app to handle one customer call, and the manager who can't answer "how much phone support did this client get this month" without exporting from two systems and reconciling them in a spreadsheet.
When call data lives next to the ticket and the company record, a few things get easier on their own:
- Returning a call is a click from the ticket instead of a copy-paste into a softphone.
- Logging the work happens in the same app, so the call and the time entry and the ticket update don't drift apart.
- Reviewing a client relationship means opening one company page that already carries their tickets, their devices, their backups, and now their call history — instead of stitching it together from memory.
- Spotting a queue problem — long waits, calls dying in a hunt group — happens where you're already working, not in a phone report you open quarterly.
That consolidation is the same idea behind the rest of Morton Command Center: we don't replace your tools, we unify them through adapters so they read as one system. The phone is just one more source feeding that single pane. If you want the dedicated breakdown of the reporting side, we put it on the 3CX call reporting dashboard page, and the broader argument for collapsing your tooling into one view lives on consolidate your MSP stack.
How it connects (and what stays in 3CX)
The integration is read-and-act, not rip-and-replace. We read your call log, presence, recordings, and queues; we act by placing click-to-call dials and reordering queue agents. Everything else — your call flows, your IVR, your recording policy, your transcription settings — stays in 3CX, owned and configured there. Cancel MortonCC tomorrow and your phone system is untouched, because we never held the data hostage in the first place.
This pairs naturally with the ticketing side. The same way we build your phone integration, we build the integration to your PSA or RMM as your ticket source — custom to your stack. Because the platform is API-driven, any PSA or RMM with an API (Freshdesk, NinjaOne, ConnectWise, HaloPSA, Datto, or whatever you run) gets the same custom build. Once both are in one place, the call and the ticket finally talk to each other. We wrote that workflow up separately in Freshdesk + NinjaOne: a real-world MSP workflow, and the phone layer slots right on top of it.
If you're not on 3CX
I'll be straight, because it's the most common question. If your shop runs a different phone system, you're not on a worse path: as long as that system has an API, we build the integration custom for it as part of your engagement. That's the point of the architecture — every integration is built to fit your exact stack and workflows, instead of bending you onto a one-size-fits-all connector. The rule is simple: if your tool has an API, we build the integration for it. And what you never have to do is move off your phone system to use Morton Command Center — the whole design is about meeting your stack where it is.
If you're already on 3CX, though, this is close to free value sitting on infrastructure you've already paid for. The call data exists, the transcripts exist, the recordings exist. We just put them where you can finally use them.