About Taskrol
Taskrol is appliance repair CRM and field service software. It was started by a working appliance repair technician and is built by the Kereon Inc. development team.
Why we built Taskrol
In appliance repair, the hard part is rarely the repair itself — sealed systems, control boards, the intermittent faults that never show up while you're standing in front of the machine. Good technicians are good at that part.
What wears a repair business down is everything around it.
Working with several companies at the same time is normal in this trade. In practice that means separate apps, separate logins, separate ways of doing everything. Finish a job, log out, log into the next system, and try not to write the diagnosis on the wrong company's ticket. Up to fifteen times a day. In a parking lot. With the next customer already calling. Here's how Taskrol handles subcontractors without the login carousel →
The van is its own mess. Anyone who does this work knows the picture: boxes of water valves, capacitors, thermostats, fuses, random hardware. You know the part is in there — you bought it two weeks ago. So you kneel in the back of the van and dig through boxes while the customer watches from the doorway. Some days go more to finding parts than to installing them. This is the mess we mean →
Then Sunday comes, and with it the weekly reports. Done by hand, they can take an hour and a half. Not because the numbers are complicated, but because the information is scattered: payments in one app, parts receipts folded in a jacket pocket, job details in text messages or just in someone's head. Every week the week gets reconstructed from fragments — what was installed, and what it cost. That became reporting built from the jobs and parts themselves →
The hardest part of appliance repair isn't repairing appliances. It's not losing information on the way between the technician, the office, the supplier, and the customer. Every dropped detail costs time. Sometimes it costs money. Once in a while it costs you the customer — like the call you miss while you're on a job and the next company on the list picks up. We built online booking that creates the job for that →
That's where Taskrol came from: being tired of doing everything twice.
The shortest path from the call to getting paid
Put the whole design philosophy in one sentence and it is this: the shortest possible path from the call to getting paid. Take the call, do the job, order the part, send the invoice, collect the money. The app should follow those actions in the same order — without extra steps or screens that exist only because the software expects them.
Take the most basic thing: a new job. Cactus Appliance, an appliance repair company in Orange County, California, ran on other CRMs before Taskrol, and in them you first create the customer, save, then create a job, then attach one to the other. Two entities, several screens, all while the customer is still talking. In Taskrol it's one screen — Quick Job. The customer and the job get created together, in seconds. That one decision is the whole philosophy in miniature: only the actions a technician actually takes, in the order they take them. Watch the 39-second Quick Job demo →
Used every day on real service calls
Cactus Appliance runs on Taskrol every day. The moment the shop counts on most is opening the statistics screen and trusting what's there. Income and expense reports build themselves from real jobs and real parts. These are not numbers reconstructed from receipts on a Sunday. They are the actual state of the business, on a phone.
The other thing the shop uses constantly is parts lookup. Type in the appliance's model number and the parts catalog and manuals for that exact unit are right there on the job. They are built into the job itself, where the technician needs them. See parts lookup inside the job →
The same rule applies everywhere: multi-company support came from the login carousel, Shopping Lists from part-number texts sent to the office, and AI invoices from evenings lost to paperwork. If a feature doesn't trace back to a real problem from the field, we don't build it.
Our test is simple: after a ten-hour day of service calls, would a technician still want to open this app? If the answer is no, it doesn't ship.