Note
Closing the Dispatch Group Chat Without Losing the Crew
The LINE group chat is how most Thai electrical contractors dispatch daily field work. Someone posts assignments in the morning. Technicians send status updates during the day. The foreman sees everything in one feed and handles exceptions as they come in. Nobody had to install anything special because everyone already had LINE.
There is a reason this works: it solves the coordination problem with tools the crew already knows. When the operation is four to six people on two or three concurrent sites, the group chat can hold the whole thing.
The problem shows up once the crew gets larger or the project count starts climbing. The group that once felt like coordination starts feeling like noise. Critical assignments disappear into the scroll. Work gets missed. The foreman ends up on the phone asking questions the chat should have answered.
What is the group chat actually doing?
Before thinking about what to replace the group chat with, it helps to list what it is currently handling:
- Job assignment: which technician goes to which site today
- Acknowledgment: the tech confirming they saw the assignment (“อ่ะ วันนี้ไปได้เลย”)
- Status updates: a message when the tech arrives, when they need something, when they finish
- Exceptions: the late arrival, the material shortage, the customer who is not on site
- Evidence: photos sent into the chat as proof of progress or completion
Every one of those functions is real. Closing the group without replacing each one is how you lose coordination rather than improve it.
What actually disappears when the group goes quiet?
The passive audience. In the chat, everyone can see what everyone else is doing. The foreman does not need to ask for status because it is already in the feed. In a system, if nobody logs anything, the screen shows nothing. That visibility has to be rebuilt deliberately.
The informal acknowledgment. The two-character reply that says “I saw this and I will handle it” has no standard equivalent in most scheduling tools. A job that shows as “assigned” in a system still leaves open the question of whether the technician noticed it. The acknowledgment step needs to exist somewhere.
The running thread. When a customer changes an instruction mid-day, the foreman posts once and the relevant technicians see it in context. In a system, that context has to be attached to the correct job record rather than floating in a chat feed.
What has to be in place before you can safely close the group?
This is the question most contractors skip. They either stay on LINE because they cannot picture what replaces it, or they close the group prematurely and rebuild it informally within two weeks.
Three things need to work before the group becomes redundant:
Job orders on each technician’s phone. The tech must be able to see today’s assignment, confirm it, attach photos, and mark it done, all from their phone without sending a message anywhere. If any of those steps still requires a chat, the group chat is still load-bearing.
A status screen the owner or foreman can read without asking. If the only way to know where the crew is means calling people or checking the chat, the group is still carrying the operation. The screen needs to show open jobs, assigned technicians, and whether confirmation has come back, without any messages being sent.
A record that travels with the job, not the person. When a foreman posts an exception into the LINE group, that information lives in the chat scroll. When the billing coordinator needs it at month end, they have to dig for it. Exceptions, photos, and updates need to attach to the job they belong to so the record survives the job completion.
Why running both in parallel tends to fail
Some contractors try to keep the LINE group running while onboarding a system alongside it, hoping the migration can happen gradually. In practice, the group chat wins.
Technicians default to the fastest tool. If posting “เสร็จแล้ว” in LINE takes three seconds and gets acknowledged, the motivation to open an unfamiliar app and navigate several screens is not high enough to compete. The formal system ends up empty and the foreman goes back to reading the chat. That is the short version of how a system ends up unused within two months.
The only way past this is to make the system the path of least resistance, not just an option alongside the path everyone already knows.
How does the transition actually happen?
The group chat does not need to close on day one. Announcing a switch and closing the group on Monday is the most common way this goes wrong.
A sequence that tends to work:
- Start with job orders on phones. Let technicians get used to seeing and confirming assignments from one place.
- Move photos into the job record. Once technicians are attaching photos to jobs in the system, the chat photos become redundant.
- Let the group go quiet. Once assignment, confirmation, and photos are in the system, chat volume drops on its own.
- At that point, closing the group is safe because it is already not doing anything critical.
The wrong sequence is to declare the switch, close the group, and hope the system catches up.
FAQ
How long does the transition realistically take?
It depends on how well job orders on phones are working. If technicians are confirming assignments and attaching photos without being chased, the shift can happen inside one month. If they are still asking for assignments by message, the system is not ready and closing the group would be premature.
What if some technicians refuse to use anything except LINE?
This is almost never stubbornness. It is usually a sign that the system is not easy enough yet. If confirming a job takes longer in the app than sending a LINE message, technicians will use LINE every time. Five taps to confirm a job is achievable. Requiring a login, a form, and four screens is not.
Does the foreman lose something by moving off the group chat?
The foreman needs a screen that shows the crew’s status without asking for it. That is a different job from managing a group chat, and a less exhausting one. When the screen is reliable, exceptions surface in one place rather than buried in a feed.
What this comes back to
Closing the dispatch group chat is not a technology decision. It is a decision about what your operation needs to be able to do without a running thread of messages holding it together.
The group chat works right up until it stops working, and that moment is usually when adding a new system is most disruptive. Getting job orders onto phones before you need to, and letting the group quiet down naturally, is a less dramatic path and a more reliable one.
If you want to see how the transition from chat to structured job orders is handled in practice, the details are at /program/.