Bài này dành cho chủ shop thời trang chuẩn bị thuê làm website mới — đang đi gặp 3-5 vendor để báo giá, không biết cách phân biệt ai làm được thật, ai chỉ “nói cho hay”.

Đa số chủ shop chỉ hỏi giá

Đa số chủ shop khi đi báo giá làm website chỉ hỏi đúng ba câu: bao nhiêu tiền, bao lâu xong, có sửa được không. Một vài người tinh tế hơn hỏi tới thiết kế, hỏi tới giao diện. Rất ít người hỏi đúng câu để biết vendor có thật sự làm được không.

Và đó là lý do 6 tháng sau, website chạy chậm dần. Một năm sau, sale lớn web sập. Hai năm sau, đổi vendor làm lại từ đầu — mất thêm vài trăm triệu nữa.

Bài này tổng hợp 10 câu hỏi bên D-Solutions thấy là quan trọng nhất khi làm website cho ngành thời trang. Bộ này có đặc thù riêng: số lượng biến thể (size × màu) lớn, traffic peak theo campaign, tích hợp Pancake/phần mềm quản lý đơn, ảnh/video lookbook nặng, và đặc biệt là Flash Sale — lúc bình thường web chạy được không có nghĩa là lúc cao điểm chạy được.

Mỗi câu có 3 phần:

  • Vì sao phải hỏi — pain point thực tế nếu vendor không lo phần này
  • Câu trả lời chuẩn nên nhận được — keyword vendor nên nói
  • Red flag — vendor nói gì là dấu hiệu né tránh

Vì sao website thời trang khó hơn ngành khác

Trước khi vào 10 câu hỏi, cần hiểu cấu trúc dữ liệu của ngành. Một shop thời trang tầm trung có khoảng 1.000 mẫu sản phẩm. Mỗi mẫu nhân với 5-7 màu, mỗi màu nhân tiếp 5-7 size. Tổng cộng dễ dàng vượt 30.000 biến thể (SKU). Mỗi biến thể có giá riêng, tồn kho riêng, có thể cả ảnh riêng.

Đây là quy mô data mà các nền tảng SaaS đơn giản (Wix, Squarespace, Shopify gói thấp) không sinh ra để xử lý tốt. Cũng là quy mô mà WooCommerce mặc định bắt đầu chậm dần nếu không tối ưu từ đầu.

Cộng thêm: traffic không ổn định mà tập trung vào những đợt sale (Tết, 11.11, Black Friday, livestream). Một vendor có thể demo web chạy mượt với 10 user, hoàn toàn khác câu chuyện khi 5.000 user cùng add to cart trong 1 phút.

Đó là vì sao 10 câu này khác với câu hỏi cho ngành dịch vụ, ngành B2B, hay landing page brochure thông thường.

Nhóm 1 — Kiến trúc hệ thống và tối ưu hiệu suất

Câu 1: Website em có nhiều màu/size, hơn chục nghìn biến thể, có chậm không?

Vì sao phải hỏi: WooCommerce mặc định lưu mỗi biến thể (variation) thành một bản ghi post riêng với rất nhiều postmeta. Với shop có 30.000 SKU, mỗi lần load trang sản phẩm có thể quét hàng trăm row — chậm dần theo thời gian, đặc biệt khi data tăng. Đến lúc web treo khi khách chọn màu/size thì đã muộn.

Câu trả lời chuẩn nên nhận được:

  • Có nhắc tới HPOS (High-Performance Order Storage) — đây là feature mới của WooCommerce, bật rồi mới đúng chuẩn cho shop quy mô
  • Có Redis Object Cache — lưu lookup biến thể trong RAM, không phải query database mỗi lần
  • Có pre-compute variation matrix — sản phẩm khi save sẽ tự sinh JSON cho ma trận màu × size, lookup tức thì
  • Với SKU lớn hơn nữa, có thể nhắc bảng custom riêng thay vì wp_postmeta mặc định
  • Có công cụ profiling (Query Monitor, New Relic, Blackfire) để phát hiện slow query liên tục

