Killing the Revision Form: How Live Chat Between Tuner and Customer Changes File Delivery

Every chiptuning workshop has seen this exchange. A customer submits a file, you tune it, deliver. Twenty minutes later they email: “Car drives fine but I get a knock between 2000-2500 RPM, can you check?” You reply asking for the OBD log. They reply asking what an OBD log is. You reply with a screenshot of how to record one. They reply two days later. You reply at midnight. Three weeks pass and the request is technically still open in your dashboard.

This is the revision conversation, and the way most portals handle it — through a “Submit Revision” form with a textarea and a file upload — is the wrong shape for the workflow. Workshops live in WhatsApp and Telegram for a reason: tuning is a back-and-forth diagnostic process, not a one-shot transaction.

This post explains why the form is wrong, what a live chat thread on every file request actually changes, and how to wire it without losing the audit trail your accountant cares about.

The “Submit Revision” form is the wrong primitive

A standard file-request portal has three states: submitted, in progress, completed. The “Submit Revision” form is a band-aid for the case when the customer isn’t happy with the delivered file. It typically looks like this:

• Free-text reason (“describe the problem”)
• Optional file upload (an OBD log, a video, a dyno PDF)
• A submit button that re-opens the request

Three problems with this design:

Problem 1 — Forms favour the most articulate customer. A workshop’s average customer is a vehicle owner, not a tuner. They struggle to write “knock between 2000-2500 RPM on light throttle in 3rd gear”. They write “car feels weird”. The engineer has to follow up, the form provides no follow-up affordance, and the conversation collapses into email.

Problem 2 — The engineer’s reply isn’t part of the workflow. When you reply to the customer’s revision request, your reply lives in your email outbox, not in the request. The next engineer who picks up the request sees the original revision text and no context. Three days later the customer says “but you told me to ignore that knock” and you can’t find the email.

Problem 3 — Files lose their conversation context. The customer uploads an OBD log via the revision form. The engineer uploads a tuned file as a revision. Both attachments live in the request. Neither has a discussion thread attached. Six months later, looking at the file request in your archive, you cannot tell why version 3 of the file was delivered. The work is invisible.

What a live chat thread on a file request changes

Replace the form with a chat thread — message-by-message, customer on one side, assigned engineer on the other, files attachable to any message — and the workflow changes in three specific ways.

1. The conversation is the request

Every message, every file, every status change appears in the same scrollable thread. New engineer assigned mid-job? They scroll up, read 6 messages, and they have the full context. No handover email, no “what’s the status on this one” pulled from memory.

2. Async by default, real-time when it matters

A chat thread is not a phone call. The customer can ask a question at 11pm; the engineer replies at 8am. Both messages live in the thread; both notifications fired on whichever channels are configured (in-app, email, Telegram, WhatsApp). No one has to be online at the same time.

When both parties are online — engineer at their desk, customer waiting for the file in the workshop bay — the thread becomes near-real-time. Five-second turnarounds. No keystroke delay because both are looking at the same page.

3. The status of the request follows the conversation

If the customer’s last message is “I need to send you an OBD log first, give me 30 mins”, the request automatically moves to On Hold with the reason “Waiting on customer (OBD log)”. When the customer uploads, the request resumes. No engineer needs to remember to flip a status flag.

This is the difference between a workflow that describes state and a workflow that derives state. The conversation IS the state.

Wiring it without losing the audit trail

A live chat thread is a customer experience win, but if it loses the audit properties of a structured form, your accountant and your dispute-resolution process will both suffer. Three guardrails preserve auditability.

Guardrail 1 — Every message is immutable

Once sent, neither party can edit or delete a message. If a customer later claims “I never asked for a DPF delete”, their original message asking for it is still there with the timestamp. This is the same model Slack uses for compliance (and same reason Slack offers “edit history” rather than silent edits).

If your jurisdiction requires deletion on customer request (GDPR Article 17), the message body can be replaced with [Message redacted at customer request — 2026-05-21] rather than removed entirely. The conversation flow is preserved; the personal data is gone.

Guardrail 2 — Status changes are part of the thread

When the engineer holds the request, when the customer submits a revision, when the file is delivered — these events appear inline in the chat as system messages:

