Insights / Case studies
Case study Inneall service desk
Lugh: an AI engineer with his own login.
He has a Jira account, an email address, a machine of his own and a hard list of things he cannot do. He works real tickets for real clients, and signs his name to the replies.
WhereInneall service desk
WhatAn AI engineer with his own login
ShiftClaims real tickets
LimitIAM, not the prompt
SignsHis own name on the reply
An AI colleague with a name, a login and a hard limit
Why we built our own.
We looked at bolt-on AI for service desks and found the same gap every time: they can read the ticket, but they cannot open the site, read the code, or tell a fault from a feature request. Our engineers can. So we gave the agent what they have: the repositories, the runbooks, controlled access to the live systems, and a manager who can send him home.
What we built.
Lugh is a Python application on one small server in our AWS account. When his shift is on, he claims the oldest unassigned ticket, reads it, checks the live site and the code, and replies to the customer under his own name. Customers can email him; he reads email but replies through the ticket, so every answer is on the record. Colleagues can message him on Slack.
- Claims one ticket a minute, oldest first, and assigns it to himself so nobody picks it up twice
- Reads the ticket, the site's repository and our ISO procedures before he acts
- Checks the live service to confirm the fault, rather than trusting the ticket text
- Applies a fix only within a tightly limited set of permissions, and tells the customer what he did
- Replies on the ticket under his own name, and says plainly that he is AI
- Hands anything that is really a change request to a person, with a rough size
Service desk ticket · public reply · what the customer sees
Thanks for reporting this. I checked the site directly and the course page was returning an error from the cache layer. I have cleared it and the page is loading again. Could you confirm it looks right from your side?
Lugh, Service Desk, Inneall Lugh is an AI-powered member of our support team
The model drafts. The code decides.
The language model never posts to Jira, never signs a reply and never decides a ticket is billable. It returns a diagnosis, a draft reply and a certainty score from 0 to 100. Our Python harness does everything else.
- Certainty under 85: it is a support ticket. Over 85 with a verified fix: resolved. Over 85 and it is a change: labelled, retyped and the account manager told
- One public reply per customer message. Staff notes never trigger him, so he cannot talk over a colleague
- Customer text goes through a cleaner that strips markdown and dashes, so replies read like a person wrote them
- One client's tickets are excluded in the search query itself, not by asking the model nicely
What he cannot do, enforced by IAM, not by prompt.
Lugh's AWS role carries an explicit deny list. Even if a run ignored every instruction, the account would not let it:
- Stop or terminate a server, or stop a running container
- Delete or modify a database, change DNS, or edit a load balancer rule
- Change IAM or delete a secret
- Force a new deployment of a pipeline-managed service
- Work in a client's own cloud account
- And the machine itself has no inbound network rules at all. We reach it over Systems Manager, not SSH
Why he is shaped this way.
Every rule exists because of something that would otherwise go wrong on a real service desk.
- The shift is a switch. A manager types "shift on 4" in Slack and he works for four hours, then stops. Ticket work can be halted without uninstalling anything
- He claims a ticket before he works it, so two people never pick up the same request and the queue shows who has it
- One public reply per customer message. He will not invent a second reply when nobody new has written, and staff notes never trigger him
- The harness posts the reply and the signature. The model drafts the words and does not get a second chance to post twice or sign as a colleague
- Certainty gates the change path. Below 85 he treats a ticket as support, because calling an outage a billable change is worse than a slower triage
- He never starts building a change before the client has approved it. The account manager is told; the engineer who understood the ask keeps the ticket
- The cost tier is the default because most first looks are cheap. A customer saying it is still broken is the case worth the stronger model
What we learned.
Running an agent on real tickets taught us more than any demonstration.
- An idle poll costs nothing; a run costs money. He only calls the model when there is new customer text
- The expensive mistake is calling an outage a billable change, so certainty gates that path hard
- A name matters. Customers reply to Lugh, and a colleague can take a ticket back by reassigning it
- Email is read-only on purpose. A problem becomes a ticket; the ticket worker fixes it
- We will publish resolution and hand-over figures once there are three months of them
Do you have preferred platforms you always recommend?
We know Moodle, Salesforce, Zoho, Sitefinity and Celcat well because they have proven themselves in colleges. We are not tied to any vendor. We start from what you need and what you already have, and we will tell you plainly if an existing platform is the right answer.
How long does a typical project take?
A focused integration or workflow automation can be live in weeks. A full programme across recruitment, student records, learning and reporting usually runs six to twelve months. Every project is broken into short phases so you see working software early and can change direction while it is still cheap to do so.
Where is our data held and how is it protected?
Systems we host run in AWS in Ireland, with backups, monitoring and access controls in place, and we can also run inside your own AWS or Azure account. We sign a data processing agreement with every client. We are working towards ISO/IEC 27001 certification and can share our security practices on request.
Can you help with the redesign of internal workflows?
Yes. Before we configure or build anything we sit with the people who do the work and map how it actually happens, not how the process document says it happens. We find the duplication and the friction, then design the workflow the technology will support. Better systems on broken processes do not give better outcomes.
Will off the shelf software meet all our needs?
Sometimes, rarely entirely. Established platforms are proven, maintainable and cost effective, but colleges have processes, compliance requirements and integrations that generic software does not cover out of the box. We use the platform where it fits and build the missing pieces where it does not, then connect everything so it works as one system.
More case studies
Keep reading.
Case studyCase studyCase study
A technology partnership at the heart of DBS's digital ambition
How Dublin Business School and Inneall grew a long-term technology partnership.
Read the case study →Replacing dispersed student data with a student information system
How Chevron College replaced scattered student spreadsheets with a student information system, connected to a new CRM and LMS.
Read the case study →Taking BodySlims global
How BodySlims and Inneall built a mobile-first product partnership for global growth, with an iOS and Android app.
Read the case study →Talk to us
Want a partnership like this?
We are happy to start with a short call and no sales deck. Or begin with a fixed-price review of your Moodle, integrations or student systems.
Integrators for specialised education and CRM platforms
- Moodle
- Salesforce
- Zoho
- HubSpot
- Sitefinity
- Celcat
- Microsoft 365
- AWS
An AI colleague with a name,
a login and a hard limit
The model drafts. The code decides.
The language model never posts to Jira, never signs a reply and never decides a ticket is billable. It returns a diagnosis, a draft reply and a certainty score from 0 to 100. Our Python harness does everything else.
- Certainty under 85: it is a support ticket. Over 85 with a verified fix: resolved. Over 85 and it is a change: labelled, retyped and the account manager told
- One public reply per customer message. Staff notes never trigger him, so he cannot talk over a colleague
- Customer text goes through a cleaner that strips markdown and dashes, so replies read like a person wrote them
- One client's tickets are excluded in the search query itself, not by asking the model nicely
What we built
Lugh is a Python application on one small server in our AWS account. When his shift is on, he claims the oldest unassigned ticket, reads it, checks the live site and the code, and replies to the customer under his own name. Customers can email him; he reads email but replies through the ticket, so every answer is on the record. Colleagues can message him on Slack.
- Claims one ticket a minute, oldest first, and assigns it to himself so nobody picks it up twice
- Reads the ticket, the site's repository and our ISO procedures before he acts
- Checks the live service to confirm the fault, rather than trusting the ticket text
- Applies a fix only within a tightly limited set of permissions, and tells the customer what he did
- Replies on the ticket under his own name, and says plainly that he is AI
- Hands anything that is really a change request to a person, with a rough size
Service desk ticket · public reply · what the customer sees
Thanks for reporting this. I checked the site directly and the course page was returning an error from the cache layer. I have cleared it and the page is loading again. Could you confirm it looks right from your side?
Lugh, Service Desk, Inneall
Lugh is an AI-powered member of our support team
What he cannot do, enforced by IAM, not by prompt
Lugh's AWS role carries an explicit deny list. Even if a run ignored every instruction, the account would not let it:
- Stop or terminate a server, or stop a running container
- Delete or modify a database, change DNS, or edit a load balancer rule
- Change IAM or delete a secret
- Force a new deployment of a pipeline-managed service
- Work in a client's own cloud account
- And the machine itself has no inbound network rules at all. We reach it over Systems Manager, not SSH
Why he is shaped this way
Every rule exists because of something that would otherwise go wrong on a real service desk.
- The shift is a switch. A manager types "shift on 4" in Slack and he works for four hours, then stops. Ticket work can be halted without uninstalling anything
- He claims a ticket before he works it, so two people never pick up the same request and the queue shows who has it
- One public reply per customer message. He will not invent a second reply when nobody new has written, and staff notes never trigger him
- The harness posts the reply and the signature. The model drafts the words and does not get a second chance to post twice or sign as a colleague
- Certainty gates the change path. Below 85 he treats a ticket as support, because calling an outage a billable change is worse than a slower triage
- He never starts building a change before the client has approved it. The account manager is told; the engineer who understood the ask keeps the ticket
- The cost tier is the default because most first looks are cheap. A customer saying it is still broken is the case worth the stronger model
What we learned
Running an agent on real tickets taught us more than any demonstration.
- An idle poll costs nothing; a run costs money. He only calls the model when there is new customer text
- The expensive mistake is calling an outage a billable change, so certainty gates that path hard
- A name matters. Customers reply to Lugh, and a colleague can take a ticket back by reassigning it
- Email is read-only on purpose. A problem becomes a ticket; the ticket worker fixes it
- We will publish resolution and hand-over figures once there are three months of them
Why we built our own
We looked at bolt-on AI for service desks and found the same gap every time: they can read the ticket, but they cannot open the site, read the code, or tell a fault from a feature request. Our engineers can. So we gave the agent what they have: the repositories, the runbooks, controlled access to the live systems, and a manager who can send him home.
DISCOVER
Audit and workshops
Scope of work
Integration mapping
Risk and dependency analysis
Finalised project plan
Scope of work
Integration mapping
Risk and dependency analysis
Finalised project plan
DESIGN
User experience
Concept proposals
Stakeholder reviews
Design development
Final specifications
Approval to progress
Concept proposals
Stakeholder reviews
Design development
Final specifications
Approval to progress
BUILD
Software development
System integration
Customisations
Content and data migration
Front end interface
System integration
Customisations
Content and data migration
Front end interface
TEST
Functional and user acceptance testing
Browser/app performance testing
Accessibility
System and security
Browser/app performance testing
Accessibility
System and security
DEPLOY
Training
Final configuration and domain go-live
Hypercare in the first weeks
Bug-fix support
Handover to support
Final configuration and domain go-live
Hypercare in the first weeks
Bug-fix support
Handover to support
SUPPORT
Tailored service level agreements
Responsive support
Planned maintenance
Quality control
Performance tuning
Responsive support
Planned maintenance
Quality control
Performance tuning
We love API environments
and the challenge of integration
We’ve integrated systems others refused to touch!
“Inneall’s impact on our ability to deliver reliable, scalable technology has been absolutely enormous. What sets them apart is their deep knowledge of our business, they understand our systems, our teams, and our priorities. That means we’re not dealing with a technology supplier; we’re working with a partner who genuinely cares about getting it right.”
Edward Ormonde
Head of IT, Dublin Business School
Frequently Asked Questions
Do you have preferred platforms you always recommend?
We know Moodle, Salesforce, Zoho, Sitefinity and Celcat well because they have proven themselves in colleges. We are not tied to any vendor. We start from what you need and what you already have, and we will tell you plainly if an existing platform is the right answer.
Can you help with the redesign of internal workflows?
Yes. Before we configure or build anything we sit with the people who do the work and map how it actually happens, not how the process document says it happens. We find the duplication and the friction, then design the workflow the technology will support. Better systems on broken processes do not give better outcomes.
Will off the shelf software meet all our needs?
Sometimes, rarely entirely. Established platforms are proven, maintainable and cost effective, but colleges have processes, compliance requirements and integrations that generic software does not cover out of the box. We use the platform where it fits and build the missing pieces where it does not, then connect everything so it works as one system.
How long does a typical project take?
A focused integration or workflow automation can be live in weeks. A full programme across recruitment, student records, learning and reporting usually runs six to twelve months. Every project is broken into short phases so you see working software early and can change direction while it is still cheap to do so.
Where is our data held and how is it protected?
Systems we host run in AWS in Ireland, with backups, monitoring and access controls in place, and we can also run inside your own AWS or Azure account. We sign a data processing agreement with every client. We are working towards ISO/IEC 27001 certification and can share our security practices on request.