Multi store luxury watch retailers safeguard repair agreements and customer trust through integrated LINE chat

PROJECT OVERVIEW

ABOUT THE CLIENT

This case study is based on a real VNEXT project. The client's identity and certain project details have been anonymized or generalized for confidentiality purposes.

The customer sells well known luxury watch brands, from everyday classics to rare and limited editions, through several stores around the country. Alongside selling, it repairs, services, and refurbishes watches, which is where much of its relationship with customers is built. A watch is often a treasured and expensive object, so a repair is a promise as much as a transaction. This is a retail business in which trust is earned one handover at a time.

THE CHALLENGE

Repairs and warranty work were being managed on paper, with spreadsheets and documents to support it, and conversations with customers took place over LINE. Each tool did its job, but none of them knew about the others. Information lived in several places, was hard to keep consistent from store to store, and took a lot of staff time to chase.

The conversations mattered for more than convenience. When a customer agrees to a repair, a price, or a condition report, the message that records it becomes evidence, and the retailer needed that evidence kept safely and linked to the right order.

The project itself had a shape worth noting. The customer knew its business thoroughly and described the situation and the outcome it wanted, but had not written a detailed specification. Its team had little time to spare, with a single weekly report meeting as the main channel for questions, and the technical side of devices and settings was not its field. Our team had to supply the structure that was missing, and to do it in a way that fit those constraints.

PROJECT OBJECTIVE

The customer wanted a single system in which every repair and warranty order is recorded, each order is connected to its customer and the conversation about it, and staff at each store can work with the right level of access, with the chat doubling as a dependable record.

APPROACH AND METHODOLOGY

Starting from the goal and building the specification with the customer

Because the customer described context and intent rather than detailed requirements, our team studied every document it sent, thought through what could go wrong in each situation, and came to meetings with suggestions as well as questions. The customer then had something concrete to react to, which is easier than writing a specification from nothing.

Making the one weekly meeting count

With only one weekly report meeting available, our team prepared all of its questions in advance and brought them together on that day. It kept the customer's time to a minimum, and made sure nothing waited a week for want of an answer.

Writing documents that serve twice

Since there were fewer conversations, we invested more in documentation, and made it detailed and clear. The documents act as a record of what was agreed, and they also work as reports that let both sides see problems early instead of late.

Explaining each step in plain terms

The customer's expertise is in watches, not in servers or settings, so our team gave detailed, step by step guidance whenever a task touched devices or configuration. It kept the project moving without asking the customer to become a technologist.

Following the team's progress each day

A short daily meeting was used to see how work was going and where someone might need a hand, so help could arrive while it was still useful.

Keeping project information tidy and protected

Project documents were shared through a cloud drive with edit, view, or comment rights granted only to people with a role in the project, detailed design discussions with the customer ran through a version control system with the same limits, and the source code sat in VNEXT's own repository with roles controlling who can read or change it. Details of the cloud environment were visible only to the project manager and technical leader, within what the customer allowed.

TEAM SCALE

Eight people worked on the project, covering the full path from design to delivery.

• Project manager and technical leader: ran the delivery and held the technical direction
• Backend and frontend engineers: built the system in Java, Spring Boot, and Thymeleaf, including the LINE integration
• Testers: verified the order, customer, staff, and chat flows, supported by our software testing practice
• Bridge communicator: kept questions and answers moving between the customer and the team

THE SOLUTION AND TECHNOLOGY STACK

Our team built a web application that gives every store the same view of every repair, along with the conversation behind it.

What was built

• Order list: lets staff add, edit, delete, and search repair and warranty orders, see each order's status at a glance, and jump from an order straight to the conversation with that customer
• Customer management: lists customers with their details and shows all the orders belonging to each one
• Staff management: lets administrators add, edit, delete, and search staff members across the stores, with permissions suited to each role
• Chat connected to LINE: lets staff talk with customers in real time through LINE, sending images and files, with messages saved as a record

Technology Stack

The AWS environment behind it is part of our wider cloud application development work, and a different retail ordering problem is described in our demand forecasting and order management case.

THE RESULTS

• One record instead of four tools: orders, customers, staff, and conversations are held together, so nothing depends on a spreadsheet or a paper file.
• Conversations that become evidence: LINE messages are saved and tied to the order they concern, so agreements and conditions can be confirmed later.
• The same picture at every store: the status of a repair is visible to staff wherever they work, within the permissions of their role.
• Delivered on the promised date: the system was completed within the timeline agreed with the customer at the start.
• Accepted, and handed over in full: the customer was pleased with the system, and all documents and project information were passed to it for the next stage.

The customer now manages repairs the way it handles its customers, with attention to every detail, and with a record to match.