🔵 ENGINEER assigned to request — Mark Robinson · 14:32
💬 Customer: "Hi, when can you start on my Audi?"
💬 Mark Robinson: "Looking at it now. Need the SW number from your KESS scan."
📎 Customer: kess_dump.bin (2.4 MB)
🟡 ON HOLD — Waiting on customer (clarify reading method) · 14:51
💬 Customer: "Sorry, that was the OBD read. Bench is below."
📎 Customer: bench_full.bin (4.0 MB)
🟢 RESUMED · 15:18
💬 Mark Robinson: "Bench file is clean. Starting Stage 1 + DPF. ETA 45 min."
📎 Mark Robinson: tuned_v1.bin (4.0 MB)
✅ COMPLETED — Stage 1 + DPF Off · 16:03
📜 Certificate attached

A new engineer reading this thread tomorrow knows exactly what happened. So does a dispute reviewer six months later.

Guardrail 3 — Notifications hit the customer’s preferred channel, not just email

Email is the worst real-time channel. A revision thread that lives only in email gets buried. Real chat threads on file requests need to fire notifications on the channel the customer actually checks:

• In-app badge (when they have the portal open)
• Email (always — as fallback)
• Telegram (if linked — the chat message arrives as a Telegram DM with a “View in portal” button)
• WhatsApp (if linked — same)
• Browser push via OneSignal (for customers who don’t want to install Telegram)

The customer’s notification preferences belong in their profile, not in your assumption that email is enough.

What about when no engineer is assigned?

A common bug in workflow systems: customer messages a request that has no engineer assigned yet. Where does the notification go? In a badly-built system, it goes nowhere and sits in the queue.

The correct behaviour: if the request has no assigned_to, the customer message notifies every admin / lead engineer on the workshop. One of them picks it up, the assignment happens, and from that point the conversation is private to the customer-engineer pair. Until then, it’s a workshop-wide ping.

This is the same model a hospital triage desk uses. No assignment = everyone hears it. Assignment = handover.

When to use chat, when to use the form

Even with chat available, some interactions are still better as structured form fields. Use this split:

The form captures structured data the workflow needs. The chat captures everything else humans need to talk about. Don’t try to make one do both.

The metric that proves the chat works

Tracking the right metric tells you whether the chat actually changed your workflow. The single most useful one is time-from-customer-question to engineer-reply, measured at the median (not the average — averages are skewed by 4am edge cases).

A workshop using only email typically has a median reply time of 6-14 hours. The same workshop with a live chat thread, browser push notifications, and a Telegram link typically drops to 18-45 minutes within four weeks. That difference compounds: faster replies mean fewer abandoned customers, more files completed per engineer per day, fewer “where’s my file?” support tickets.

Track it. Show it to your engineers. Reward the median, not the maximum.

What this looks like in TunerSuite

TunerSuite v2.8.168 onwards replaces the “Submit Revision” textarea with a live conversation thread on every file request. Customer message ↔ engineer message ↔ inline file attachments ↔ system status events, all in one scrollable view. Notifications fire to in-app, email, Telegram (if linked), and OneSignal browser push — the customer chooses which.

The hold/resume actions integrate with the chat: an engineer who needs more info from the customer clicks “Hold + Ask” once, types the question, and the request flips to On Hold automatically. When the customer replies with the missing info, the engineer clicks “Resume” and continues.

This isn’t a feature you buy separately — it’s part of the standard TunerSuite licence — £699 setup + £49.99/month, the same one that covers white-labelling, multi-technician routing, and the branded tuning certificate.

Update: one inbox, and conversations that follow you

Everything above is still true — the conversation belongs on the job, and a file handed over in chat becomes a proper versioned revision. But running it for a while exposed a second problem that a per-job thread does not solve on its own: a shop does not have one conversation, it has forty, and they are scattered across forty job pages.

You end up with a member of staff opening requests one at a time to find out which ones are waiting on a reply. That is not a chat problem. That is an inbox problem.

Every conversation in one list

Job chats, support tickets, sales enquiries and conversations coming in from sub-dealers now arrive in one place. You answer from the row you are looking at: the conversation opens where you clicked, with the message you are replying to still visible above the box. It sounds small. It is the difference between answering a customer and guessing what they asked.

The list is plainly newest first. Anything that needs a person still says so on its row and still has its own filter — but a week-old chat no longer sits above this morning’s message just because it is unresolved.

Unread has to mean unread by you