Red flag:

  • Trả lời chung chung “bên em tối ưu rất kỹ” mà không nhắc tên công nghệ cụ thể
  • “Cứ làm bình thường, có vấn đề rồi tối ưu sau” — đợi đến lúc chậm rồi tối ưu là quá muộn, phải build đúng cách từ đầu
  • Đề xuất chuyển sang nền tảng SaaS “vì WooCommerce không chịu nổi” — sai. WooCommerce chịu được, vấn đề là người làm có biết cách hay không

Câu 2: Bộ lọc theo màu/size/giá tải lại trang hay tải ngầm? Có ảnh hưởng SEO không?

Vì sao phải hỏi: Trải nghiệm bộ lọc (faceted search) là điểm convert quan trọng — khách muốn xem nhanh “áo thun nam đen size L dưới 300k”. Nếu mỗi click chọn filter là reload trang, khách bỏ giữa chừng. Nhưng nếu làm AJAX sai cách, bot Google không đọc được nội dung → mất SEO.

Câu trả lời chuẩn nên nhận được:

  • AJAX, không reload — UX mượt
  • Có URL state sync (qua history.pushState) — URL phản ánh filter hiện tại, khách có thể share link, browser back/forward hoạt động đúng
  • SSR cho lần load đầu — bot Google ghé URL có filter vẫn nhận HTML đã render, không cần chạy JavaScript
  • Tránh infinite scroll thuần JS (hỏng SEO), thay bằng “load more” + pagination có link
  • Đo và đảm bảo Core Web Vitals (LCP, INP, CLS) không bị hỏng — Google đặt nặng 3 chỉ số này từ 2024

Red flag:

  • “Bộ lọc bên em dùng plugin X, anh/chị cứ yên tâm” — plugin không xấu nhưng phải biết plugin gì, có URL sync không, có SSR không
  • Không phân biệt được FID (chỉ số cũ) và INP (chỉ số mới) — dấu hiệu không update kiến thức

Câu 3: Hình ảnh sản phẩm và video lookbook của em nặng, có làm chậm web không?

Vì sao phải hỏi: Ngành thời trang là ngành sống nhờ hình ảnh. Một shop trung bình có hàng nghìn ảnh sản phẩm độ phân giải cao, cộng thêm video lookbook cho campaign. Xử lý sai = web load 8 giây, bounce rate 70%.

Câu trả lời chuẩn nên nhận được:

  • Pipeline ảnh tự động: upload bản gốc một lần, hệ thống convert sang AVIF + WebP (nhẹ hơn JPEG 30-50%), giữ JPEG làm fallback
  • Cắt nhiều kích cỡ (srcset) theo device — không tải ảnh 3000px về điện thoại
  • Lazy-load native cho ảnh dưới fold; ảnh hero ưu tiên fetchpriority="high"
  • CDN (Cloudflare hoặc tương đương) phân phối edge gần người dùng nhất
  • Video lookbook: KHÔNG host trực tiếp trên server, dùng Cloudflare Stream / Bunny Stream / Mux cho encode adaptive

Red flag:

  • “Bên em compress ảnh thủ công khi upload” — không scale được, người vận hành sẽ quên hoặc làm sai
  • Không nhắc tới AVIF — đây là định dạng nhẹ nhất hiện tại, vendor không biết = không update
  • Đề nghị “video cứ host trực tiếp lên server cho đơn giản” — tốn băng thông, gây nghẽn server khi nhiều user xem

Nhóm 2 — Tích hợp Pancake và xử lý đơn hàng

Câu 4: Cơ chế đồng bộ tồn kho giữa Website và Pancake hoạt động ra sao?

