Phone Repair Intake Form: Turn Customer Messages Into Tickets With AI

Paste the customer's message into an AI assistant that holds your intake fields and price list, and ask it to return a structured ticket: device, fault, urgency, what it could not tell, the questions to ask, and a provisional quote from your own price list. A person confirms the device and parts before anything is booked.

The aim is not to replace the intake form but to fill part of it before the customer arrives. Messages are vague ("the screen is broken, how much?"), so the most useful output is the list of gaps: which exact model, since the price depends on it; whether liquid was involved; whether the data is backed up; whether Find My is switched on. A quote and a diagnosis stay provisional until the phone is on the bench.

Follow me on Instagram@sagnikteaches

One message, start to finish: a cracked iPhone 13

The message below is invented, but it is typical of what arrives on a weekday morning: no name, a model that might be one of several, a fault with two symptoms, a deadline and a price question, all in one breath.

Connect on LinkedInSagnik Bhattacharya

hi, my iphone 13 dropped on the pavement yesterday, screen cracked all across and theres a green line down the left side. touch still works. i need it back by tomorrow because of work. how much and can you do it today?? thanks

The shop's assistant, loaded with the field list and the price list (both described below), returns the following. In an automation this would be machine-readable JSON, which is why it is shown that way (illustrative).

Subscribe on YouTube@sagnikteaches

{
  "device": {"brand": "Apple", "model": "iPhone 13", "variant_confirmed": false},
  "fault_category": "screen",
  "customer_words": "cracked all across, green line down the left side, touch still works",
  "how_it_started": "dropped on pavement, yesterday",
  "other_functions": "touch works; others not mentioned",
  "liquid_contact": "not mentioned",
  "urgency": "wants it back tomorrow; asks if same-day is possible",
  "customer_questions": ["price", "same-day repair"],
  "unknown_fields": ["name", "email", "exact model (13, 13 mini or 13 Pro)", "liquid contact",
                     "backup", "Find My status", "other damage to back glass or frame"],
  "provisional_quote": {
    "basis": "price list: iPhone 13 screen",
    "options": [
      {"grade": "aftermarket", "price": 109, "stock": 2},
      {"grade": "refurbished original", "price": 149, "stock": 0}
    ],
    "status": "provisional until the model is confirmed and the phone is checked at the bench"
  },
  "do_not_record": ["passcode"]
}

Three details make this output usable rather than merely tidy. It says "variant_confirmed: false", because "iPhone 13" could mean the 13, the 13 mini or a Pro, and the price depends on which. It lists everything it does not know instead of guessing, so the reply to the customer is half-written. And the quote comes from the price list with its stock figure, so it is the shop's number, not the model's recollection of typical prices.

The assistant also drafts the reply for a person to read and send (illustrative).

Hi, thanks for getting in touch, and sorry about the drop. A screen replacement for an iPhone 13 is $109 with an aftermarket screen, or $149 with a refurbished original, and we have the aftermarket one in stock. That price is provisional until we see the phone. Could you send a photo of Settings > General > About so we can confirm it is a standard iPhone 13, and tell us: 1) whether it has been near water; 2) whether it is backed up; 3) whether Find My is switched on; 4) your name and an email address? Please do not message us your passcode; we will ask at the counter if the repair needs it. If you can bring it in by 2 pm, same-day is possible with the aftermarket screen.

Before it goes out, a person checks two things: the prices against the price list (the assistant read them from the file, so what you are really checking is that the file is current), and the promise. "Same-day is possible" depends on stock, bench time and the 2 pm cut-off, none of which the assistant can see. If your rule is "no promises in drafts", strip that line. For a related capture problem in another trade, capturing the complaint on an auto repair intake form works through the same message-to-fields step.

The 26 ticket fields, and which stage can fill each one

An intake form is a list of fields that the shop needs before it can repair and bill. A message can fill some of them, the customer's reply to your questions fills a few more, and the rest are only ever true at the counter. Sorting them into those three stages is the design decision behind the whole system, and it works with any ticket system that lets you add or import fields. The table uses the cracked iPhone 13 to show which stage fills what.