This is the one that surprises people. In most systems a conversation is read or it is not, for the whole company. In a shop with three people on the desk that is actively harmful: whoever glances at the list first quietly clears everyone else’s signal.

Read is now recorded per person. What you have read is read for you. Your colleague still sees it waiting, because for them it is.

You can see what happened to what you sent

One tick when the message leaves, two when it reaches the other side, two in blue when it has been read, with the exact times when you hover. The important part is what it refuses to do: a message with no delivery recorded shows one tick and never two. A delivery indicator that guesses is worse than none, because you stop trusting the one time it matters — the customer who says they never got it.

Conversations that follow you around the portal

A floating panel sits beside every page with the conversations that need a person. Two details in it were worth more than the feature itself:

• It holds still while your pointer is over it. It is sorted newest first and redraws whenever a message arrives, so on a busy day rows slid out from under the pointer and clicks landed on the wrong customer. Now the order freezes while you are pointing at it.
• It is switched on per person. A tuner who wants a quiet screen turns it off without affecting the person on the desk who needs it.

A number that agrees with the list underneath it

The chat button in the top bar carries a count of conversations waiting for a reply. It used to ask a different question from the list below it — it treated a file attached to a job as if the customer had asked something, and it ignored conversations the team had already ticked off. On a busy portal it read one hundred and six above a list built from the real question.

Header, badge, floating panel and reminders now answer one question, defined once. A row where a customer is genuinely waiting carries an amber ring, with the car, the job reference and the last thing said already on it — enough to decide whether to answer now without opening anything.

Finishing a conversation actually finishes it

Ticking one off used to leave the row exactly where it was, so the list only ever grew. What you finish now moves to an archive, and anything the customer says afterwards brings it straight back into the working list. The archive behaves like every other lane — you can reply in it, see the car, and open the job — because a lane that behaves differently from its neighbours is a trap, not a feature.

And when nobody is at the desk

The support assistant answers from the knowledge you curate, and your team can take a conversation over mid-sentence. The rule that matters is the failure case: if anything goes wrong while the assistant is working out a reply, the conversation is handed to a person and flagged. A customer’s question is never met with silence, which is what used to happen when the reply could not be produced.

Photos from a phone are resized and read rather than refused — most photos a phone takes were too large before, which was about one in four of the ones customers actually sent. And a library of more than twelve thousand fault codes sits behind it, so a customer who types a code gets an answer about that code.

The honest summary

The per-job conversation was the right primitive. It was not, on its own, a way to run a day. What turns it into one is a single list, an unread count that belongs to a person, a delivery state that only claims what it knows, and one definition of “waiting on us” used everywhere in the product.

FAQ

Does the customer need a separate login to use the chat?
No. The chat lives on the file request detail page they already have access to. Their existing account credentials work; no second sign-up.

Can I have multiple engineers on the same chat?
Yes. The multi-technician workflow supports re-assigning a request mid-conversation. The new engineer sees the full thread, can post, and the original engineer either stays in the loop or gets unassigned cleanly.

What happens if the customer sends a message at 3am?
The notification fires immediately on whichever channels the customer has configured. The engineer sees it when they next open the portal, check email, or open Telegram. There’s no expectation of a 3am reply unless your premium 24/7 SLA requires one.

Do attachments in the chat respect file-type whitelist?
Yes. The same allow-list that governs the file-request form (bin, ori, zip, rar, 7z, dat, pak, sg, org, mod, dim, plus images and PDFs for OBD reports) applies to chat attachments. Executable types are rejected before they reach disk.

How is the chat different from a third-party tool like Crisp or Intercom?
Third-party chat widgets live on top of your portal and don’t know what a file request is. The conversation is structured around the request — every message is scoped to that job, status changes appear inline, file attachments inherit the request’s permissions, and the audit trail belongs to your portal, not to a vendor whose pricing might change next year.

Next step

If you’re on TunerSuite v2.8.168 or later, the chat is live on every file request — no setup. If you’re on an older release, the Update Center handles the upgrade in one click.

If you’re shopping for a chiptuning portal and the one you’re testing still uses a textarea “Submit Revision” form, that’s a workflow built for one-shot files, not for the back-and-forth that actual customers need. TunerSuite is built for the second case.

For more on how the engineer-customer split works behind the scenes, read about the multi-technician workflow.