Giới thiệu dự án

Bối cảnh ngành và thực trạng thị trường

Thị trường cơ điện lạnh (HVAC) và thiết bị gia dụng tại Việt Nam ghi nhận tốc độ tăng trưởng quy mô tiêu thụ từ 7,3% lên 11,9% mỗi năm, với tổng mức chi tiêu toàn ngành vượt 157.000 tỷ đồng, trong đó thiết bị làm lạnh gia dụng chiếm hơn 97% thị phần. Trước sức ép cạnh tranh gay gắt từ các thương hiệu FDI (Panasonic, Daikin) và nhóm thương hiệu giá rẻ (Funiki, Casper), Công ty Cổ phần Nagakawa Việt Nam (Mã chứng khoán: NAG, thành lập từ năm 2002) đối mặt với bài toán chuyển dịch chiến lược: từ cạnh tranh đơn thuần về giá và thông số kỹ thuật sang cạnh tranh bằng chất lượng dịch vụ chăm sóc khách hàng (Customer Service Quality - CSQ) để gia tăng giá trị tài sản thương hiệu (Brand Equity).

Vấn đề cốt lõi (Problem Statement)

Mặc dù sở hữu mạng lưới phân phối hơn 500 đại lý và 60 trạm bảo hành ủy quyền trên toàn quốc, hệ thống quản trị dịch vụ khách hàng tại Nagakawa bộc lộ các điểm nghẽn nghiêm trọng:

  1. Dữ liệu phân mảnh: 100% hồ sơ đại lý B2B và khách hàng cuối B2C được quản lý thủ công qua sổ sách và file Excel rời rạc, gây mất mát lịch sử tương tác.
  2. Độ trễ xử lý dịch vụ bảo hành: Thời gian tiếp nhận, điều phối kỹ thuật viên tại các trạm tỉnh chưa được số hóa, dẫn đến vi phạm thỏa thuận mức dịch vụ (SLA) cam kết.
  3. Kênh tương tác đơn lẻ: Hotline 1900 545489 và Fanpage Facebook thiếu cơ chế đồng bộ tự động, tỷ lệ phản hồi trễ mạng xã hội chiếm đến 23% tổng phản ánh tiêu cực.
  4. Sai lệch năng lực nhân sự vùng miền: Đánh giá không đồng đều về kỹ năng kỹ thuật viên giữa các trạm bảo dưỡng (10% đại lý không hài lòng về thái độ và chuyên môn).

Mục tiêu nghiên cứu và phát triển

  1. Hệ thống hóa lý luận: Xác lập mô hình quan hệ giữa chất lượng dịch vụ (SERVQUAL), quản trị quan hệ khách hàng (CRM) và giá trị thương hiệu trong ngành điện lạnh B2B2C.
  2. Khảo sát thực nghiệm đa chiều: Đo lường trải nghiệm thực tế trên mẫu đại lý ($N_1 = 100$) và người tiêu dùng ($N_2 = 1000$).
  3. Thiết kế kiến trúc hệ thống số hóa CSKH: Xây dựng mô hình Omnichannel CRM tích hợp tổng đài VoIP, tự động hóa điều phối bảo hành và phân tích phân khúc khách hàng.
  4. Chuẩn hóa quy trình vận hành: Ban hành khung chính sách đổi trả, SLA trạm bảo hành và liên kết quy trình kiểm soát chất lượng sản xuất 3 cấp (IQC - LQC - OQC).
graph TD
    A[Khách hàng B2B/B2C] -->|Hotline 1900 / Web / Social| B[Omnichannel Contact Center]
    B --> C{Smart Dispatching Engine}
    C -->|Bảo hành / Sửa chữa| D[60 Trạm bảo hành ủy quyền]
    C -->|Chính sách / Chiết khấu| E[Phòng Kinh doanh & Trade Marketing]
    D --> F[Field Service Mobile App]
    F --> G[(PostgreSQL Central CRM)]
    G --> H[Bi-directional QA Feedback Loop: IQC - LQC - OQC]

