Across 100+ homestay units in Johor Bahru, every repair follows one path: a report (cleaner, guest or staff) becomes a job in AntlerHub, the Handyman team accepts it, it gets a priority and a technician, the unit is flagged as under repair so nobody sells it broken, and the finished job writes its cost into the owner's monthly statement. This article walks through that path with the rules we actually use.
Why does dispatch matter more than the repair itself?
A leaking water heater is a RM 150 job. The same leak discovered by a guest at 11 pm on a Saturday, with no one sure who was told, is a refund, a bad review and a cancelled next booking. At 5 units you remember everything. At 30 you start losing track. At 100+ the only thing that works is a queue that nobody can skip.
Most articles ranking for "handyman dispatch software" are lists of apps for handyman companies. This is the other side: what a homestay operator needs the dispatch to do, written from the side of the operator that also runs the repair team.
Where do repair reports come from?
Four doors, all leading to the same queue:
| Source | How it arrives | Who files it |
|---|---|---|
| Cleaner after checkout | Cleaning app flags damage or a fault; it becomes a property task in AntlerHub | Cleaning team |
| Guest during stay | Guest feedback on WhatsApp; the duty staff files it with the /feedback command | Front-desk staff |
| Operator inspection | Raised directly from the unit page in AntlerHub | Our ops team |
| Owner | Owner tells us; we file it under the unit | Our ops team |
One rule here: no job exists only in a WhatsApp chat. If it is not in the queue, it is not being fixed. Everyone on the team knows that a message is a message, a job number is a promise.
What happens before a technician sees the job?
The Handyman side does not start work the moment a job appears. Every incoming job sits in a Requests list until the repair company accepts it. Until then it is invisible to technicians.
That sounds like bureaucracy, but it exists for a reason: in our system a client can hand any unit to any repair company without that company agreeing first. If jobs flowed straight to technicians, one wrong click would put a stranger's broken toilet on your Monday schedule. The acceptance step is the filter. For long-term clients (our own units included) we switch on auto-accept, so the step costs zero seconds in practice.
How do we decide what gets fixed first?
Every job carries one of four priorities, and the technician list is sorted by priority first, then by age:
| Priority | What it means in a homestay | Typical examples |
|---|---|---|
| Urgent | Guest is in the unit, or a guest arrives today, and the fault makes the stay unsellable | No water, no electricity, aircond dead in the master room, door lock failure |
| High | Unit is empty but booked within 48 hours | Water heater leak, toilet flush broken, fridge not cooling |
| Normal | Unit is empty with a gap, or the fault is cosmetic but visible | Blind cord, wardrobe hinge, wall scuffs, silicone resealing |
| Low | Owner request, upgrade, or "fix next time you're there" | Extra hooks, a loose cabinet handle, replacing a lamp shade |
The honest version of this table: the priority is only as good as the person filing the job. Our cleaners file damage straight after a checkout, so they see the unit empty. The staff who files guest complaints is looking at the booking calendar. Both get told to pick the priority by when the next guest arrives, not by how bad the fault sounds.
What does the unit calendar know about a repair?
This is the part that most standalone handyman apps cannot do, and the reason we built our own instead of buying one. When a job is created, accepted, started or completed, the event is written back to AntlerHub, which does three things:
- The task in AntlerHub changes status (open, in progress, done, cancelled) so the ops team sees the same state the technician sees.
- The unit's maintenance flag changes. A unit under repair shows a repair state on the turnover board, so nobody confirms a same-day booking into a room with no hot water.
- The final charge lands on the task. When the job is marked done, the amount is written back, and from there it flows into the owner's statement for that month.
If the write-back fails for any reason, the event is left marked as not yet pushed and the next sync picks it up. We would rather have a job pushed twice than a repair the calendar does not know about.
Who pays, and how does the owner see it?
Three cases, and the job record decides which one applies:
| Situation | Who pays | Where it shows |
|---|---|---|
| Wear and tear (water heater element, aircond gas, hinge) | Owner, as a unit expense | Owner's monthly statement, expense line with the job number |
| Guest damage | Guest, from the deposit | Damage claim on the reservation; the deposit refund page suggests the deduction |
| Our mistake (cleaner broke it, wrong instruction) | Antlerzone | Absorbed, not on the owner statement |
Parts are charged at cost with the receipt attached to the job. The owner can open any expense line on the statement and see the job, the photos and the receipt behind it. That is the single most effective thing we have done to stop "why is there a RM 280 charge" messages: the answer is already attached.
What does a technician actually do on site?
The technician's app is deliberately simple: today's jobs in priority order, the unit address with a one-tap map link, the access notes for that building, clock-in on arrival, photos, parts used, clock-out. Status moves from assigned to in progress when they start, and to done when they finish. If a part has to be ordered, the job goes on hold with a note rather than quietly staying "in progress" for a week.
Clock-in and materials go to the same system that runs payroll and expense claims, so a technician who bought a RM 45 tap on the way does not have to chase anyone for the money at month end.
What goes wrong, honestly?
A few things we still get wrong:
- Photo discipline. Before-and-after photos are required, but on a busy day a technician will do the fix and shoot one photo of the finished work. We catch it in review, not in real time.
- Priority inflation. When everything is urgent, nothing is. We periodically see a week where half the queue is marked urgent and have to re-sort it by hand.
- The owner wants a cheaper quote. Some owners prefer to bring their own contractor for bigger jobs. That is their right; we close the job on our side with a note saying the owner arranged it, so the unit history stays complete, but we lose visibility on the quality of the work.
Can other operators use the same setup?
Yes, in Johor Bahru. The Handyman team is open to any operator running on AntlerHub, with a flat monthly fee covering all your units and parts at cost. The current plan details are on the Handyman pricing page. The reason it is tied to AntlerHub is the write-back described above: the value is not the technician, it is that the repair, the calendar and the owner statement are one record.
If you run homestays in JB and your repairs still live in a WhatsApp group, that is the gap to close first. The channel manager article on what sync gets wrong and the piece on PMS vs Excel at 10, 30 and 50 units cover the other two places where the same "one record" rule applies.
This article describes our internal process and is not a service guarantee. Terms for the Handyman plan are as stated on the pricing page at the time of booking.