Features

A repair shop operations system, not just a POS.

A POS counts sales. A repair shop needs far more: intake, technician workflow, spare parts, payments, warranty, returns, receivables, payroll, customer messaging, reports, and accounting — all affecting each other. When those live in separate tools (POS here, stock in a spreadsheet, repairs in a notebook, payroll on a calculator), the owner becomes the integration layer — every single day.

Automan takes over that connecting work. It isn’t just a POS but one operations and finance system, and it’s modular: start with the repair workflow, then enable more as the shop gets serious.

The test of whether you have a system or a pile of tools is simple and slightly uncomfortable: if you took a week off, how much of the shop would keep working? In a shop where numbers travel by hand from one place to another, the honest answer is “not much” — because the connecting is a job, and you are the one doing it.

Parts of the shop that talk to each other

Every part of the shop has its place in the system, and none of them sits on its own:

Automan Repair dashboard showing service revenue, unit counts by status, and repair intake and completion charts Repair dashboard: monitor revenue, queued and in-progress units, parts waits, uncollected units, and unpaid balances from one screen. (App UI shown in Indonesian.)

One transaction, flowing everywhere

This is what separates a connected system from a pile of separate apps. When a repair is finished and paid — with no re-entry — the parts used reduce stock and form COGS, the labor becomes revenue, the technician’s commission is calculated, cash or receivables form, and it all lands in reports and accounting journals. You record once; the system connects the rest.

Count what that replaces. In a disconnected shop the same job means: writing the ticket, deducting the part from a spreadsheet, noting the commission in a notebook, entering the payment in the till, and copying the totals into the books that evening. Five actions, five chances to skip one, and no way to tell later which one you skipped. The single-entry version is not merely faster; it removes the category of error where the shop’s records quietly disagree with each other.

Morning at a counter, morning in a workshop

One operations system, two working days that look nothing alike. The difference is not cosmetic — it decides which screen you have open most of the day.

At an electronics counter, volume is the pressure. Units arrive small and numerous: a dozen or several dozen a day, each needing an identity so two identical handsets never get confused on the same shelf. The screen that stays open is the status board — who is working on what, which unit is waiting on a part, which is finished but not collected. The same customer asks about the same unit several times in one day.

In an auto workshop, size is the pressure. Fewer vehicles arrive, but one vehicle can mean three jobs, eight parts, and a yard that has to be arranged so the car at the back can get out. The screen that stays open is the job detail for one vehicle, not a long queue. Customers drop off and leave, so there is really only one message they are waiting for: is it ready.

Automan follows that difference through the business type you pick when setting the shop up. What changes is not a colour theme but the vocabulary and the fields, across the whole app:

At an electronics counterIn an auto workshop
Repair ItemVehicle
TechnicianMechanic
Item TypeVehicle Type
Unit ProviderVehicle Brand
ModelModel / Variant
SymptomsCustomer Complaint
IMEI / serial numberPlate number, chassis number, engine number, odometer, year

Workshops also have a habit counters do not: the vehicle intake checklist. Registration document, body condition, glass and wipers, exterior lights, tyres and wheels, brakes, fuel level, and the odometer reading are all recorded as the vehicle is booked in. It is not paperwork for its own sake — it is where liability stops, and it is what saves you the argument about whether that scuff was there this morning.

Before work starts, the cost estimate is recorded and prints on the intake receipt, so the customer leaves with a figure rather than a queue number. When the number moves once the job is opened up, the work stops at Awaiting Confirmation until somebody decides, then moves to Confirmation Approved or Confirmation Rejected — and the decision stays on the record rather than in somebody’s memory. Stated plainly: the phone call is still yours to make, and it is your staff who enter the outcome. The customer sees the status on the tracking page; there is no approve button on their side.

One boundary to plan around: a single Store App serves one kind of unit — general electronics or vehicles. A motorcycle workshop and a phone counter run as two Store Apps under one account, and that is precisely where multi-branch transfers start to matter. The trade-specific walkthroughs live at auto repair shop software and phone repair shop software.

Four places a disconnected shop leaks

The pitch for an integrated system is usually abstract. The leaks are not.

Stock that disagrees with the shelf. When parts leave for a job but the deduction happens at a weekly catch-up, the gap between the two is where variance lives. You find out a part is gone at the worst possible moment: with the customer’s vehicle already apart. Connected to the parts inventory, consumption and the record are the same action.

Commission arguments at month end. A technician keeps a private tally, you keep the job sheets, and the two do not match. Whoever is more certain wins, and the other one starts looking at job adverts. When commissions form from recorded work, the dispute happens on the day of the job or not at all.

Warranty claims you cannot verify. Someone returns three weeks later insisting the work is covered. Without a history — what was done, which delivery the part came from, what warranty was agreed — you approve it to avoid a bad review, and you eat the cost. A searchable service history turns that into a two-minute check via returns, claims and corrections.