Phạm vi và giới hạn dự án

  • Không gian: Trụ sở Nagakawa (96 Định Công, Hà Nội), 3 chi nhánh lớn (Hà Nội, Đà Nẵng, TP.HCM) và 60 trạm bảo hành ủy quyền.
  • Thời gian: Khảo sát thực địa và phân tích số liệu tài chính - vận hành giai đoạn 2014 – 2016, kiểm chứng dữ liệu 2017.
  • Giới hạn: Dự án tập trung vào dòng sản phẩm điều hòa dân dụng, điều hòa thương mại và tủ đông công nghiệp.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

So sánh các mô hình quản trị dịch vụ khách hàng

Tiêu chí Mô hình thủ công (Hiện trạng) Hệ thống CRM đóng gói (Salesforce/SAP) Hệ thống Smart-CRM tùy biến (Đề xuất)
Chi phí triển khai (TCO) Thấp (chỉ tốn nhân sự ghi chép) Rất cao (> 50.000 USD/năm) Trung bình (Tối ưu theo mã nguồn mở)
Tích hợp trạm bảo hành tỉnh Không có, liên lạc qua điện thoại Phức tạp, phụ thuộc nhà cung cấp Tối ưu hóa sâu theo luồng trạm ủy quyền
Khả năng đồng bộ Tổng đài Thủ công (nhân viên tự ghi lại) Tích hợp CTI đắt đỏ Tích hợp trực tiếp Asterisk PBX API
Bảo mật & Kiểm soát dữ liệu Nguy cơ thất thoát dữ liệu cao Lưu trữ Cloud quốc tế On-premise / Private Cloud nội địa

Phân tích cạnh tranh ngành điện lạnh

  • Panasonic & Daikin: Chiếm lĩnh phân khúc cao cấp, hệ thống ProShop/e-Service đồng bộ, thời gian phản hồi bảo hành $< 24\text{h}$.
  • Funiki & Casper: Đánh mạnh phân khúc giá rẻ, chính sách chiết khấu sâu nhưng mạng lưới bảo hành trạm ủy quyền mỏng hơn ở tuyến huyện.
  • Nagakawa: Lợi thế 15 năm uy tín, hệ thống 60 trạm phủ rộng nhưng thiếu công cụ số hóa để kiểm soát đồng bộ chất lượng.

Phân loại yêu cầu theo khung MoSCoW

  • Must have: Quản lý tập trung thông tin đại lý B2B; Module tiếp nhận và phân luồng ticket bảo hành; Tích hợp hotline 1900; Báo cáo doanh số và tỷ lệ hoàn tất sửa chữa.
  • Should have: Thuật toán tự động định tuyến kỹ thuật viên theo vị trí địa lý; Hệ thống chấm điểm CSAT/NPS tự động qua SMS/Zalo; Phân khúc đại lý theo mô hình RFM.
  • Could have: Ứng dụng di động (Field Service PWA) cho thợ bảo hành cập nhật trạng thái linh kiện thay thế.
  • Won't have (Giai đoạn này): Chẩn đoán lỗi từ xa thông qua cảm biến IoT gắn trực tiếp trên máy nén điều hòa.

Thiết kế hệ thống

Kiến trúc tổng thể và Công nghệ sử dụng

Hệ thống được thiết kế theo kiến trúc Microservices phân lớp, đảm bảo tính sẵn sàng cao và khả năng mở rộng:

  • Backend Core: Python 3.11, FastAPI v0.104.1 (Async I/O cho hiệu năng cao).
  • Database Engine: PostgreSQL 15.4 (Dữ liệu giao dịch quan hệ), Redis 7.2 (Caching và Message Queue).
  • Task Worker: Celery 5.3 kết hợp Redis Broker xử lý tác vụ nền và gửi thông báo.
  • Telephony Interface: Asterisk PBX 20 LTS kết hợp Asterisk Manager Interface (AMI).
  • Frontend / PWA: React 18.2, TypeScript 5.0, TailwindCSS.
