Chào mọi người
Trong môi trường IT, drama không chỉ nảy sinh từ bug hay spec mơ hồ, mà đôi khi lại xuất phát từ… một tin nhắn thiếu emoji.
Một câu “ok” cụt lủn, hay một lời phản biện chưa khéo, có thể biến Slack/Chatwork thành “chiến trường mini”.

Điều quan trọng là: drama nội bộ thì để nội bộ tự xử. Tuyệt đối không để sóng gió này “tràn” sang kênh khách hàng. Vì với khách, BrSE thường là cầu nối duy nhất, và mọi thông điệp gửi ra ngoài đều cần được lọc nhiễu, chỉnh lý và giữ tone chuyên nghiệp.

 

🌐 Business case — Notify real-time trong hệ thống booking

Cơ chế notify cơ bản trong hệ thống booking:

  1. User đặt lịch thành công → server ghi booking vào DB.

  2. Ngay sau đó server publish sự kiện vào Redis pub/sub.

  3. Redis gửi sự kiện này đến tất cả client đang subscribe.

    • Store admin → chỉ nhận notify của clinic mình quản lý.

    • Company admin → quản lý nhiều clinic → nhận notify từ tất cả.

  4. FE subscribe channel → khi có sự kiện → hiển thị notify real-time.

👉 Hình dung Redis giống cái loa phát thanh của làng:

  • Server là người đọc bản tin.

  • Redis là cái loa.

  • Ai có radio (subscriber) thì sẽ nghe được ngay.

 

 

 

⚠︎ Redis và Queue là gì?

  • Queue = hàng đợi ở siêu thị 🛒: message hay task được xếp hàng, server xử lý lần lượt.

  • Redis = “tủ lạnh mini siêu tốc”: lưu dữ liệu tạm ở RAM, lấy ra cực nhanh.

Nhờ kết hợp Redis + Queue:

  • User booking xong → cần notify ngay cho admin.

  • Message đưa vào queue để không bị mất.

  • Redis giữ tạm rồi đẩy sang service khác để bắn notify.

 

🔥 Drama bùng nổ như thế nào?

Một ngày đẹp trời, khách báo notify không chạy trên production. Team lập tức biến Slack thành bãi chiến trường:

  • BE: “Anh confirm rồi, publish chạy lúc 10:03. Log đầy đủ đây.”

  • FE: “Bên em subscribe channel mà không thấy notify. Rõ ràng server không gửi.”

  • QA: “Mình test 5 lần, client không có event. Đây, screenshot 📸📸📸.”

Trong chưa đầy 10 phút, thread Slack đã vượt 100 tin nhắn. Ai cũng tin mình đúng.
👉 Drama nổ ra vì:

  • BE chỉ nhìn log publish (server → Redis).

  • FE chỉ nhìn log subscribe (Redis → client).

  • QA chỉ nhìn kết quả cuối cùng (FE không hiện notify).

Mỗi người đúng một mảnh → nhưng không ai thấy toàn cảnh.

 

👩‍💻 Bí kíp sống sót (nội bộ trước, khách hàng sau)

 

1) Trong Slack/Chatwork nội bộ

  • Stop the noise: nếu thread bắt đầu căng, BrSE nhảy vào:
    “Mọi người pause chút nhé, để mình tổng hợp fact lại trong một message.”

  • Tách fact khỏi cảm xúc:

    • BE log: publish OK lúc 10:03

    • Redis: subscriber chưa nhận

    • FE log: không có event lúc đó
      👉 Giả định lỗi nằm ở đoạn Redis → FE.

  • Tổng hợp gọn gàng: thay vì 20 tin rời rạc → gom thành 1 tin bullet rõ ràng.

  • Rule 15 phút: nếu >15 phút vẫn chưa xong → hẹn call ngay. Một cuộc call 5 phút nhanh gấp chục lần chat 50 tin.

2) Khi communicate ra ngoài với khách hàng
Khách hàng không quan tâm ai đúng, ai sai. Họ chỉ cần: status hiện tại, nguyên nhân sơ bộ, plan xử lý.

Ví dụ report:

現在、通知のリアルタイム配信に遅延が発生しております。
原因はRedisの受信処理にある可能性が高く、現在調査と対応を進めております。
10分後に進捗をご報告いたします。

 

BrSE ở đây giống bộ lọc:

  • Nội bộ có thể cãi nhau ầm ầm, nhưng ra ngoài chỉ có một tiếng nói duy nhất.

  • Không blame, không cảm xúc. Chỉ fact + action plan.

 

🚀 Bài học rút ra cho BrSE/BA

 

  • Điều phối nội bộ: biến thread ồn ào thành message fact-based, dễ theo dõi.

  • Khi nói với khách: giữ cái cần (fact, status, ETA), bỏ cái thừa (cảm xúc, blame).

  • Nhận diện noise: Slack drama chính là noise, và BrSE là người phải lọc noise.

 

🥀 Đúc kết

Drama trong Slack/Chatwork nội bộ là chuyện thường ngày. Nhưng cách xử lý mới là thứ quyết định team trưởng thành hay bế tắc.

  • Nội bộ: dập noise sớm, gom fact rõ.

  • Ra ngoài: một tiếng nói, khách quan và chuyên nghiệp.

BrSE chính là “người gác cổng” của truyền thông: giữ cho drama không biến thành phim dài tập, và giữ cho khách hàng tin rằng team vẫn kiểm soát được tình hình.