AI for appliance repair businesses: making the second trip the last one.

Appliance repair turns on two things that set it apart from other home-service work: a model and serial number printed on a plate somewhere inside the machine, and a job that splits into a diagnosis visit and a return visit once a part has been ordered. A wrong digit at intake orders a wrong part, and a wrong part sends the van out a third time. A coverage question nobody asked can mean diagnosing a fault the manufacturer would have repaired under its own warranty, and a recall nobody looked up means the household hears about it from someone else.

Assistants built on Grok Bot can prepare much of what makes the return visit final: a model number read from the customer's rating-plate photo with anything unreadable flagged, a coverage-and-recall note for the technician, a list of parts on order, and a drafted message when a part arrives. They do not diagnose, decide whether a warranty applies, say anything about a recall beyond the official notice, or open a sealed refrigerant system. The owner and the technicians make those calls.

Consider, as an illustration, a company with three technicians, an owner who still runs calls, and one person in the office on weekdays. Its part-dependent jobs follow one arc: an inquiry describes a symptom, a technician diagnoses, a part is ordered, and a technician comes back to fit and test it. The table lists the ways that arc grows an extra trip, and what the office could have had in hand to prevent each one. None of these is a statistic; they are the failure points the back office is there to close.

In Grok Bot, as its documentation describes it, an owner sets up Bots by name, gives each one a job and talks to each in a separate thread, while all of them work from one persistent cloud computer that holds files, a browser and a terminal. A photo goes into a Bot's thread as an attachment: up to six files per message from the desktop app, and up to twenty-five megabytes for an image. iPhone users can push a picture in through the system share sheet; on Android that sheet takes text only for now, but the phone app can still take or attach a photo inside a chat. Telephony is absent from the documentation, so an inquiry taken by phone arrives only as notes somebody typed.

The Intake Bot here is the owner's creation under Aevrion's pattern, not a feature of the product. When a customer emails a photo of the rating plate, the owner, who holds the account the Bots belong to, attaches it to the Intake Bot's conversation; alternatively, a custom integration with the booking form could save uploads to a folder the Bot reads, if the form's vendor permits it and once tested. The Bot transcribes brand, model and serial into the job record and marks every character it is unsure of. It never completes a number from memory or from a similar model, because two numbers that differ only in a suffix are not safe to treat as the same machine.

Each transcription ends in one of four flags, and only the last one lets a part be ordered against it.

• UNREADABLE

  Glare, grease or wear hides a character. The Bot names the character it could not read and drafts a request for a sharper photo, which the owner sends.

• MISSING

  The customer could not find the plate. The draft points them to the places listed in the owner's own guide for that kind of appliance; the Bot does not invent a location.

• MISMATCHED

  The brand on the plate differs from the brand in the inquiry, or the photo shows a different appliance from the one described. The Bot reports the conflict and a person settles it.

• CONFIRMED

  A person has compared the transcription with the photo, character by character. Only a confirmed model number goes on a parts order or into a recall search.

Based on the Grok Bot documentation at docs.x.ai as checked on 15 October 2026. Its statements on Bot rules, Bot-to-Bot messaging, routine triggers, connected apps, approval expiry and payments were rechecked against docs.x.ai and Cursor's help pages on 26 October 2026. The trade examples are Aevrion's illustrations, not documented Grok Bot use cases. Aevrion Ops is an independent consultancy. It is not affiliated with, endorsed by or a partner of xAI, SpaceXSI or Cursor. Grok Bot is named here only to describe it.

Before the van goes, the office wants to know if someone else is already responsible for the repair: the maker under its warranty, the seller of a service contract, or a recall. In this design a Bot prepares a short note for the technician and the owner: what the customer said about the purchase date and any contract, the warranty document the owner keeps for that brand, and the result of a search of the US Consumer Product Safety Commission's recall listings, with links. Whether a warranty applies is the warrantor's decision, and what the household is told is the owner's.

Federal guidance shapes how that note is worded, as checked on 15 October 2026. The Federal Trade Commission's business guidance on the Magnuson-Moss Warranty Act says that picking an outside repairer, or a part from another maker, is not by itself, outside narrow exceptions, something a warrantor can use to void a written warranty or refuse coverage; damage that part or that repair caused can still be excluded. And a recall remedy is whatever the official notice says, relayed as written. The warranty-and-recall intake guide in this series sets out the check itself, step by step.

So the Bot never drafts "you're covered", and never drafts "using us won't affect your warranty". Where the note suggests a warranty may apply, the owner tells the customer to contact the warrantor and decides whether the visit still goes ahead as a paid call. A dispute about coverage is between the customer and the warrantor, and the owner takes legal questions about it to a lawyer.

Once a technician has diagnosed the fault and the customer has approved the quote, the owner orders the part. In this design a Parts Bot adds the order to a list in the computer's shared workspace, tied to the job and to the confirmed model number. Reading a supplier's order status takes either a custom integration, if the supplier's API or terms allow one, or the Bot working the supplier's website under supervision, where the supplier permits that and once it has been tested. The owner signs in to the supplier's site and takes over the computer for passwords, two-factor codes and payments; the Bot pays for nothing. Cursor's help pages add a Vault, where saved logins and cards let a Bot sign in and check out without seeing them, and no setting asks for approval each time a saved card is used, so this design saves no card there.

