Attua / Industries / IT and managed services
AI for IT consultancies and managed service providers
You already sell this. The awkward part is that the provider is usually last in the queue for its own improvements, because every hour that could go into internal tooling has a client waiting for it. This page is laid out as the ticket lifecycle, before and after, so you can see where the time goes back.
Book a discovery callThe honest version
Why this is a different conversation inside a provider
Every other industry page on this site is written for a business learning what these tools do. You are not that. Your engineers have opinions about model providers, somebody has already wired a webhook into a chat tool, and there is a half built internal project sitting in a repository that nobody has touched since a large client went live.
So the problem is not knowledge. It is that internal work is unbillable, and unbillable work loses to billable work every single week until somebody protects it. The second problem is more subtle: providers tend to build the clever thing rather than the boring thing. An engineer will happily spend a fortnight on an alert enrichment pipeline and leave the quarterly reporting pack, which eats two days of a service delivery manager's month, exactly as it was.
The boring work is where the return is. Triage, documentation, time narration, reporting and pre sales paperwork are high volume, low variation and text based. That is the shape of work worth building around.
The lifecycle
A ticket from arrival to invoice, before and after
| Stage | How it runs now | How it runs after |
|---|---|---|
| Arrival | Email, phone and portal all land differently. Somebody reads each one to work out what it is. | Intake is read once, with the client, site, affected user and likely service area already identified from the text and the asset record. |
| Triage | Category and priority set by whoever is on the board, inconsistently, which ruins reporting later. | A proposed category, priority and queue against your own definitions, with the reasoning shown so the dispatcher can disagree in one click. |
| First response | A template, or nothing, until an engineer picks it up. | A drafted reply that names the actual issue, references the last 2 similar tickets for that client, and asks for the one piece of information the engineer will need anyway. |
| Diagnosis | Engineer searches IT Glue, then the ticket history, then asks in the team chat. | A context pack on open: the client's documented configuration, prior tickets on the same asset, and any current alert or advisory that may be related. |
| Action | Engineer does the work in the client environment. | Unchanged. This is the step we deliberately do not touch. |
| Documentation | Promised, then skipped. Documentation debt grows quietly for years. | A drafted document or an update to an existing one, produced from what the ticket actually recorded, queued for an engineer to approve or discard. |
| Time entry | Reconstructed on Friday, under recorded, with narrations a client queries. | Suggested entries with a client readable narration from the ticket notes, for the engineer to confirm before the day is over. |
| Closure | Resolution note written in haste, or copied from the last one. | A drafted resolution note and client summary, with closure held until a person confirms the fix held. |
| Reporting | Two days a month assembling a quarterly pack per client out of BrightGauge exports and screenshots. | A drafted pack per client: ticket themes in plain language, recurring causes, asset and licence position, and the 3 recommendations worth discussing. |
| Pre sales | Scoping notes become a proposal written by the owner at night. | A drafted scope of work and proposal from the discovery notes and your own previous statements of work, for the owner to price and sign. |
Read the right hand column as drafts. Every row ends with a person, which is the only version of this that survives contact with a managed services agreement.
Hard limits
The things a workflow is not allowed to do
A provider holds privileged access to dozens of other businesses. That makes the blast radius of a careless automation larger than anywhere else I work, so the exclusions get written before the first workflow is designed.
Not now, not with approval, not later:
- Making a change in a client tenant. No conditional access policy, no mailbox rule, no firewall object, no Intune configuration.
- Performing identity verification before a credential or multi factor change. A person verifies a person, and the verification is recorded by that person.
- Deciding whether an event is a security incident, or writing to a client to say that it is not one.
- Closing a ticket, releasing a change, or marking a backup as verified.
- Answering a client question about whether they are compliant with anything.
- Touching credentials, secrets or recovery keys in any form, including reading them to summarise a document that contains them.
Those are not cautious defaults waiting to be relaxed as confidence grows. They are the line, and a provider that blurs it is one prompt injection away from a very bad week.
Australian context
Essential Eight, breach reporting and what clients now ask you
Three things have changed what an Australian client expects from their provider. The Essential Eight Maturity Model published by the Australian Cyber Security Centre is now the common language for a maturity conversation, and clients want to see where they sit against it. The Notifiable Data Breaches scheme under the Privacy Act means a suspected eligible breach has to be assessed inside a defined window, and you are usually the one assembling the facts. And the ransomware payment reporting obligations introduced under the Cyber Security Act 2024 have given owners a reason to ask questions they previously left to you.
Alongside that, more clients arrive with their own requirements attached: an ISO 27001 certification to maintain, an IRAP assessed environment for government work, a Right Fit For Risk assessment because they deliver disability services, or obligations under the Security of Critical Infrastructure Act. Each one brings a questionnaire.
- Essential Eight posture summaries per client
- Breach assessment fact packs for a person to verify
- Security questionnaire first drafts
- Policy and procedure reviews against your own control set
- Advisory triage against your actual client footprint
- Board ready summaries written in plain language
All of those are assembly and writing, which is where the help is. None of them are an assessment, which stays with your security lead and, where it matters, an assessor with the right credentials.
Documentation debt
Documentation debt is the problem under the problem
Ask any provider owner what they would fix and documentation comes up within 2 minutes. IT Glue or Hudu is partly populated and nobody can say which parts. The gaps sit in exactly the places that hurt: the client where one engineer knows everything, the legacy line of business application, the site with the odd network. Every onboarding, every handover and every after hours escalation pays for it.
Documentation projects fail because they ask engineers to write documents separately from doing work. The version that holds is drafting documentation as a by product of resolved tickets and configuration data, then asking an engineer for a yes or no rather than a page of prose. You get coverage where the work is happening, which is where the gaps are.
If you want the sequence mapped before anything is built, that is AI strategy, and the build itself is AI implementation.
Your stack
Where this plugs into a service desk
- ConnectWise PSA, Autotask or HaloPSA
- Ticket intake, triage proposals, time narration drafts and resolution notes, written back only after a person confirms.
- IT Glue or Hudu
- Documentation drafted from resolved work, with an approval step so nothing enters the knowledge base unreviewed.
- Datto RMM, NinjaOne, N-able or Auvik
- Alert and advisory noise translated into client readable language, grouped by cause rather than by device.
- Microsoft 365, Entra ID and Intune
- Read only reporting for licence position, stale accounts and configuration drift. No writes, by design.
- BrightGauge and your reporting layer
- Quarterly pack drafts per client, with the themes and recommendations written out rather than left as charts.
- Your proposal and contract library
- Scopes of work and proposals drafted from discovery notes and the agreements you have already signed.
How it runs
What a Diagnostic looks like with technical people in the room
A Diagnostic comes first, and with a provider it moves faster than usual because your team can answer questions precisely. Expect it to be a working week rather than a workshop: time on the board with the dispatcher, a session with the service delivery manager on the reporting month, and a look at the last 500 tickets to see where the volume genuinely is rather than where it feels like it is.
The output is a short sequence with an argument for the order, the exclusions written down, and the one or two things I would not build. Then four to six weeks on the first workflow, running beside the current process, measured on whether an engineer accepts the draft or rewrites it. Acceptance rate is the only metric that matters early.
Illustrative example, not a client story
Example scenario: the reporting month that eats a service delivery manager
Picture a provider with 38 managed clients and one service delivery manager who owns quarterly reviews. Each pack means pulling ticket data, licence counts, patch status and project progress, then writing a page of commentary nobody reads closely because it says much the same thing every quarter. A full week per quarter goes into assembly, and the reviews that would actually sell the next project get rescheduled.
In this example the pack is drafted per client from the systems that already hold the data, with the ticket themes grouped by cause, the licence and asset position stated plainly, and 3 recommendations proposed from what the quarter actually showed. The service delivery manager spends an hour per client correcting, cutting and adding the judgement that makes it useful, then runs the meetings they previously had to cancel. Illustrative example, not a client story.
Data
Client data when you hold keys to 40 businesses
Your position is unusual. You are both a data holder and a data processor for other people, and the obligations your own clients carry flow through to you by contract. Most providers already have the right instincts here. What tends to be missing is a written position on these tools specifically, which is what a client's auditor will ask for.
The setup we use: business grade accounts with training on your data switched off, each workflow scoped to one system rather than the network, no credentials or secrets in scope at all, a record of which workflow produced which draft, and client level exclusions where a managed services agreement or a client policy rules it out. Personal information in tickets is handled under the Privacy Act and the Australian Privacy Principles, and tickets containing health or financial information get tighter handling than the rest.
Your engineers also need a rule they can follow at 11pm without asking: what may go into which tool, what never does, and who decides. Writing that and training the team on it is AI training, and for a provider it is usually the first deliverable rather than the last.
Every job is scoped up front after a Diagnostic. Sam is based in Fortitude Valley, Brisbane, and travel is charged at cost from Brisbane. See the cost guide.
Questions
Common questions from provider owners and service delivery managers
We sell AI to our own clients. Why would we bring someone in?
Because your engineers are billable and this is not billable. Most providers I speak to have a half finished internal project that keeps losing to client work, and a service delivery manager who knows exactly which workflow would help but has no quiet fortnight to build it. Bringing someone in is usually about sequencing and capacity rather than capability.
Can it close tickets on its own?
No. It can draft a resolution note, propose a category and suggest the closure, and an engineer confirms. Automatic closure is how a provider ends up with a clean board and an angry client, because the signal that a fix did not hold arrives after the ticket has gone.
Will it reset a password or approve an MFA request?
Never. Identity verification before a credential change is the one control standing between your service desk and a social engineering attempt, and the person verifying has to be a person. A workflow can prepare the ticket and present the verification steps. It does not perform them and it does not decide that they were met.
Does this run inside client tenants?
By default, no. The work sits in your own systems: the PSA, your documentation platform, your inbox, your reporting. Where a client specifically wants something in their tenant it is a separate project with their written approval, their data handling requirements and their change process, not an extension of ours.
Our documentation is a mess. Is that a blocker?
It is the reason to start, and it changes the sequence. If IT Glue or Hudu is half populated, the first workflow is usually drafting documentation from resolved tickets and configuration data for an engineer to approve, which fills the gap as a by product of work already being done.
How do you handle client data when every client is different?
Scope per workflow rather than per provider. Each one gets read access to the single system it needs, client material stays out of consumer tools, and clients with contractual restrictions are excluded at the account level. If you hold an ISO 27001 certification or an IRAP assessed environment, the design has to fit inside it rather than beside it.
Talk it through with Sam
Book a 30 minute discovery call about how your business runs today.
Related: Professional services · Engineering firms · Recruitment and labour hire · AI consultant Brisbane · All industries