Count the rows against the 26 individual fields and the pattern is clear. In this example the message fills nine (phone number, contact method, brand, model, fault category, the customer's words, how it started, other working functions and the provisional quote), the customer's reply fills five more (name, email, liquid contact, backup status and Find My status), and 12 can only be completed at the counter or by staff. So the assistant does not remove the counter step. It shortens it from 26 questions to 12 checks, and the customer arrives with the awkward questions already answered.

The prompt, the field list and the price list it reads

Set the assistant up once in a ChatGPT or Claude project (or a Gemini Gem, becoming a skill from November 2026) so that three things sit together: the instructions, the field list and the price list. The price list does the heavy lifting, because it stops the assistant quoting from memory.

You turn a customer's message to a phone repair shop into a draft repair
ticket. Staff check every draft before it is used.

Use FIELD LIST for the output keys and PRICE LIST for every price.
Rules:
1. Fill only what the message says or clearly implies. Everything else goes
   in "unknown_fields". Never guess a model variant, a cause or a price.
2. Never write a price that is not in PRICE LIST. If the device or repair
   is not listed, set the quote to "NOT IN LIST".
3. Do not diagnose. Sort the fault into a category and say what would
   need checking at the bench.
4. Never record a passcode, password or Apple Account detail. If the
   message contains one, write "passcode in message: staff to delete"
   and leave it out of every field.
5. Liquid contact, will-not-charge and random-shutdown faults are
   "diagnostic first": no firm quote.
6. Return the JSON, then a reply to the customer under 120 words that
   asks for the unknown fields, gives the provisional price and says it
   is provisional. Make no promise about timing.

FIELD LIST: [paste the 26 fields]
PRICE LIST: [paste the table]
MESSAGE: [paste the customer's message]

Rule 4 matters more than it looks. Customers sometimes volunteer their passcode in the first message, in the best of faith. The assistant's job is to flag it so a person deletes it, rather than copying it into a ticket that the whole team and every connected tool can read. The price list can be as plain as this (illustrative prices; yours come from your supplier costs and your margin).

Keep the arithmetic in the spreadsheet, as a formula for part plus labour, and let the assistant read the finished price. Language models make small slips with sums, which is the subject of why AI is bad at maths and what to check in quotes, and a customer will remember a quote that was $10 wrong in their favour or against them. If you also build the price list from supplier files, turning supplier price lists into a parts markup sheet shows the method in another trade.

The parts check: match a message to a part, a price and a stock count

The assistant reads a stock figure from a file, and that file is only as fresh as its last update. So the parts check has two layers. The assistant matches the device and repair to a line in the price list, and a member of staff confirms the part is on the shelf before anything is promised. Four messages show what comes back (illustrative, using the price list above).

The fourth row is the one that protects the shop. A model left to its own devices will happily quote the nearest line, in this case the standard iPhone 13 battery, which is a different part and may carry a different price. "NOT IN LIST" is a deliberate instruction in rule 2, and it is the most valuable thing the prompt does. On the third row, the diagnostic-first rule keeps the assistant from sounding like a technician: a phone that will not charge may have a worn port, a faulty cable, a battery problem or a board fault, and only the bench shows which.

Part grades deserve careful wording. If the price list says "aftermarket" and "refurbished original", the quote must say the same, and the assistant must never upgrade the wording to "genuine" or "original" to sound reassuring. A customer who believes they bought an original screen and later learns otherwise has a complaint that no template will fix. Write the grade names once in the price list and make the assistant copy them exactly.

When a customer is quoted and goes quiet, the follow-up is a separate job, and following up unapproved repair estimates with AI covers it. Once the repair is under way, repair status updates for phone repair shops picks up where the ticket leaves off.

Security fields a message must never fill

Four fields carry the real risk in a phone repair, and none of them should be completed from a message alone: passcode status, Find My status, backup status and the data-risk acknowledgement. The customer's answers in a reply are a heads-up for the counter, but the counter checks each one against the device in front of you.

• Passcode. Record whether one was given, never what it was. Apple's own service page tells customers never to give their device passcode or account details to anyone else and to stay present while a technician has access to the device. An independent shop can borrow both habits: take a passcode in person only when the repair needs it, and let the customer watch it being used.
• Find My. Apple's page says that, on iOS 26 and earlier, it might not be able to service a device with Find My on, and that from iOS 27 customers turn on "Ready for Repair or Trade-In" in the Find My app instead. Ask the customer which applies, record the status at the counter, and write down what you need it to be before work starts and who switches it back on afterwards.
• Backup. Ask, record the answer and do not offer to do it unless that is a service you sell.
• Data-risk acknowledgement. A line on the ticket that the repair may involve data loss and that the customer has been told to back up. Have a solicitor approve the wording, and keep it in your terms, not in an AI-written paragraph.

Photos need a privacy rule too. Customers often photograph the broken phone with the screen lit, which can expose notifications, messages or a lock-screen name. Ask for photos of the back and sides, or of the screen switched off, and delete any photo that shows private content once you have what you need. The same applies to screenshots of the About screen: ask for the model number, not the whole conversation.

For the model itself, ask for a screenshot of the About screen. On an iPhone, Apple's page says to open Settings, tap General, tap About, and look to the right of the Model Number entry, where a part number is shown that you tap to reveal the model number. On Android the path is usually Settings then About phone, but the wording varies by maker, so give both when you ask.

Three ways to run it, and what each costs

You do not need an integration on day one. The same instructions work three ways, and the shop can move from one to the next as volume grows.

Two quick sums for the automated route. Zapier's pricing page, read on 28 October 2026, lists the Free plan at 100 tasks a month with two-step Zaps only, and Professional's lowest tier at 750 tasks. An AI step counts as one or more tasks depending on the model tier you pick (Zapier's help pages have shown one, three or five tasks per run, so check its current rates), so assume three. Add one task to write the sheet row and one to send the staff alert and each message uses five. At 120 messages a month that is 600 tasks, inside the 750-task plan, with a little headroom. At 200 messages it is 1,000 tasks, so you would move up or use your own API key, which reduces the AI step's cost.

If you call an AI model through its API instead, the per-message cost is negligible. Anthropic's list price for Claude Haiku 4.5 is $1 per million input tokens and $5 per million output tokens. A message with the field list, price list and instructions might run to about 2,000 input tokens and 500 output tokens: $0.002 plus $0.0025, about half a cent. At 120 messages a month that is well under a dollar. The cost of the system is the human who checks its drafts, not the model.

Six messages that break naive capture, and how the prompt handles them

• Two devices in one message. "My phone and my daughter's tablet both need screens." The assistant should return two tickets, not one merged record. Add a rule: one device per ticket, and a "linked tickets" note.
• "iPhone 13" that is really a mini. This is why the output carries "variant_confirmed". The question to ask is the model number from About, not "which iPhone 13".
• A fault described as a cause. "The battery is dead" may be a battery, a charging port or software. The prompt files it under "charging or power" and flags diagnostic first, instead of treating the customer's diagnosis as fact.
• A passing mention of water. "It got a bit wet last week but it's fine now." Treat any liquid contact as diagnostic first, tell the customer plainly that liquid damage can show up later, and record it in the ticket whether or not the customer thinks it matters.
• A voice note or a message in another language. Transcribe or translate first, then run the prompt. Keep the original text on the ticket as well, so the customer's own words are not lost in translation.
• A screenshot with private content. Ask the customer to resend a photo without it, and delete the first. The assistant never needs the content of someone's messages to do its job.

An illustrative mistake shows how these fail in practice. Suppose a shop starts with a prompt that lacks rule 2. A customer asks about an iPhone 13 mini battery, the price list holds only the standard iPhone 13 battery, and the assistant quotes $54 without a murmur. The staff member glances at the price, which looks right for a battery, and sends it. The mini takes a different battery with its own supplier cost, so if that cost is higher the shop either absorbs the difference or has an awkward conversation. The fix is the "NOT IN LIST" rule plus a habit: any price sent to a customer is checked against the price list row, not against a feeling that it looks about right.

Testing the first ten tickets, then keeping a sample going

Before the assistant sees a live customer, run 10 to 20 real past messages through it with names and numbers removed, and compare each draft with the ticket staff actually created. Score four things separately: the device and variant, the fault category, the quote (right row, right grade, right arithmetic) and the questions it asked. A single overall impression hides the pattern: a system can be excellent at devices and weak at liquid damage, and the fix is different for each.

Then keep a draft-only rule: a human reads every output for the first month. After that, keep sampling. Every Friday, pull five tickets at random and check them against the message and the price list. Track two numbers: how often staff changed the device or quote field (the target is "rarely", and anything above one in ten needs the prompt or price list looked at), and how many tickets still arrive with an unknown liquid status. If you route messages from WhatsApp, the WhatsApp Business app versus the API explains why copying messages by hand is the safe starting point. The Business Platform's service-reply charges changed on 1 October 2026, and Meta's terms bar general-purpose AI assistants there. A bot tied to one business task such as intake should fall outside that rule, but confirm it with your WhatsApp provider and read Meta's current pricing and policy pages before you build one.

One last habit pays back quickly. When staff correct a draft, write the correction down against the message, then add it to the prompt or the price list the same day. Over a few weeks the assistant makes fewer of the mistakes your team notices, and the intake form becomes something the customer finishes before they walk in.

Phone repair intake questions shops ask next

Should the AI ever ask for the customer's passcode?

No. Ask only whether a passcode will be provided, and take it in person at drop-off if the repair needs it. Never type it into a message, a prompt or a ticket note that other staff or tools can see. Apple tells its own customers never to share a device passcode with anyone else.

Can the assistant diagnose the fault from a message?

It can sort the description into a fault category and list the checks to run, but only the bench test confirms the cause. Treat any quote built from a message as provisional and say so in the reply, especially for faults such as will not charge, random shutdowns or any liquid contact.

What if my customer messages arrive on WhatsApp?

Copy messages across by hand from the free WhatsApp Business app at first. The Business Platform route, where software replies for you, brought per-message charges for some replies from 1 October 2026 and carries Meta's terms on AI use, so read Meta's current pricing and policy pages before you automate.

How many test messages should I run before trusting it?

Run 10 to 20 real past messages with names and numbers removed, and compare each draft ticket with what staff recorded. Score device, fault category, quote and missing-information questions separately, and keep a draft-only rule until the device and quote fields are right almost every time.

Further reads

• Turning On-Site Voice Notes Into Job Sheets and Quotes With AI — Turning spoken notes into job sheets and quotes, a similar capture step.
• AI Ticket Triage: Tag, Route, and Prioritise Support Requests — Tagging and prioritising incoming requests once tickets are flowing.
• Shoe Repair Software: Job Tickets, Pick-Up Texts and AI Replies — Job tickets and pick-up texts for another small repair trade.
• The Intake Questions That Make AI Cleaning Quotes Accurate — How the right intake questions make an AI quote accurate.
• Phone Repair Shop Marketing: Local Search and Trade-In Offers With AI — Getting more enquiries to your shop once capture works.
• Is It Safe to Let AI Reply to Customers on WhatsApp? — Whether letting AI reply to customers on WhatsApp is safe.
• AI for a Shoe Repair Shop: Quotes and Ready-for-Collection Texts — Draft provisional quotes from customer photos and your own price list, then send ticket-numbered ready and reminder texts, with prompts and timings.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Apple Support pages on preparing an iPhone for a service appointment and finding an iPhone model number (read 28 October 2026); Zapier's pricing page (read 28 October 2026); Anthropic's published API prices for Claude Haiku 4.5.