Vì sao phải hỏi: Đây là điểm chết của 70% shop bán đa kênh. Web báo còn hàng, Pancake báo hết hàng, khách đặt → shop phải gọi xin lỗi. Hoặc ngược lại: Pancake đã trừ tồn nhưng web vẫn hiển thị còn → khách tiếp tục đặt → tồn âm.

Câu trả lời chuẩn nên nhận được:

  • Kiến trúc nhiều lớp: webhook real-time làm chính, REST polling fallback khi webhook fail, reconciliation cron đối soát hàng đêm
  • Webhook in/out đều có signature verification (chống fake request) + idempotency (chống xử lý trùng)
  • Khi network/Pancake outage, hệ thống tự khôi phục đồng bộ khi service phục hồi — không phải vendor vào sửa tay
  • Có audit log lưu mọi lần sync để truy vết lệch

Red flag:

  • “Chỉ dùng cronjob mỗi 15 phút sync” — không real-time, oversell trong giờ cao điểm
  • “Dùng webhook thôi là đủ” — webhook có thể mất, không có lớp fallback là nguy hiểm
  • Không phân biệt được source of truth — vendor không trả lời rõ “khi lệch thì lấy bên nào làm chuẩn”

Câu 5: Nếu kho còn 1 sản phẩm, khách đặt trên web và nhân viên chốt Pancake cùng lúc thì sao?

Vì sao phải hỏi: Đây là câu hỏi mà 90% vendor sẽ trả lời lan man, chứng tỏ chưa làm thật. Race condition (đua) là nỗi đau cụ thể: 2 đơn đặt cùng giây, hệ thống xử lý thế nào?

Câu trả lời chuẩn nên nhận được:

  • Reservation pattern — khi khách bấm “Mua ngay” hoặc add to cart, website tạo “giữ chỗ tạm” trong DB với TTL (15 phút), kèm row-level lock (SELECT FOR UPDATE InnoDB)
  • Pancake là source of truth cho tồn kho cuối cùng — website chỉ giữ chỗ
  • Idempotency key trên mọi order request — kể cả double-click, network retry, không tạo đơn trùng
  • Khi oversell xảy ra (rất hiếm) — trả HTTP 409 + UI báo lịch sự + recommend sản phẩm tương tự
  • Vendor thật sự sẽ nói thẳng giới hạn — nếu Pancake không hỗ trợ reserve API, không thể về 0% oversell tuyệt đối, chỉ giảm risk window xuống vài giây

Red flag:

  • “Bên em chưa gặp tình huống này” — chưa gặp không có nghĩa sẽ không gặp, đặc biệt khi sale
  • Hứa “0% bán âm 100%” mà không nhắc tới reservation, lock, idempotency — đây là marketing speak
  • Trả lời “thì hệ thống tự xử lý” — câu vô nghĩa

Câu 6: Khách có tự tra cứu được trạng thái giao hàng từ website không?

Vì sao phải hỏi: Khi shop đã giao Pancake cho đơn vị vận chuyển (GHN, GHTK, J&T, SPX…), mã vận đơn lưu trên Pancake. Nếu không sync về web, khách phải gọi tổng đài shop để hỏi “đơn em tới đâu rồi?”. Vừa tốn người vừa làm khách bực.

Câu trả lời chuẩn nên nhận được:

  • Pancake webhook trạng thái → bắn về website → lưu order meta
  • Trang tra cứu đơn hàng trên website — khách nhập SĐT + mã đơn, xem timeline trực quan
  • Email transactional tự gửi khi status đổi (đã giao ĐVVC, đang giao, đã giao thành công, hoàn hàng)
  • Tùy chọn: SMS / Zalo ZNS qua nhà cung cấp
  • Fallback: gọi trực tiếp API ĐVVC (GHN, GHTK có public API) bằng tracking code khi webhook chưa kịp về

Red flag:

  • “Khách cứ gọi điện hỏi” — đây là dấu hiệu vendor chưa làm bao giờ
  • Không phân biệt được webhook và polling — dấu hiệu kiến thức yếu

