Case studies — Smarterapps Ai
Energy AI automation
How an Australian energy business can give crews the job on a device, tell customers what is actually known about an outage, and keep switching and safety with the people who hold that authority.
The situation
What was getting in the way.
An Australian energy business split field work, customer outage calls and asset defects across a works system, a call script and photos on crew phones. Customers were told crews had been dispatched because that was the script, not because the job said so. Defects found on site were written up back at the depot.
Operations wanted a crew app and a customer status that could only say what the job knew. They did not want an assistant advising switching, isolation or anything else that sits with an authorised operator.
This anonymised use case is a composite of the energy and utilities work Smarterapps Ai designs. It is not a named retailer or network and it does not claim a reliability statistic.
Read the matching industry page on Energy and utilities AI, or talk to us via contact or chat.
What we would build
The app, the assistant and the automation.
Each part is scoped so a person keeps the decision that matters. This is the shape of the engagement, not a claim that every module ships on day one.
01 — Crews
Field crew app
The job, the asset, site notes and defect photos, with offline capture for the parts of the network that do not have signal.
02 — Customers
Outage and job status
Customer updates drawn from job events you mark as customer-safe. If the event has not happened, the message does not pretend it has.
03 — Work
Work order flow
Defects drafted into the work order your asset system expects, released by the role that already releases work.
04 — Assets
Defect capture
Identification, photo and condition recorded against the asset while the crew is standing at it.
05 — Knowledge
Procedure assistant
Crews retrieve the procedure you published, with the section cited. The assistant does not invent a switching step.
06 — Systems
Customer and asset integration
Status and defects write to the customer and asset systems you already audit.
How it runs
From the first request to the system of record.
The automation prepares work. It does not take the action your organisation reserves for a person.
Step 01
The crew takes the job that was released
The app shows the released work, not a shadow list. Completion and defects sync when the device can.
Step 02
Customers hear job events
Messages use states you have approved for customers. Dispatched is said only when that event exists.
Step 03
Defects become work, after a person
A draft waits for release. The assistant does not schedule live work or alter the network model.
Step 04
Procedures are retrieved, not rewritten
The assistant cites the current procedure. Authorised operators keep switching and isolation.
Outcomes
What this pattern is built to change.
Crews close the job they were given. Notes and photos land on the asset, not in a camera roll.
Customer status that matches the job. Scripts stop outrunning events.
Defects raised the same day. The depot is not reconstructing a fault from a radio call.
Safety authority untouched. Switching, isolation and access remain with authorised people and the systems that already govern them.
Controls
What the automation is not allowed to do.
Customer messages are allow-listed states, not free text from a model. Network control actions are out of scope for the assistant. Crew access follows existing authorisations. Offline work syncs as the user who captured it, and is not marked complete in the asset system until sync succeeds.
Smarterapps Ai builds the software and the operating guardrails with you. We do not invent a compliance position for your sector. The person you already hold accountable — clinician, adviser, officer, supervisor — still makes that decision.
This page is an anonymised composite use case. It uses a realistic Australian scenario. It is not a published result for a named organisation.
Keep going
Industry page, services and chat.
The industry page covers how we build. This page covers one operating pattern.
Related: Services · AI developers · Workflow automation · AI agents · Document AI · AI customer chat · Contact · All case studies →
You can also open the chat on this page and describe the workflow. A person follows up from there.
01 — Use case
How an Australian nonprofit can answer supporters from the CRM, roster volunteers without a spreadsheet, and get grant documents into a file a program lead can actually.
02 — Use case
How an Australian media business can give audiences a faster path to the right story, help producers research from their own archive, and move a piece through editorial.
03 — Use case
How an Australian healthcare provider can take pressure off reception and clinicians with a patient app, an enquiry assistant grounded in approved information, and.
FAQs
Questions we expect on the first call.
Can the assistant advise switching?
No. It can show the procedure you published. Switching and isolation stay with authorised operators.
How do customer messages stay accurate?
They are tied to job states you approve. The assistant does not compose a reassurance the job does not support.
Does the crew app need coverage all day?
No. Capture queues on the device. Completion hits the asset system when sync succeeds.
Where next?
One work type and the outage message you are willing to publish. Contact or chat.
Start with one workflow
Say only what the job knows.
We will take one work type, the customer states you are willing to publish, and the asset system a defect should land in. Or open the chat on this page.