When the supplier's record shows a part delivered, the Bot drafts a part-arrived email offering the return windows the owner has set. The draft waits in the owner's conversation with the Parts Bot, to be edited, sent or discarded there. The delivery status is reread from the supplier's record on every check rather than recalled, since the documentation's advice is that facts which change belong in their source system, with a Bot's memory never standing in for it.

For a shop with a single technician, that list is close to the whole backlog. The one-tech guide in this series follows nine open parts jobs through a week, including a household that keeps asking for a date the supplier has not yet given.

In the United States, Section 608 of the Clean Air Act and EPA's rules under it make refrigerant work a credentialed job: a person whose maintenance, servicing, repair or disposal work could let refrigerant escape needs Section 608 certification, as checked on 15 October 2026. EPA describes the work that makes someone a technician: attaching hoses and gauges to read pressure, adding or removing refrigerant, and other work that breaks into a small appliance's refrigerant circuit, other than disposal. Type I covers servicing small appliances, which the federal rules define as appliances sealed in the factory with five pounds of refrigerant or less, naming refrigerators and freezers designed for home use, dehumidifiers and window air conditioners among them. The credentials do not expire, and an apprentice may do the work without one only under close, continuous supervision by someone who holds it.

The office's part is routing, not judgment. When a diagnosis points to the sealed system, the job goes back to the owner, who books a technician whose card shows Type I or Universal certification, or refers the work out. A Bot can keep the list of who holds which type, built from copies the owner supplies; it never decides that a fault is in the sealed system.

A company working in Great Britain has a parallel line for gas cookers and hobs. HSE's householder guidance, checked on 15 October 2026, puts it plainly: a person employed on gas appliances in someone's home has to be on the Gas Safe Register and competent for that particular kind of gas work, and the back of the engineer's register ID card lists what they are competent to do. A gas cooker booking therefore goes only to an engineer whose card covers that work, and a person makes that check.

Start small, the documentation advises: give one Bot a whole outcome, and add a second only once there is a specialist job that will stay stable. Here the Intake Bot comes first, since a parts order, a recall search and a warranty lookup all start from its confirmed number; the Parts Bot once intake is reliable; and a Coverage Bot for the warranty and recall notes when the owner's warranty library is worth reading. These roles are Aevrion's design. Handoffs between them are files saved in the shared workspace, which every Bot on the account can open.

All three share one cloud computer, and with it every saved login. Once the owner signs in to a parts supplier for the Parts Bot, the Intake and Coverage Bots could reach the same session, because separate Bots are not a security boundary. A login that should stay with the owner alone stays off that computer.

Scheduled routines are allowed, spaced five minutes apart at the closest. In this trade a midday routine that lists every open inquiry still waiting on a confirmed model number fits well; the owner chases each one before the next morning's visits. The documentation ties the need for approval to the particular tool, how risky the action is and the rules the owner has written, so there is no single switch for it.

A second trip turns into a third when a job sits in a state nobody holds. Writing the repair down this way gives every state a person, and leaves the Bots preparing only what that person needs to move it on.

1. 1

   Inquiry

   Owner

   The office, from the Intake Bot's transcription

   Advances when

   A person confirms the model number against the plate photo

   Ends when

   The customer books elsewhere

2. 2

   Checked

   Owner

   The owner, reading the coverage-and-recall note

   Advances when

   The owner books a paid visit or points the customer to the warrantor

   Ends when

   A warrantor or an official recall remedy takes the repair

3. 3

   Diagnosed

   Owner

   The technician on site

   Advances when

   The customer approves the quote

   Ends when

   The customer declines or decides to replace the appliance

4. 4

   Part on order

   Owner

   The owner orders; the Parts Bot tracks the supplier's record

   Advances when

   The part arrives and a person matches its number to the order

5. 5

   Return booked

   Owner

   The owner, who sends the drafted message

   Advances when

   The customer confirms a window in writing

6. 6

   Repaired

   Owner

   The technician, who fits and tests the part

   Advances when

   The test passes and the owner raises the invoice

   Ends when

   A further fault starts a new diagnosis

The first deliverable in this trade is a written intake rule: what a usable plate photo shows, who confirms the transcription, and what happens when the customer cannot find the plate. Test it by hand on recent jobs that needed a second parts order. Where a confirmed model number would have stopped the wrong part, the rule is ready for the Intake Bot, and the Parts and Coverage Bots can follow later.

Next, take the workflow automation readiness assessment, which is free to use and asks for no sign-up. Score one workflow in it, intake from first inquiry to confirmed model number, against its twelve dimensions; it returns a result straight away as one of four outcomes, says what is holding that workflow back and what step to take after. Expect data availability to score low if past job records hold a brand and a symptom but no model number. After that, a scoping conversation with Aevrion Ops would cover the intake rule, the coverage note, the parts list and any custom link to your booking form or job software, each one only where the vendor's API or terms allow it and only after testing.

1. A part-dependent appliance repair takes two visits; the back office's job is to stop it needing a third.
2. Intake starts with a rating-plate photo; the Bot flags unreadable, missing and mismatched details, and only a person-confirmed model number is used.
3. The coverage-and-recall note is written for the people who decide; no Bot tells a customer they are covered.
4. Parts on order sit on a list checked against the supplier's own record; part-arrived drafts wait for the owner to send.
5. Sealed-system work goes to a technician holding the right Section 608 type, and in Great Britain gas cooker work to a Gas Safe registered engineer.
6. Grok Bot's documentation describes no telephony; the Bots work from written inquiries and photos.