Nhóm 3 — Nền tảng cho SEO và quảng cáo

Câu 7: Schema sản phẩm, sitemap, breadcrumb có sẵn hay phải mua plugin?

Vì sao phải hỏi: Schema (dữ liệu có cấu trúc) là cách Google đọc trang sản phẩm để hiển thị rich snippet (giá + rating + tồn kho) trên kết quả tìm kiếm. Đây là chi tiết tăng CTR rõ rệt. Nếu vendor “cài plugin Rank Math Pro để xử lý” rồi tính tiền hàng năm, là dấu hiệu code không chuẩn.

Câu trả lời chuẩn nên nhận được:

  • Schema build sẵn từ code: Product (price, stock, rating, brand, SKU), CollectionPage (category), BreadcrumbList, Organization, WebSite + SearchAction, VideoObject cho video
  • URL structure chuẩn: slug tiếng Việt không dấu (/san-pham/ao-thun-co-trang), không param ID
  • Canonical đúng cho trang filter/pagination — tránh duplicate content
  • Sitemap.xml auto-update, chia theo nhóm (products / categories / blog)
  • robots.txt chuẩn, chặn /wp-admin/, /cart/, /checkout/
  • Validate bằng Google Rich Results Test trước khi go-live

Red flag:

  • “Bên em dùng plugin SEO trả phí Y” — không sai, nhưng phải biết plugin làm gì
  • Không nhắc tới canonical / hreflang — dấu hiệu chưa hiểu sâu SEO
  • “Để go-live xong rồi cài SEO sau” — SEO phải build vào code từ đầu, không phải tô lên sau

Câu 8: Tracking quảng cáo của em đo lường chính xác hơn cụ thể như thế nào?

Vì sao phải hỏi: Khi shop đốt ngân sách quảng cáo lớn, tracking sai = quảng cáo “học” sai = mất tiền âm thầm. Vài năm gần đây, Safari ITP, Firefox ETP, Chrome dần loại bỏ 3rd-party cookie — tracking truyền thống mất 20-40% data mà không có cảnh báo.

Câu trả lời chuẩn nên nhận được:

  • GTM Server-Side Container (sGTM) trên subdomain first-party (vd sgtm.brand.vn) — bypass tracking prevention của trình duyệt
  • Meta Conversion API (CAPI) — gửi event server-to-server kèm hashed PII
  • Google Enhanced Conversions — match user identifier với Google Ads
  • Dedup giữa Pixel client-side và CAPI server-side bằng event_id
  • Event mapping chuẩn ecommerce: PageView, ViewContent, AddToCart, InitiateCheckout, AddPaymentInfo, Purchase
  • Hỗ trợ Consent Mode v2 nếu cần GDPR
  • Dashboard so sánh Pixel vs CAPI để phát hiện gap sớm

Red flag:

  • “Cứ cài Pixel là được” — đây là cách của 2018, mất hơn 30% data trong 2026
  • Không nhắc CAPI hoặc Enhanced Conversions — vendor đang sống trong quá khứ
  • Hứa “100% tracking” — không vendor nào hứa được, người trung thực sẽ nói “giảm gap còn 5-10%“

Nhóm 4 — Cam kết và bảo trì (SLA)

Câu 9: Website em sập trong Flash Sale thì bao lâu được xử lý?

Vì sao phải hỏi: Flash Sale là lúc shop sống chết nhất. Sập 1 tiếng = mất doanh thu mà có thể không bao giờ lấy lại được vì khách đã bỏ đi mua chỗ khác. Cam kết SLA mơ hồ = khi sự cố xảy ra, vendor sẽ “cố gắng” thay vì có quy trình cụ thể.

Câu trả lời chuẩn nên nhận được:

  • Uptime cam kết bằng con số (vd 99.9%)
  • Phân loại severity rõ — Sev1 (web sập, giỏ hàng lỗi) phản hồi < 30 phút, mục tiêu khôi phục trong vài giờ
  • Giám sát 24/7 chủ động qua uptime monitor + alert
  • War room mode cho Flash Sale lớn — báo trước, vendor pre-scale server + trực kỹ thuật realtime
  • Có runbook cho sự cố thường gặp — không phải vendor mò mẫm khi nóng

