Artificial intelligence for IT operations, usually shortened to AIOps, promises fewer alerts, faster incident triage and systems that fix themselves. This article answers one question for a company of 10 to 250 people with one or two IT staff: which parts of that promise apply to you, and which belong to firms with a network operations centre? The short answer is that your bottleneck is rarely the alerts. It is the stream of internal requests that arrive by email, chat and corridor conversation, with no record and no priority.
What AIOps means at enterprise scale
At large organisations, AIOps sits on top of monitoring. Thousands of servers, applications and network devices produce events. Software groups related events into one incident, suppresses duplicates, guesses the probable cause and sometimes runs a fix. The value comes from volume: no human team can read a million log lines an hour.
A 60-person firm does not have that volume. You might run a cloud office suite, a handful of business applications, a phone system, laptops and a printer that hates everyone. Your monitoring, if you have any, produces a few alerts a week. Grouping those with machine learning saves almost nothing.
Where the hours actually go
Ask your IT lead to keep a tally for two weeks. In most firms of this size the pattern is the same. A small share of time goes on genuine incidents. A large share goes on requests: new starter set-up, password resets, access to a shared folder, a licence for a new hire, a broken headset, a question about how to share a calendar. Each request is small. The cost is the interruption and the chasing, because nobody wrote it down.
Suppose the IT manager logs every interruption for ten working days and counts 140 items. Nine are real incidents, such as a failed backup or an email outage. The other 131 are requests, and 52 of those arrive as a message in a chat channel or a word at the desk. If working out who asked for what, and whether it was done, costs 40 minutes a day, that is over three hours a week before any fixing starts.
That is the problem AI can help with at this size. Not detecting anomalies across a data centre, but turning an untidy stream of requests into a queue with a category, a priority and a summary.
What the levelpartner.ai platform can and cannot do here
Be clear about the boundary. The levelpartner.ai platform is not a monitoring tool. It does not watch your servers, read your logs or patch your laptops. If you need endpoint management or infrastructure monitoring, buy a tool built for it.
What the platform does well is intake, routing and record keeping. You can publish an internal request form, route each submission through a workflow, use AI to summarise and classify the request, and track it through a pipeline until it is closed. The same tools you would use for customer enquiries work for internal ones. For the broader pattern, see AI business process automation.
Before you start
- A list of your ten most common request types, taken from the tally above.
- A decision on who owns each type: the IT lead, an outside provider, or the office manager.
- A rough priority rule, for example anything that stops a person working is urgent.
- Staff added as contacts, so each request attaches to a named person and builds a history.
How to set up the request queue
The queue is a pipeline with one card per request. The form that feeds it and the workflow that classifies each submission sit around it, but the pipeline is where your IT lead works every day, so build it first.
- Select Opportunities in the left sidebar.
- Choose Pipelines from the top navigation.
- Click Create new pipeline.
- Enter a Pipeline Name, such as Internal requests.
- Click Save.
- Enter a Stage Name and click Add stage, repeating for each stage.
- Use the arrows to put new, in progress, waiting and closed in order.
With the queue in place, publish a short request form in Sites with fields for the request type, the person affected, the device and a description, then connect it to a workflow that creates a card in the first stage for each submission.
Pin the form link in your staff chat and on the intranet home page. Then make a rule: if it is not on the form, it is not in the queue. That rule matters more than any AI step.
Triage that a small team can trust
The AI work in that workflow is classification and summarisation. Both are tasks current language models do reliably on short text. A description such as "can't get into the finance folder since the restructure, need it for month end Friday" becomes a summary, a category of access request and an urgency of high because of the deadline.
What the AI should not do is close requests or change permissions. Keep it on the reading side. It drafts, sorts and summarises. A person acts. That split keeps a wrong classification cheap: the worst outcome is a request in the wrong column for an hour.
Imagine a 45-person estate agency receives 210 internal requests in a month through the form. Say the AI category matches the IT lead's own judgement on 190 of them. On the other 20, the lead would move the card to the right stage in a few seconds. Without the form, the same month would mean scrolling chat history to find what was asked.
Incidents: the part you keep simple
For real incidents, such as email down or the internet out at one office, you need speed and one clear message to staff, not machine learning. Build a short workflow that the IT lead triggers by hand: it sends one SMS and one email to all staff saying what is down, what to do meanwhile and when the next update is due. Draft those templates now, while nothing is broken.
AI can help afterwards. Paste the notes from the incident into an AI content prompt and ask for a plain-language summary: what happened, what was affected, what changed to stop it happening again. That summary goes to the owners and into the record. Writing incident reviews is the task most small IT teams skip, and it is the one AI makes cheapest.
What most articles on AIOps get wrong
Most writing on this topic assumes the hard part is detection. For a firm with one or two IT people, detection is easy: staff tell you, loudly, within minutes. The hard part is memory. Which laptop did the sales director have replaced last spring? Who has access to the client folder? Why did we change the backup schedule? Enterprise AIOps assumes a configuration database already exists. You probably do not have one.
That is why the intake desk comes first. Every request on the form builds a history against a named person. After six months you can ask useful questions: which request types repeat, which person needs the most help, which application causes the most tickets. That is the raw material any later automation needs. Buying an AIOps product before you have it is buying analytics for data you do not collect.
The trade-off
Running internal requests on a sales and marketing platform means you get a capable form, workflow and AI layer without another subscription. You give up the things a dedicated service desk tool offers: asset registers tied to tickets, service-level timers built for IT, a self-service portal with a knowledge base designed for staff, and integrations with device management. If your IT team grows past two or three people, or you take on compliance obligations that require formal change records, move to a proper service desk tool. Until then, a form, a pipeline and two AI steps cover most of the need.
The common mistake is automating the fix before standardising the request. A workflow that resets passwords automatically is tempting, but if half the requests still arrive by chat, the automation sits idle and the chasing continues. Get every request through one door first. Automate the fixes once you can see which ones repeat.
Weekly running time
Expect about 30 minutes a week once the desk is running. Review requests the AI miscategorised and adjust the category list or the prompt. Close stale cards. Once a month, look at the volume by category and pick one request type to remove at the source, for example by writing a short guide for staff. If you use AI for staff-facing answers, an internal chat agent built the same way as AI customer support can answer how-to questions from your own guides.
When to buy a dedicated tool instead
Buy a dedicated AIOps or monitoring product when at least one of these is true: you run your own servers or a hybrid network with real alert volume, you have more than three people in IT, you face audit requirements for change management, or downtime costs you enough per hour that minutes of detection matter. For everything else, the request desk is the higher return. If you are still deciding where AI fits across the business, how to use AI for business gives a wider map, and AI agents explains how conversational agents differ from the workflow steps used here.
Frequently asked questions
Can the platform monitor our servers or network?
No. It does not read logs, watch uptime or manage devices. Use a monitoring or device management tool for that, and use the platform for request intake, routing and staff communication.
Is it safe to put internal requests through an AI step?
Keep sensitive details out of the free-text field, such as passwords or personal data about colleagues. Add a line to the form telling staff not to include them. The AI step only summarises and classifies, and a person makes every change.
How long does the request desk take to build?
A form, a pipeline and a workflow with two AI steps is usually a day of set-up, plus a week of tuning categories. The harder work is getting staff to use the form instead of messaging the IT lead directly.
What should we automate after the desk is running?
Look at the most frequent request type after two months. If it is new starter set-up, build a checklist workflow triggered by HR. If it is how-to questions, write guides and let an internal chat agent answer them.