Aura Business is built for lift maintenance businesses: several cars under one building contract, periodic inspection cycles that must be evidenced, entrapment calls that outrank everything else in the day, and spares that only fit one model.
Lift maintenance software has to model a building before it models a machine. One agreement covers four cars in a tower, or nine across a campus, each with its own model, controller, load and installation date, and each needing its own visit record. The customer you deal with is a building manager or an association secretary, not the person who bought the lift, and what they judge you on is whether the cars ran and whether you turned up when someone was inside one.
That gives the work two rhythms running at once. There is the planned rhythm, the periodic maintenance and the periodic inspection cycle that has to be evidenced with dates, readings and a signature. And there is the interrupt rhythm, the entrapment or breakdown call that has to be dispatched immediately and beat everything already on the technician's list. Aura Business holds the contract against the asset register of cars, raises the planned visits per car, runs intake and dispatch with a response clock for calls, and keeps spares against the model rather than as one undifferentiated pile.
None of these are complicated. They are all consequences of a contract, a machine list and a call register living in three different places.
Cars were modernised, controllers replaced and one was taken out of service, and the agreement still lists the original set.
The visits happened, but the proof is in a logbook in the machine room that nobody in the office can see.
The urgent call reaches a technician directly, so there is no logged time, no dispatch record and no closing note.
A part bought for one model sits in the van for a year because nobody knows which cars it suits.
Every association meeting needs a list of visits and breakdowns, and it is rebuilt by hand each time.
A contract ends, the visits stop, and nobody notices until the building rings about a breakdown you are no longer paid for.
Each lift is an asset with its building, wing, model, controller, capacity and installation date recorded once.
One contract covers the listed cars, with visit frequency, what is covered and what is excluded set out on it.
Preventive maintenance schedules raise visits per car by date or usage, with the checklist attached to each one.
Entrapment and breakdown calls come in through the desk or the customer portal and start an SLA timer at intake.
The call is assigned to a technician who works on that model and can actually reach the building quickly.
The mobile job card records the fault, the parts fitted against the car, photographs and the building signature.
The building gets a visit and breakdown history it can read, and the renewal engine raises the offer before expiry.
Workflow: The call is logged at the desk against that specific car, a timer starts, and dispatch goes to the nearest technician trained on the model.
Result: A response time you can show, not one you claim.
Workflow: Visits, breakdowns, parts and downtime are already attached to each car under the building contract.
Result: A report printed rather than assembled.
Workflow: Parts are catalogued against the models they suit, and consumption is booked against the job that used them.
Result: Van stock that matches the buildings on the route.
Workflow: The renewal engine works from contract end dates and raises the offer while the service record is still fresh.
Result: Renewal discussed before a lapse, not after.
Contracts on cars installed by several different makers.
Installation, warranty period, then the maintenance contract.
Heavier planned work in malls, stations and airports.
Associations and secretaries as the paying customer.
Lifts as one asset class inside a wider site contract.
Problem: A distribution business run entirely on WhatsApp and Excel.
Built: Field app, manager dashboard, GST billing and payment tracking.
Stack: React Native, Supabase, WordPress.
Problem: No online store or way to manage distributors.
Built: Storefront, distributor portal, quote-to-order and 253 SEO pages.
Stack: Supabase, JavaScript, Playwright.
Yes. The contract covers a listed set of assets, and each car keeps its own model details, schedule, visit record and fault history. A campus or a group of buildings under one customer can sit on a single multi-site contract.
Both are logged at intake so the clock starts from a recorded time, and the SLA definition on the contract decides the response expected. Dispatch can then be made on skill and proximity rather than on who answers the phone first.
Preventive maintenance schedules raise a visit per car with a checklist, and the completed job card carries the date, the technician, the readings entered, photographs and the customer signature. The record sits against that car permanently.
Parts are held in the catalogue against the models they suit, and every part fitted is booked against the job card, which drops stock. Over a few months that gives you real consumption per model rather than a guess.
Yes. The customer portal and helpdesk let a building manager raise a call, follow its status and see the visit history for their cars, which also gives you a clean logged time to measure response against.
Yes. A job can be recorded as covered or chargeable, with parts and labour raised on a service invoice where the work sits outside the agreement. What is covered is held on the contract so the desk can check at intake.
The full operations platform.
Seasonal contracts across many units.
Timers, breaches and proof.
Getting the right technician there.
Every machine you are responsible for.
What an SLA really commits you to.
Many small devices, different intervals.
Tell us how you work today. We will show you what the platform would look like for you, and give you a clear scope and timeline.
Founder-led · Chennai, India · Built and supported by the person who wrote it