Red flag:

  • “Bên em xử lý nhanh lắm anh/chị yên tâm” — không có con số, không có quy trình
  • Không phân biệt được severity — sự cố nào cũng “ưu tiên” = sự cố nào cũng có thể bị bỏ
  • Không có hỗ trợ Flash Sale đặc thù — vendor không hiểu ngành thời trang

Câu 10: Backup lưu ở đâu? Có test khôi phục thật không?

Vì sao phải hỏi: Đây là câu hỏi mà 95% vendor sẽ trả lời “backup hàng ngày tự động”. Nhưng backup hỏng âm thầm là chuyện rất phổ biến — log báo backup thành công nhưng file backup thực ra bị corrupted. Đến lúc cần restore thật mới phát hiện = mất sạch data.

Câu trả lời chuẩn nên nhận được:

  • Backup hàng ngày (incremental DB theo giờ nếu cần)
  • Nguyên tắc 3-2-1: 3 bản sao, 2 loại media, 1 bản off-site (R2 / B2 / S3 ở data center khác hosting chính)
  • Backup mã hoá at-rest + restrict permission theo principle of least privilege
  • Test khôi phục thật định kỳ — restore vào server staging, verify data integrity, verify site chạy được
  • Báo cáo restore test gửi khách kèm RTO (Recovery Time Objective) — thời gian thực để có data lại

Red flag:

  • “Backup hàng ngày tự động” mà không nói lưu đâu, giữ bao lâu, có test không
  • “Tool backup chạy thành công là OK” — sai, log success ≠ file usable
  • Không phân biệt được backup vs disaster recovery — dấu hiệu chưa từng gặp sự cố lớn

Tổng kết: làm sao chọn đúng vendor?

Bộ 10 câu này không phải để vendor trả lời thuộc lòng. Mục tiêu là để anh/chị đánh giá độ sâu của câu trả lời:

  • Vendor giỏi sẽ trả lời thẳng, kèm tên công nghệ cụ thể, kèm giới hạn rõ ràng (vd “không thể 0% oversell nếu Pancake không hỗ trợ reserve API”)
  • Vendor trung bình sẽ trả lời đúng nhưng chung chung (“bên em làm rất kỹ phần này”)
  • Vendor yếu sẽ né bằng cách hứa sales-y, đánh giá thấp tầm quan trọng, hoặc đẩy sang “có gì xử lý sau”

Một kinh nghiệm khác: hỏi xin demo trên web mẫu cùng cấu hình. Vendor đã làm thật sẽ có web mẫu để show ngay, không phải “đang chuẩn bị”. Demo 45 phút với data thật sẽ tiết lộ nhiều hơn 5 buổi pitch deck.

Bên D-Solutions làm những gì?

D-Solutions chuyên thiết kế website và tích hợp Pancake cho ngành thương mại điện tử, đặc biệt là thời trang & FMCG. Stack chuẩn của chúng tôi: WooCommerce + Redis Object Cache + Cloudflare CDN + sGTM + Pancake 2-chiều với reservation pattern.

Nếu anh/chị đang đi báo giá làm web, D-Solutions mời 1 buổi demo 45 phút trên web mẫu cùng cấu hình thật (30k+ SKU, tích hợp Pancake live). Anh/chị sẽ thấy tận mắt cách hệ thống xử lý variant, race condition, faceted filter, tracking đơn hàng.

Liên hệ tư vấn:

Bài viết tổng hợp từ kinh nghiệm thực tế của D-Solutions làm website cho nhiều brand thời trang Việt. Có gì cần làm rõ thêm, anh/chị inbox cho chúng tôi — sẵn sàng trao đổi thẳng.