Books that are always a week behind. Copying the day’s takings into a spreadsheet each evening is the job everyone skips first when they are tired. Skip it three times and the month is a reconstruction exercise rather than a record.

None of those four is dramatic on any single day. That is precisely why they persist: each one is small enough to absorb and frequent enough to matter.

Modular — start small, grow gradually

A complete system doesn’t have to be complex on day one. A small shop can start with the repair workflow, job tickets, and basic reports. The heavier parts — deep inventory, WhatsApp, commissions and pay, promotions, accounting — switch on when the shop truly needs them. Only what you switch on appears on screen, so the interface stays simple as the capability grows.

That matters more for staff than for owners. Owners tolerate a crowded menu because they know what everything does; a new counter hand does not, and a screen full of features nobody uses is how people end up avoiding the software and keeping a private notebook instead. The moment a parallel notebook appears, you have two versions of the truth again.

A new shop starts through the guided initial setup — the Business Type Wizard — six steps in order: Store, Units, Service, Products, Notes & Rules, then Review. Every recommendation can be deleted and replaced with your own lists if your shop works differently. It is worth not confusing it with the opening-balance wizard, which is a separate thing you use when migrating existing books into Automan.

What it does not do

A system is easier to trust when it names its edges.

No offline mode in the web version. The web app needs a connection: there is no queue of transactions waiting to sync and no local copy that catches up afterwards — we checked, rather than assumed, and there is nothing there. The exception is field work, where the Automan Mobile Android app keeps working when the signal drops and syncs its queued transactions once it returns. If your counter connection genuinely drops for hours, that is a real constraint and you should weigh it before committing.

Not everything a business does. Automan concentrates on the operations of a repair business and the retail that surrounds it. It is not an ERP for a manufacturing supply chain, and we would rather say so than let a mismatch surface three weeks into your setup.

Built in Indonesia, priced there. Lite is Rp 0 and Pro is Rp 15,000 per month, with no separate USD price list. Support runs in Bahasa Indonesia, and the app interface is Indonesian. Over 1,767 repair businesses run on Automan today, and they are Indonesian businesses — that is honest evidence of traction, not a claim of global footprint.

Not just a POS

Calling Automan a “POS app” is like calling a car “a seat on wheels” — not wrong, but it misses the point. The POS is one door. What makes Automan different is how every part of a repair shop connects into a single source of truth.

The practical version of that is unglamorous. It means the parts number in the stock screen and the parts number in the profit report were never separately maintained, so they cannot disagree. It means a commission and the expense in the books are the same event seen twice, not two entries someone has to reconcile. And it means the week you take off is a week off, rather than a backlog waiting for the only person who knows how the pieces fit.

Not sure what you need? Read the guide to choosing repair shop software — a checklist and demo questions that help you evaluate any app objectively, including ours.

FAQ

Is Automan too complex for a small shop?
No. You don't need all of it on day one. Start with repair intake, job tickets, customer tracking, and basic reports. Add inventory, messaging, commissions, promotions, or accounting when your shop needs them.
Is Automan a POS app or a repair app?
Neither label quite fits. Automan is an operations and finance system for repair and retail businesses — the POS is just one part. Inside it are the repair workflow, inventory, purchasing, sales, returns, WhatsApp, reports, commissions and pay, access control, and accounting — whichever parts you switch on.
Do I have to enter the same data multiple times?
No. Because every part is connected, one transaction flows through the whole system — a completed repair reduces stock, forms revenue, calculates commission, and reaches reports without re-entry. You record once; the system connects the rest.
Is this built for auto workshops or for electronics repair counters?
Both, though not inside the same shop. When you set up a Store App you choose a business type, and that choice relabels the app throughout: Repair Item becomes Vehicle, Technician becomes Mechanic, Item Type becomes Vehicle Type, and vehicle identity fields appear — plate number, chassis number, engine number, odometer, and year. One Store App serves one kind of unit: general electronics or vehicles. If you run a workshop and a phone counter, they run as two Store Apps under a single account.
Can a customer approve the cost estimate through the app?
Not by tapping a button themselves — but the confirmation stage is real and the job genuinely waits for it. The estimate prints on the intake receipt, and when the figure has to be checked the job stops at Awaiting Confirmation until somebody decides, then moves to Confirmation Approved or Confirmation Rejected with the decision kept on the record. Your staff enter that decision after phoning or messaging the customer. The customer can see the status on the tracking page; there is nothing there for them to press.
Does it work offline?
The web version, no: it needs an internet connection, with no offline mode, no queued transactions, and no local sync that catches up later — we would rather state that plainly than let you discover it during a power cut. Field work is the exception: the Automan Mobile Android app keeps working when the signal drops, queuing transactions on the phone and sending them once it returns. If your counter connection is genuinely unreliable, that is a real constraint worth weighing before you commit.

Already know the problem?

See the workflow demo that matches it.