classDiagram
    class Distributor {
        +UUID id
        +String dealer_code
        +String name
        +Point geo_location
        +Float discount_rate
        +get_tier()
    }
    class WarrantyTicket {
        +UUID ticket_id
        +String serial_number
        +String issue_description
        +Enum status
        +DateTime created_at
        +assign_technician()
        +close_ticket()
    }
    class StationTechnician {
        +UUID tech_id
        +String station_id
        +String full_name
        +Boolean is_active
        +Int active_jobs_count
    }
    class QualityAudit {
        +UUID audit_id
        +String defect_component
        +Enum stage
        +record_defect()
    }

    Distributor "1" --> "0..*" WarrantyTicket : creates
    StationTechnician "1" --> "0..*" WarrantyTicket : handles
    WarrantyTicket "1" --> "0..1" QualityAudit : triggers_qc

Thiết kế cơ sở dữ liệu (Database Schema DDL)

-- PostgreSQL 15.4: DDL Schema for Distributor and Warranty Ticket Management
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS "postgis";

CREATE TYPE ticket_status AS ENUM ('PENDING', 'ASSIGNED', 'IN_PROGRESS', 'RESOLVED', 'CLOSED', 'CANCELLED');
CREATE TYPE qc_stage AS ENUM ('IQC', 'LQC', 'OQC', 'FIELD_FAILURE');

