Koltra for managed IT services · Exploratory service context
Koltra is exploring what an answering layer for MSP service work would need: customer context, structured intake, permitted ticket actions and clear human responsibility. This page examines that service context; it is not an announced next product or an available Koltra service.
MSP is an exploratory service context, not a committed next product or available off-the-shelf Koltra service. The examples describe intended operating possibilities.
A message-taking service converts calls into callbacks. An answering layer built for MSPs should convert calls into work the desk can act on: identified, contextualized, and routed under the rules the MSP declared.
After-hours, overflow, and peak volume should stop rolling to voicemail; concurrent calls should enter the same declared intake instead of waiting for another person to answer.
The conversation should start from the customer, site, contracted services, and open tickets, rather than from a caller spelling their company name.
Symptoms, urgency, affected users, and business impact should arrive captured, so nobody reconstructs them by interrogation an hour later.
The ticket should already exist in the system of record, deduplicated against open work, with the conversation and its provenance attached.
The request should reach the queue, technician, or on-call route you declared, carrying everything collected with it.
The answering layer identifies, captures, creates, and routes. It does not decide what is wrong, change a customer environment, accept risk, or command a major incident. Those stop the workflow and reach a named person with the full context attached, so a technician's first touch is diagnosis, not interrogation.
Both models answer the call. They differ in what reaches the queue afterwards, which is what decides whether the technician's first touch is diagnosis or interrogation.
| The call | A message-taking service leaves | An operating layer should leave |
|---|---|---|
| Site cannot reach a shared drive | A message naming the caller and the symptom. | A ticket in the PSA with customer, site, affected users, business impact, and the conversation attached. |
| Repeat of an open issue | A second message, unlinked to the first. | The existing ticket updated rather than duplicated, with provenance preserved. |
| Possible security signal | A message routed like any other. | A stop before routine routing, marked as risk, on the declared escalation path to a named person. |
| Call at 3 a.m. | A queue of callbacks waiting for morning. | The same declared intake, so the morning queue starts with complete, routed tickets. |
What a well-answered service call should look like behind the conversation: six declared stages, none improvised at the time.
An answering service you cannot inspect is a message pile with a friendlier voice. Each call should end with a written outcome: what was asked, what was created or updated in the PSA, who owns the next step, and how long it took. That per-call record is the standard Koltra designs against.
The numbers worth managing are the ones answering-layer automation actually moves: re-intake rate, routing accuracy without a bounce, time to a technician's first meaningful touch, and failure visibility for every call that stopped short.
If you are still deciding what belongs in software and what belongs with technicians, start with the plain-language guides. They map the boundary without the pitch.
The category defined against auto attendants, IVRs, and human answering services.
Read the guide →The automation map: what to automate, what stays human, and how to sequence it.
Read the guide →Classification, prioritization, enrichment, and routing under declared rules.
Read the guide →The exploration goes beyond message-taking: a useful design could connect caller context, structured intake, permitted ticket actions and routing. Those possibilities are not claims of current Koltra functionality.
No specific PSA integration is promised here. An implementation would need to establish supported APIs, scoped permissions and the actions permitted by the MSP before changing a system of record.
A proposed design would need explicit escalation rules for major incidents and security-sensitive requests, with appropriate human responsibility and the relevant context preserved. This page does not demonstrate a live incident-handling system.
Reducing repetitive intake may free people for diagnosis, exceptions and customer relationships. Whether it does so, and how staffing changes, depends on the workflow and measured results; no staffing outcome is claimed here.
After-hours intake is one possibility to evaluate, subject to capacity, integrations and support arrangements. Emergency and incident handling would need a defined, tested path to the responsible people.
A concrete service-desk example can help evaluate the opportunity: what should be answered, which context matters, what may change in the PSA, and when a person must take over.
MSP is an exploratory service context, not a committed next product or available off-the-shelf Koltra service. The examples describe intended operating possibilities.