IT services
A helpdesk first line that actually opens the ticket.
In an IT services firm the most expensive minute is the one where an engineer answers the phone to find out who is calling and from which client. The ticket gets opened anyway, the details get asked for anyway, and that order can be reversed: details first, engineer second.
The assistant takes the support call, identifies the company and the person, establishes what is broken and since when, opens the ticket in Zendesk, Freshdesk, Jira or Linear with the literal description, and escalates to the on-call engineer any incident matching your rules.
What the first line takes
The useful distinction is not between simple and complicated problems, but between calls that need an engineer now and calls that need a well-written ticket.
A new report
The company, the person, what is broken, since when, how many people are affected.
A major incident
When the criteria you write are met, the call goes straight to the on-call engineer.
The status of a ticket
Searched by number or by company, with the status read from your ticketing system.
A change request
A new user, an access grant, an install. Opened as a ticket in the right queue.
An out-of-hours call
Taken, written as a ticket and pushed to Slack, escalating only what the contract covers.
From the call to a ticket with everything in it
The purpose of the flow is that the engineer picking the ticket up does not have to make a second call to find out what broke.
- 01 Identify the company By phone number, searching your ticketing system or the CRM. When it finds nothing, it asks for the company name directly.
- 02 Check the escalation threshold How many people are affected, whether a service is completely down, whether it is out of hours. The criteria are yours, written in the prompt.
- 03 Gather the literal description What is broken, since when, what changed beforehand. The text stays the user, without technical interpretation.
- 04 Open the ticket In Zendesk or Freshdesk for support, in Jira or Linear for what goes to development, with the description and transcript attached.
- 05 Escalate or confirm Transfer to on-call for major incidents, otherwise a Slack message and an SMS to the caller with the ticket number.
What the engineer finds
A ticket opened by an assistant has to look like one opened by an attentive colleague, not like a raw transcript.
| The ticket | In Zendesk, Freshdesk, Jira or Linear, with the company, the person, the description and the time. |
|---|---|
| The attached transcript | As text on the ticket, because sometimes a word said in passing is the key. |
| The notification | A Slack message in the right channel, immediately, with the link to the ticket. |
| The confirmation to the client | An SMS with the ticket number, which stops the second chasing call. |
What it does not do for an IT services firm
The temptation here is to believe the assistant can resolve level one. It cannot, and it does not try.
- It does not troubleshoot It does not walk somebody through fixes, does not ask them to restart anything and does not diagnose. It gathers and opens.
- It executes nothing in your systems It resets no passwords, unlocks no accounts and restarts no services. The shell and computer tools in the product refuse to run: the sandbox they are meant to execute inside does not exist yet.
- It does not decide severity It applies the thresholds you write. It does not assess the impact of an incident on its own.
- It monitors nothing It does not see your alerts and does not know a server is down unless a caller tells it.
- Connectors do not cover everything Zendesk, Freshdesk, Jira and Linear are implemented. For any other ticketing system, an HTTP tool has to be written.
What IT services firms ask us
Can it resolve simple tickets on its own?
No, and that is a deliberate choice. The tools that could execute something on a machine refuse to run in this build, because the sandbox they should execute inside does not exist. Refusing is better than running them on our machine, and the tools guide says so explicitly.
How does it know who is calling?
It looks the phone number up in your ticketing system or CRM. That is enough for routing and for filling in the ticket, but it is not authentication. For any request that changes an access grant, escalation to a person is compulsory.
Does it work with our service level agreements?
It can write what it learned onto the ticket and escalate by threshold, but it does not calculate response times and does not track a contract. Those stay in your ticketing system, which already does them.
Can it cover the night rota?
Taking the call, yes. Escalating, yes, to the number you configure. What it cannot do is chase somebody who does not answer or move to a second on-call tier by itself, because that would be a decision about severity.
Where to go next
Integrations
25 business connectors, 18 selectable providers, eight storage destinations.
Tools and MCP
Discovery, per-tool permissions, per-server namespacing, and a tool of your own.
Developers
A REST surface with OpenAPI, webhooks, MCP, and a tenant boundary enforced in several places.
Pricing
Components at their published price, the platform on top, and what we cannot price yet.
Notes
-
1
The tools named on this page are the ones in
App\Services\Integrations\ConnectorRegistrycarryingimplemented. Anything that is only in the catalogue, without that flag, is not named here as though it worked. -
2
Tickets use
create_ticketandsearch_ticketson Zendesk and Freshdesk, orcreate_issueon Jira and Linear. The shell, computer and text-editor tool types refuse to run in this build.