CREATE TABLE distributors (
    dealer_id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    dealer_code VARCHAR(20) UNIQUE NOT NULL,
    dealer_name VARCHAR(255) NOT NULL,
    phone VARCHAR(15) NOT NULL,
    address TEXT NOT NULL,
    location GEOMETRY(Point, 4326),
    loyalty_years INT DEFAULT 0,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE station_technicians (
    tech_id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    station_code VARCHAR(50) NOT NULL,
    full_name VARCHAR(100) NOT NULL,
    phone VARCHAR(15) UNIQUE NOT NULL,
    current_workload INT DEFAULT 0,
    is_available BOOLEAN DEFAULT TRUE,
    rating_score NUMERIC(3, 2) DEFAULT 5.00
);

CREATE TABLE warranty_tickets (
    ticket_id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    ticket_code VARCHAR(32) UNIQUE NOT NULL,
    customer_phone VARCHAR(15) NOT NULL,
    product_serial VARCHAR(100) NOT NULL,
    error_code VARCHAR(20),
    status ticket_status DEFAULT 'PENDING',
    assigned_tech_id UUID REFERENCES station_technicians(tech_id),
    dealer_id UUID REFERENCES distributors(dealer_id),
    sla_due_date TIMESTAMP WITH TIME ZONE NOT NULL,
    resolution_note TEXT,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_tickets_status ON warranty_tickets(status);
CREATE INDEX idx_tickets_serial ON warranty_tickets(product_serial);

Thiết kế API Endpoints

  • POST /api/v1/tickets/dispatch: Tiếp nhận yêu cầu sự cố và tự động định tuyến kỹ thuật viên.
  • GET /api/v1/distributors/{dealer_code}/rfm: Truy xuất chỉ số phân khúc đại lý (Recency, Frequency, Monetary).
  • POST /api/v1/telephony/call-event: Webhook tiếp nhận sự kiện cuộc gọi từ tổng đài Asterisk 1900.

Phương pháp luận triển khai (Methodology)

Dự án áp dụng mô hình phát triển Agile Scrum với chu kỳ Sprint 2 tuần, kết hợp phương pháp nghiên cứu định lượng phân tích nhân tố khám phá (EFA) để lượng hóa các tiêu chí tác động từ chất lượng dịch vụ đến sức mạnh thương hiệu.

Ma trận đánh giá và giảm thiểu rủi ro

Nhận diện rủi ro Mức độ Khả năng xảy ra Biện pháp giảm thiểu
Đại lý từ chối sử dụng phần mềm Cao Trung bình Tích hợp Zalo Mini App không cần cài đặt; áp dụng chính sách tặng điểm tích lũy.
Hạ tầng mạng trạm tỉnh không ổn định Trung bình Cao Thiết kế PWA với cơ chế Offline-first, đồng bộ dữ liệu nền qua IndexedDB.
Quá tải đường dây nóng mùa cao điểm Cao Cao Thiết lập hệ thống IVR thông minh, phân bổ cuộc gọi theo vùng miền và kỹ thuật viên.

Triển khai thực nghiệm và Kết quả

Quá trình phát triển và Thuật toán điều phối

Hệ thống triển khai thuật toán Dynamic Nearest-Fit Dispatching (DNFD) nhằm tối ưu hóa việc phân công việc sửa chữa cho kỹ thuật viên tại 60 trạm ủy quyền, dựa trên khoảng cách địa lý (Haversine Formula) kết hợp trọng số tải công việc hiện tại.

import math
from typing import List, Optional
from pydantic import BaseModel
from uuid import UUID

class Technician(BaseModel):
    tech_id: UUID
    full_name: str
    latitude: float
    longitude: float
    current_workload: int
    is_available: bool

class DispatchEngine:
    @staticmethod
    def haversine_distance(lat1: float, lon1: float, lat2: float, lon2: float) -> float:
        R = 6371.0  # Earth radius in kilometers
        dlat = math.radians(lat2 - lat1)
        dlon = math.radians(lon2 - lon1)
        a = (math.sin(dlat / 2) ** 2 +
             math.cos(math.radians(lat1)) * math.cos(math.radians(lat2)) *
             math.sin(dlon / 2) ** 2)
        c = 2 * math.atan2(math.sqrt(a), math.sqrt(1 - a))
        return R * c

    @classmethod
    def select_best_technician(
        cls, 
        cust_lat: float, 
        cust_lon: float, 
        technicians: List[Technician], 
        max_workload: int = 5
    ) -> Optional[Technician]:
        candidates = [t for t in technicians if t.is_available and t.current_workload < max_workload]
        if not candidates:
            return None

        # Cost function: Distance (km) * 0.7 + Workload (units) * 0.3 * 10
        # Time Complexity: O(N), Space Complexity: O(1)
        best_candidate = min(
            candidates,
            key=lambda t: (cls.haversine_distance(cust_lat, cust_lon, t.latitude, t.longitude) * 0.7) + 
                          (t.current_workload * 3.0)
        )
        return best_candidate

Kiểm thử và Đánh giá hiệu năng

Kết quả Benchmark hệ thống (k6 / Locust Test)

  • Tải kiểm thử: 500 người dùng đồng thời (Concurrent Virtual Users) tương ứng lưu lượng giờ cao điểm mùa hè.
  • Throughput: 1.250 Requests Per Second (RPS).
  • Độ trễ phản hồi (Response Latency): $P_{50} = 45\text{ ms}$, $P_{95} = 128\text{ ms}$, $P_{99} = 210\text{ ms}$.
  • Tỷ lệ lỗi (Error Rate): $0.00%$ trên tổng số 100.000 requests.
+-----------------------------------------------------------------------------+
|                            KIỂM THỬ TẢI HỆ THỐNG                            |
| Target: 500 VUs | Duration: 10m | Total Requests: 100,000                   |
+-----------------------------------+-----------------------------------------+
| HTTP 200 (Success)                | 100,000 [100%]                          |
| HTTP 5xx (Server Error)           | 0       [0.00%]                         |
| P95 Latency                       | 128 ms                                  |
| P99 Latency                       | 210 ms                                  |
+-----------------------------------+-----------------------------------------+

Kết quả kinh doanh và Vận hành thực tế (2014 – 2016)

Bảng chỉ số tài chính và tăng trưởng đại lý

Chỉ tiêu kinh doanh Năm 2014 Năm 2015 Năm 2016 Tăng trưởng 2016/2015 (%)
Doanh thu thuần (tỷ VNĐ) 185,28 264,52 324,94 +22,56%
Lợi nhuận gộp (tỷ VNĐ) 23,54 38,12 48,90 +28,28%
Lợi nhuận sau thuế (tỷ VNĐ) 6,51 18,48 24,80 +34,19%
Đại lý thực tăng mới (điểm) 17 24 33 +37,50%
Đại lý trung thành > 3 năm 143 167 200 +19,76%
Tỷ lệ đại lý rời bỏ (Churn Rate) 8 đại lý 6 đại lý 5 đại lý -16,67% (Cải thiện)
Tăng trưởng Doanh thu & Lợi nhuận Nagakawa (2014 - 2016)
Doanh thu (tỷ VNĐ):  [2014: 185.28] =====> [2015: 264.52] ======> [2016: 324.94] (+22.56%)
Lợi nhuận (tỷ VNĐ):  [2014:   6.51] =====> [2015:  18.48] ======> [2016:  24.80] (+34.19%)
Đại lý trung thành: [2014: 143 đại lý] => [2015: 167 đại lý] => [2016: 200 đại lý] (+20.00%)

Đánh giá khảo sát thực nghiệm

  • Khảo sát đại lý B2B ($N = 100$): Mức độ hài lòng chung đạt 68% (22% Rất hài lòng, 46% Hài lòng); Tỷ lệ hài lòng về sự kiện tri ân và hỗ trợ Trade Marketing đạt 89%.
  • Khảo sát người tiêu dùng B2C ($N = 1000$): 66% khách hàng hài lòng với chất lượng phục vụ của kỹ thuật viên tại các trạm bảo dưỡng tỉnh (43% Hài lòng, 23% Rất hài lòng).

Đổi mới và Đóng góp

Đổi mới kỹ thuật và Quy trình

  1. Liên kết vòng lặp chất lượng đóng (Closed-Loop Quality Control): Tích hợp trực tiếp dữ liệu mã lỗi bảo hành ngoài thị trường vào hệ thống quản lý chất lượng nhà máy Phúc Yên: $$\text{Defect Rate (Field)} \longrightarrow \text{OQC} \longrightarrow \text{LQC} \longrightarrow \text{IQC (Linh kiện đầu vào)}$$
  2. Khung quy định SLA bảo hành đa cấp: Chuẩn hóa thời gian khắc phục sự cố: $< 24\text{h}$ đối với khu vực đô thị loại 1 và $< 48\text{h}$ đối với khu vực ngoại thành/tỉnh xa.
  3. Chính sách đổi trả minh bạch số hóa: Xóa bỏ cơ chế giải quyết cảm tính của nhân viên bán hàng bằng quy chuẩn tính điểm khấu hao và duyệt đổi trả tự động qua portal đại lý.

So sánh với các giải pháp hiện hành trên thị trường

Tính năng Quy trình cũ Nagakawa Hệ thống Panasonic/Daikin Hệ thống Smart-CRM Nagakawa mới
Cơ chế phân bổ phiếu sửa chữa Thủ công gọi điện Hệ thống phân vùng tự động Định tuyến tối ưu kết hợp tải trọng kỹ thuật viên
Quản lý dữ liệu bảo hành Sổ sách, phiếu bảo hành giấy Phần mềm chuyên dụng nội bộ Cơ sở dữ liệu tập trung PostgreSQL + Web Portal
Phản hồi khiếu nại mạng xã hội Trễ ($> 12\text{h}$) Tích hợp CRM Social ($< 2\text{h}$) Omnichannel Bot & Webhook Alert ($< 15\text{ phút}$)
Chi phí vận hành trạm tỉnh Cao do trùng lặp nhân sự Chuẩn hóa cao, chi phí cao Tối ưu hóa chi phí nhờ trạm ủy quyền tự quản trị

Ứng dụng thực tế và Triển khai

Kịch bản vận hành thực tế (Use Cases)

Kịch bản 1: Xử lý bảo hành khẩn cấp cho khách hàng B2C

  1. Khách hàng gọi đến tổng đài 1900 545489 báo lỗi điều hòa kêu to và không mát.
  2. Tổng đài viên tạo Ticket trên giao diện CRM, hệ thống tự động trích xuất lịch sử mã máy và vị trí địa lý.
  3. Thuật toán DNFD gợi ý kỹ thuật viên thuộc trạm bảo hành tỉnh gần nhất có tải công việc thấp.
  4. Kỹ thuật viên nhận thông báo trên PWA, tiếp nhận hiện trường trong vòng 2 giờ và cập nhật linh kiện thay thế.
  5. Sau khi đóng ticket, hệ thống tự động kích hoạt cuộc gọi IVR khảo sát điểm hài lòng CSAT.

Kịch bản 2: Đại lý đặt hàng số lượng lớn và xử lý chiết khấu

  • Đại lý truy cập Web Portal, đặt đơn hàng $\ge 15$ sản phẩm: Hệ thống tự động áp dụng chính sách miễn 100% phí vận chuyển và cập nhật điểm thưởng đại lý thân thiết.

Hướng dẫn triển khai hạ tầng (Deployment Configuration)

# docker-compose.production.yml
version: '3.8'

services:
  crm-backend:
    image: nagakawa/crm-core:v1.2.0
    restart: always
    environment:
      - DATABASE_URL=postgresql://crm_user:${DB_PASSWORD}@db:5432/nagakawa_crm
      - REDIS_URL=redis://redis:6379/0
      - ASTERISK_AMI_HOST=192.168.10.50
    ports:
      - "8000:8000"
    depends_on:
      - db
      - redis

  db:
    image: postgis/postgis:15-3.3
    restart: always
    environment:
      - POSTGRES_DB=nagakawa_crm
      - POSTGRES_USER=crm_user
      - POSTGRES_PASSWORD=${DB_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7.2-alpine
    restart: always

volumes:
  pgdata:

Phân tích hiệu quả kinh tế (Cost-Benefit Analysis)

  • Tổng chi phí đầu tư (CAPEX): 350.000.000 VNĐ (Bao gồm chi phí máy chủ, số hóa dữ liệu và đào tạo nhân sự 60 trạm).
  • Chi phí vận hành hàng năm (OPEX): 60.000.000 VNĐ (Bảo trì đường truyền, hosting, nâng cấp phần mềm).
  • Lợi ích định lượng:
    • Giảm thiểu 35% chi phí xử lý sai hỏng và vận chuyển đổi trả không cần thiết.
    • Tăng tỷ lệ giữ chân đại lý (Retention Rate) thêm 19,76%, đóng góp vào mức tăng trưởng lợi nhuận 34,19% (đạt 24,80 tỷ VNĐ năm 2016).
  • Thời gian hoàn vốn (Payback Period): Ước tính đạt 8,5 tháng.

Hạn chế và Hướng phát triển

Hạn chế kỹ thuật hiện tại

  • Hệ thống điều hòa thế hệ cũ chưa tích hợp chip kết nối IoT/Wi-Fi, việc thu thập thông số kỹ thuật (áp suất gas, dòng điện máy nén) vẫn phụ thuộc vào đo đạc thủ công của kỹ thuật viên.
  • Trình độ công nghệ thông tin của chủ đại lý tại các vùng nông thôn chưa đồng đều, đòi hỏi thời gian đào tạo kéo dài.

Lộ trình nâng cấp (Roadmap)

  1. Giai đoạn 1 (2017 – 2019): Phủ sóng 100% phần mềm CRM cho 500 đại lý và 60 trạm ủy quyền; tự động hóa hoàn toàn tổng đài 1900.
  2. Giai đoạn 2 (2020 – 2022): Ra mắt dòng điều hòa Smart-Inverter tích hợp module IoT chẩn đoán lỗi tự động gửi về trung tâm điều hành.
  3. Giai đoạn 3 (2023 – 2025): Ứng dụng mô hình học máy (Machine Learning) để dự báo nhu cầu linh kiện bảo hành theo mùa vụ và vùng khí hậu.

Đối tượng hưởng lợi

+-------------------------------------------------------------------------------+
|                             GIÁ TRỊ MANG LẠI                                  |
+-----------------------+-------------------------------------------------------+
| Sinh viên &           | - Tham khảo mô hình nghiên cứu gắn kết giữa Marketing |
| Nghiên cứu sinh       |   và Kỹ thuật hệ thống trong ngành HVAC.              |
|                       | - Dữ liệu thực nghiệm phong phú từ doanh nghiệp niêm  |
|                       |   yết (HOSE/HNX: NAG).                                |
+-----------------------+-------------------------------------------------------+
| Kỹ sư phần mềm &      | - Kiến trúc mẫu tích hợp CTI/Asterisk PBX và Webhook. |
| Solution Architects   | - Codebase điều phối kỹ thuật viên dựa trên PostGIS.  |
+-----------------------+-------------------------------------------------------+
| Doanh nghiệp sản xuất | - Mô hình chuyển đổi số dịch vụ khách hàng chi phí    |
| & Phân phối B2B2C     |   thấp, khả thi cho các đơn vị quy mô vừa và lớn.     |
|                       | - Chiến lược giữ chân đại lý bằng chính sách minh bạch|
+-----------------------+-------------------------------------------------------+

Câu hỏi thường gặp

1. Yêu cầu phần cứng và hạ tầng để triển khai hệ thống CRM này là gì?

Hệ thống yêu cầu máy chủ Server (hoặc Cloud VPS) tối thiểu 4 vCPU, 8GB RAM, 100GB SSD NVMe chạy hệ điều hành Ubuntu Server 22.04 LTS. Tại các trạm ủy quyền, kỹ thuật viên chỉ cần điện thoại thông minh chạy Android 8.0 hoặc iOS 12 trở lên để sử dụng PWA qua trình duyệt web.

2. Hệ thống xử lý thế nào trong trường hợp mất kết nối Internet tại các vùng xa?

Ứng dụng Field Service PWA được trang bị Service Worker và thư viện IndexedDB, cho phép kỹ thuật viên cập nhật thông tin phiếu bảo hành, chụp ảnh chứng từ ngoại tuyến (Offline Mode). Dữ liệu sẽ tự động đồng bộ (Background Sync) ngay khi thiết bị có kết nối Internet trở lại.

3. Làm thế nào để đồng bộ dữ liệu giữa tổng đài 1900 545489 và CRM?

Hệ thống sử dụng Asterisk Manager Interface (AMI) và FastAGI để bắt sự kiện cuộc gọi theo thời gian thực (Real-time Call Events). Khi có cuộc gọi đến, số điện thoại được đối soát với cơ sở dữ liệu khách hàng để tự động mở Popup thông tin (Screen Pop) trên màn hình tổng đài viên trong thời gian $< 300\text{ ms}$.

4. Chi phí bảo trì và nâng cấp phần mềm hàng năm là bao nhiêu?

Nhờ sử dụng nền tảng mã nguồn mở (Python, PostgreSQL, Redis, Linux), doanh nghiệp không phải trả phí bản quyền phần mềm định kỳ trên mỗi người dùng (Per-user License). Chi phí vận hành chỉ bao gồm hạ tầng máy chủ và gói hỗ trợ kỹ thuật ước tính khoảng 5.000.000 VNĐ/tháng.

5. Chính sách bảo mật dữ liệu khách hàng và đại lý được thiết kế ra sao?

Cơ sở dữ liệu áp dụng cơ chế mã hóa AES-256 đối với các trường thông tin nhạy cảm (Số điện thoại, địa chỉ, chiết khấu doanh thu). Quyền truy cập được kiểm soát chặt chẽ thông qua mô hình Phân quyền theo vai trò (Role-Based Access Control - RBAC) và xác thực định danh qua giao thức JWT (JSON Web Token) kết hợp mã hóa TLS 1.3 trên đường truyền.


Kết luận

Đề tài đã chứng minh một cách toàn diện rằng nâng cao chất lượng dịch vụ chăm sóc khách hàng là đòn bẩy sống còn để phát triển thương hiệu bền vững cho Công ty Cổ phần Nagakawa Việt Nam. Việc kết hợp chặt chẽ giữa chiến lược quản trị định hướng khách hàng, quy trình kiểm soát chất lượng IQC-LQC-OQC và hệ thống công nghệ số hóa Omnichannel CRM đã mang lại hiệu quả kinh doanh vượt bậc: doanh thu năm 2016 đạt 324,94 tỷ VNĐ (+22,56%) và lợi nhuận sau thuế đạt 24,80 tỷ VNĐ (+34,19%). Đây là mô hình ứng dụng thực tiễn điển hình cho các doanh nghiệp sản xuất và thương mại điện lạnh Việt Nam trên con đường hiện đại hóa và hội nhập kinh tế quốc tế.