Thiết kế website theo yêu cầu, làm đúng cách bạn bán hàng và vận hành

Một website không cần làm riêng chỉ để trông khác những trang đang có trên mạng. Lý do đáng đầu tư nằm ở chỗ web mẫu buộc bạn đổi cách bán hàng, nhập dữ liệu hoặc phục vụ khách để vừa với những ô có sẵn.

Ví dụ, một cửa hàng sơn cần khách lọc theo loại bề mặt, dòng sản phẩm và bảng màu. Mẫu bán hàng chỉ có danh mục chung vẫn đăng sản phẩm được, nhưng khách phải mở từng trang để tìm, còn nhân viên lại nhận nhiều câu hỏi lặp về những thông tin đáng lẽ website đã giúp chọn từ đầu.

Trang này đi sâu vào trường hợp cần làm khác mẫu có sẵn. Nếu bạn vẫn đang chọn giữa website giới thiệu, bán hàng hoặc một hướng khác, phần tổng quan tại dịch vụ thiết kế website sẽ giúp xác định loại phù hợp trước.

Khách phải đi theo một đường riêng trước khi liên hệ

Dịch vụ đơn giản thường chỉ cần khách đọc thông tin rồi gọi điện. Nhưng có nơi khách phải chọn chi nhánh, loại nhu cầu, ngày dự kiến và một số điều kiện trước khi gửi yêu cầu. Nếu biểu mẫu chỉ có họ tên và số điện thoại, nhân viên vẫn phải gọi lại để hỏi từ đầu.

Thiết kế website theo yêu cầu có ích khi những bước này ảnh hưởng thật tới cách tư vấn. Web22 sắp xếp chúng thành một luồng vừa đủ, không bắt khách điền cả một hồ sơ dài chỉ để được liên hệ.

Dữ liệu cần đi đúng người và đúng chỗ

Một doanh nghiệp có nhiều chi nhánh có thể muốn yêu cầu từ quận nào chuyển thẳng về nhân viên phụ trách khu vực đó. Một đội dịch vụ lại cần phân loại khách mới, khách cũ và đối tác để mỗi nhóm nhận cách xử lý khác nhau.

Đây không còn là chuyện đổi màu hay thay bố cục. Website phải đọc dữ liệu khách gửi, áp dụng quy tắc đã chốt và thông báo đúng người; nếu làm sai, yêu cầu vẫn vào hệ thống nhưng nằm im ở một hộp thư không ai theo dõi.

Phần quản trị phải theo cách nhân viên đang làm

Có website nhìn ổn bên ngoài nhưng mỗi lần đổi giá, thêm dự án hoặc cập nhật trạng thái đều phải sửa ở nhiều nơi. Nhân viên không biết trường nào bắt buộc, quản lý không biết ai đã thay dữ liệu, còn người làm web trở thành người duy nhất dám chạm vào trang quản trị.

Khi đó phần cần làm riêng nằm phía sau. Web22 có thể sắp lại trường nhập, tạo vai trò phù hợp, cho nhập một lần rồi dùng dữ liệu ở nhiều vị trí và ẩn những lựa chọn người dùng không cần nhìn thấy.

Khi nào web mẫu đã đủ dùng

Nếu bạn cần vài trang giới thiệu, một danh sách dịch vụ, thông tin liên hệ và biểu mẫu cơ bản, website mẫu vẫn có thể đáp ứng tốt. Làm thêm chức năng lúc chưa có nhu cầu thật chỉ làm giá tăng và tạo thêm phần phải bảo trì.

Doanh nghiệp đang thử mô hình cũng nên bắt đầu vừa sức. Khi chưa biết khách có dùng bộ lọc, tài khoản hay đặt lịch hay không, làm một phiên bản cơ bản rồi quan sát dữ liệu thật thường chắc chắn hơn đoán trước một hệ thống lớn.

Cùng gọi là “theo yêu cầu” nhưng thay giao diện, sửa phần quản trị và xây một chức năng mới là ba loại công việc khác nhau. Nếu gom thành một giá chung, con số hoặc quá cao với người chỉ cần giao diện, hoặc quá thấp để làm chắc một luồng dữ liệu phức tạp.

Tùy chỉnh giao diện và mẫu trang

Mức này phù hợp khi nội dung và chức năng quen thuộc, nhưng cách trình bày phải theo thương hiệu hoặc cách khách tìm hiểu. Công việc tập trung vào trang chủ, trang dịch vụ, sản phẩm, dự án và những thành phần lặp lại trên điện thoại.

Website thương hiệu có nhiều mẫu trang và giao diện riêng thường nằm trong khoảng 7 đến 15 triệu. Số chính xác còn tùy số kiểu trang, tình trạng nội dung và lượng dữ liệu Web22 cần nhập ban đầu.

Tùy chỉnh phần quản trị hoặc chức năng khách dùng

Giá tăng khi website cần bộ lọc, đặt lịch, tính giá, phân quyền, quản lý yêu cầu, bán hàng hoặc cách nhập dữ liệu riêng. Những chức năng này phải được thử với nhiều trường hợp, không chỉ dựng một màn hình rồi xem như đã xong.

Website bán hàng hoặc có nhiều chức năng thường nằm trong khoảng 15 đến 30 triệu. Một biểu mẫu đặt lịch đơn giản khác hẳn hệ thống có lịch từng nhân viên, giới hạn số chỗ, nhắc hẹn và đổi lịch, nên tên chức năng không đủ để chốt giá.

Nghiệp vụ riêng, nhiều dữ liệu hoặc kết nối hệ thống

Mức trên 30 triệu thường xuất hiện khi website có nhiều vai trò, lượng dữ liệu lớn, quy tắc xử lý riêng hoặc phải trao đổi dữ liệu với phần mềm khác. Chi phí không tăng vì dùng từ “cao cấp”, mà vì số tình huống cần phân tích, xây và kiểm tra nhiều hơn.

Để nhận báo giá sát, bạn không cần tự viết tài liệu kỹ thuật. Chỉ cần mô tả người nào đang làm việc gì, dữ liệu lấy từ đâu, bước nào mất thời gian và kết quả cuối cần chuyển cho ai; Web22 sẽ hỏi tiếp để chốt thành danh sách cụ thể. Bạn cũng có thể xem các mức chung tại bảng giá thiết kế website.

Phần khó nhất của website theo yêu cầu không phải viết mã. Cái khó là hiểu đúng một công việc đang diễn ra bằng cuộc gọi, bảng tính, tin nhắn và kinh nghiệm của nhân viên, rồi chuyển nó thành các bước đủ rõ để website xử lý.

Giả sử một đơn vị nhận yêu cầu khảo sát. Khách chọn loại dịch vụ và địa điểm, hệ thống kiểm thông tin, chuyển yêu cầu cho người phụ trách, nhân viên hẹn lịch, sau đó quản lý cần biết yêu cầu đang mới, đã liên hệ hay đã hoàn thành. Chỉ cần thiếu một trạng thái, đội vận hành lại phải quay về hỏi nhau qua tin nhắn.

Bắt đầu từ người sử dụng, không bắt đầu từ màn hình

Web22 xác định ai sẽ dùng từng phần: khách, nhân viên, quản lý hay đối tác. Mỗi người cần xem và thay đổi dữ liệu khác nhau, nên một màn hình dùng chung cho tất cả thường vừa rối vừa dễ lộ thông tin không cần thiết.

Chẳng hạn khách chỉ cần biết yêu cầu đã được tiếp nhận, nhân viên cần số điện thoại và ghi chú, còn quản lý cần thống kê theo trạng thái. Khi vai trò rõ, giao diện và quyền truy cập mới có cơ sở để làm đúng.

Gọi đúng tên dữ liệu phải lưu

Câu “lưu thông tin khách” vẫn còn quá chung. Tên, số điện thoại, chi nhánh, loại dịch vụ, thời điểm mong muốn, nguồn khách và lịch sử xử lý có thể đều liên quan, nhưng không phải dự án nào cũng cần giữ hết.

Web22 cùng bạn chọn dữ liệu cần cho bước tiếp theo, bỏ trường chỉ để “biết thêm” nhưng không ai dùng. Ít trường hơn giúp khách gửi nhanh hơn, phần quản trị cũng bớt những cột trống khó theo dõi.

Xác định điều kiện và đường lui khi có lỗi

Một luồng tốt phải nói được chuyện gì xảy ra khi dữ liệu thiếu, kết nối ngoài tạm ngừng hoặc người nhận chưa phản hồi. Nếu chỉ mô tả trường hợp mọi thứ đều thuận lợi, website có thể chạy đẹp lúc thử nhưng mắc ngay khi gặp dữ liệu thật.

Ví dụ, khi email thông báo gửi lỗi, yêu cầu của khách vẫn phải được lưu để nhân viên kiểm tra lại. Nếu hệ thống thanh toán chưa phản hồi, đơn không nên tự chuyển thành đã trả tiền chỉ vì khách quay về trang cảm ơn.

Chốt điểm kết thúc của từng luồng

“Gửi biểu mẫu thành công” chỉ là điểm kết thúc đối với khách. Với doanh nghiệp, công việc có thể chưa xong cho tới khi nhân viên nhận thông báo, thấy yêu cầu trong quản trị và biết phải làm gì tiếp theo.

Mỗi luồng vì vậy cần một kết quả kiểm tra được. Cách làm này giúp hai bên nghiệm thu cùng một thứ, thay vì Web22 nói chức năng đã chạy còn người vận hành lại thấy chưa dùng được.

Những tên như đặt lịch, thành viên, tính giá, tìm kiếm nâng cao hoặc phân quyền nghe có vẻ rõ nhưng thực tế chứa nhiều cách hiểu. Hai báo giá cùng ghi “đặt lịch” có thể chênh nhau rất xa vì một bên chỉ lưu ngày, bên kia còn xử lý nhân viên, khung giờ, số chỗ, nhắc hẹn và đổi lịch.

Một tình huống cần đủ sáu mảnh

Web22 mô tả người sử dụng, điểm bắt đầu, thao tác, dữ liệu nhập, kết quả và trường hợp lỗi. Với bộ lọc sản phẩm, chẳng hạn, cần biết khách lọc theo thuộc tính nào, có chọn nhiều điều kiện cùng lúc không, kết quả hết hàng hiển thị ra sao và người quản trị thêm thuộc tính mới ở đâu.

Khi sáu mảnh này rõ, tên chức năng không còn là lời hứa mơ hồ. Người viết, người duyệt và người sử dụng đều có thể đọc rồi chỉ ra chỗ nào chưa đúng trước khi công việc đi quá xa.

Ví dụ tham khảo chỉ để minh họa một phần

Bạn có thể gửi website khác để chỉ cách lọc, bố cục hoặc một thao tác mình thích. Tuy nhiên, câu “làm giống trang A” không nên thay cho mô tả chức năng, vì bên ngoài giống nhau nhưng dữ liệu và cách quản trị phía sau có thể hoàn toàn khác.

Web22 sẽ hỏi rõ bạn muốn học phần nào từ ví dụ đó. Cách này vừa tránh sao chép nguyên một website, vừa không để đội làm web tự đoán rằng mọi chi tiết trên trang tham khảo đều là yêu cầu bắt buộc.

Thay đổi sau khi chốt được xử lý thế nào

Trong lúc xem bản chạy, bạn có thể nhận ra một bước cần đổi. Nếu thay đổi chỉ là câu chữ hoặc cách sắp xếp trong mẫu đã chốt, việc sửa thường nhẹ; nếu nó tạo thêm dữ liệu, vai trò hoặc nhánh xử lý, Web22 phải kiểm tra lại các phần liên quan.

Trước khi làm thêm, Web22 nói rõ thay đổi ảnh hưởng tới trang nào, chức năng nào, lịch và chi phí ra sao. Hai bên xác nhận rồi mới thực hiện, không để tới cuối mới tranh luận một ý phát sinh có nằm trong giá cũ hay không.

Dự án theo yêu cầu ít khi trễ chỉ vì viết mã lâu hơn dự tính. Phần lớn vướng ở nội dung chưa sẵn, quy tắc thay đổi, dữ liệu cũ không đồng nhất hoặc người duyệt chưa thống nhất cách làm.

Nội dung thật tới muộn hơn giao diện

Giao diện có thể trông vừa vặn với đoạn chữ mẫu, nhưng vỡ bố cục khi tên sản phẩm dài gấp ba hoặc ảnh thật có tỉ lệ khác nhau. Vì vậy Web22 cần một nhóm nội dung đại diện sớm, không nhất thiết đủ toàn bộ nhưng phải giống thứ sẽ dùng khi website hoạt động.

Nếu nội dung chưa hoàn chỉnh, hai bên chốt trước độ dài, loại ảnh và trường dữ liệu. Việc này không thay thế nội dung thật, nhưng giảm nguy cơ thiết kế xong mới phát hiện mẫu trang không chứa nổi thông tin cần đăng.

Quy tắc nằm trong đầu một người

Nhiều công việc chạy được vì nhân viên lâu năm tự biết trường hợp nào cần gọi ai, đơn nào phải duyệt và ngoại lệ nào được bỏ qua. Khi đưa lên website, những kinh nghiệm đó phải được nói ra; hệ thống không thể tự hiểu một quy tắc chưa ai ghi lại.

Web22 thường dùng ví dụ cụ thể để tìm ngoại lệ. “Nếu khách ở ngoài khu vực giao thì sao?” hoặc “nếu hai nhân viên cùng rảnh thì chia lịch thế nào?” là những câu giúp lộ phần còn thiếu trước khi chức năng được dựng.

Dữ liệu cũ không sạch như dự kiến

Hai nghìn sản phẩm trong bảng tính có thể dùng nhiều cách viết tên, thiếu ảnh, trùng mã hoặc để giá trong ô chữ. Nếu đưa thẳng sang website mới, lỗi cũ không biến mất mà chỉ chuyển sang một giao diện mới.

Web22 kiểm tra một mẫu dữ liệu trước, thống nhất cột nào giữ, cột nào sửa và phần nào phải làm tay. Khối lượng làm sạch được báo riêng, vì nó phụ thuộc chất lượng dữ liệu chứ không chỉ số dòng.

Kết nối bên thứ ba chưa sẵn quyền truy cập

Cổng thanh toán, phần mềm quản lý khách, đơn vị vận chuyển hoặc dịch vụ gửi tin đều có tài khoản, phí và giới hạn riêng. Nếu tới sát ngày bàn giao mới đăng ký, lịch có thể phải chờ duyệt hoặc chờ nhà cung cấp mở quyền.

Những kết nối này được liệt kê từ đầu cùng người chịu trách nhiệm cung cấp tài khoản. Web22 có thể dựng phần còn lại trước, nhưng chỉ xác nhận luồng hoàn chỉnh khi dịch vụ bên thứ ba đã hoạt động.

Người góp ý và người chốt không phải một người

Nhiều ý kiến không phải vấn đề nếu có một người tổng hợp và quyết định. Dự án dễ đi vòng khi mỗi bộ phận gửi một hướng khác nhau, Web22 sửa theo từng tin nhắn rồi người duyệt cuối lại yêu cầu quay về bản cũ.

Mỗi mốc nên có một phản hồi đã được gom lại. Với thay đổi ảnh hưởng tới chức năng, người vận hành trực tiếp cần tham gia trước khi chốt, vì họ là người biết bước nào đang bất tiện ngoài thực tế.

Các dự án dưới đây đều đã được đối chiếu là website khách hàng, không phải bản mẫu. Điểm đáng xem không nằm ở chuyện bốn giao diện khác màu, mà ở cách nội dung và lựa chọn được sắp theo từng loại sản phẩm, dịch vụ.

Dự án khách hàng

Sữa Đặc Trị MiMi

Website chia sản phẩm theo nhu cầu sử dụng để người mua tìm đúng nhóm sữa và đọc thông tin trước khi chọn.

Xem dự án →

Dự án khách hàng

Quốc Việt Sound & Light

Website dịch vụ sự kiện làm rõ năng lực tổ chức, hình ảnh thực tế và cách gửi yêu cầu cho từng loại chương trình.

Xem dự án →

Dự án khách hàng

Khánh Toàn Color

Website chia danh mục màu và sản phẩm theo nhóm để khách tìm mặt hàng phù hợp mà không phải lướt một danh sách dài.

Xem dự án →

Dự án khách hàng

Hoa Tươi Duy Duy

Website giúp khách tìm hoa theo dịp, xem thông tin giao hàng và liên hệ nhanh khi cần tư vấn mẫu phù hợp.

Xem dự án →

Với website theo yêu cầu, chờ tới cuối mới xem thành phẩm là quá muộn. Web22 chia việc duyệt theo các mốc có thể kiểm tra, để lỗi hiểu sai được phát hiện trước khi nó lan sang nhiều trang và chức năng.

Duyệt giao diện trên bản chạy thật

Web22 Design Live (bản giao diện chạy thật để khách duyệt trước) cho phép bạn mở trên máy tính và điện thoại, bấm thử menu, nút và các thành phần chính. Bản này dùng để chốt cách trình bày trước khi Web22 dựng toàn bộ website, không phải website cuối cùng đem bàn giao.

Phản hồi nên gắn với mục tiêu sử dụng, chẳng hạn nút đặt lịch khó thấy hoặc thông tin quyết định nằm quá xa. Cách góp ý này rõ hơn yêu cầu chung như “làm nổi hơn” nhưng không nói người dùng cần nhìn thấy điều gì.

Nghiệm thu theo tình huống đã chốt

Mỗi chức năng được thử từ đầu tới cuối bằng dữ liệu gần với thực tế. Biểu mẫu phải lưu đúng, thông báo đi đúng người, quyền truy cập chặn đúng chỗ và trường hợp lỗi phải cho người dùng biết bước tiếp theo.

Bạn được thử trên bản gần hoàn chỉnh trước khi tiếp quản. Nếu phát hiện lỗi, mô tả tài khoản, thao tác và kết quả nhận được giúp Web22 tái hiện nhanh hơn một ảnh chụp chỉ ghi “không chạy”.

Thời gian làm website

Website thường hoàn thành trong khoảng 2 đến 4 tuần khi nội dung đã sẵn và các mốc duyệt được phản hồi đúng hẹn. Dự án có nghiệp vụ riêng, nhiều dữ liệu hoặc kết nối hệ thống sẽ cần lịch dài hơn; Web22 chốt mốc sau khi hiểu đủ các luồng cần xây.

Lịch không chỉ là số ngày viết mã. Thời gian còn dành cho duyệt giao diện, chuẩn bị dữ liệu, thử vai trò người dùng, sửa lỗi và hướng dẫn người tiếp quản.

Tài khoản, mã nguồn và bảo hành 12 tháng

Khi bàn giao, bạn nhận tài khoản quản trị, mã nguồn, hướng dẫn sử dụng và danh sách dịch vụ cần gia hạn như tên miền, hosting hoặc công cụ bên thứ ba. Thông tin đứng tên ai, chu kỳ thanh toán thế nào và quyền truy cập ở đâu phải rõ, vì đó mới là cơ sở để bạn thật sự tiếp quản.

Web22 bảo hành lỗi kỹ thuật trong phần đã làm suốt 12 tháng. Khi cần thêm mẫu trang, chức năng hoặc kết nối mới, Web22 kiểm tra ảnh hưởng rồi báo chi phí trước khi thực hiện.

Một website thường lấy nội dung và hành động của khách làm trung tâm. Khi phần lớn người dùng là nhân viên đăng nhập để phân công, duyệt nhiều cấp, theo dõi trạng thái, tạo báo cáo và xử lý nghiệp vụ mỗi ngày, dự án đã gần với phần mềm hơn.

Ví dụ, trang cho khách gửi hồ sơ vẫn là phần website. Nhưng hệ thống phía sau có nhiều phòng ban nhận hồ sơ, quy tắc chuyển bước, lịch sử chỉnh sửa, nhắc hạn và báo cáo theo người xử lý cần được phân tích như web app theo yêu cầu.

Dấu hiệu nên tách phần website và phần vận hành

Nếu khách chỉ cần xem thông tin và gửi yêu cầu, còn nhân viên cần một khu vực làm việc riêng, hai phần nên được xác định rõ. Trang công khai ưu tiên dễ đọc và dễ tìm; khu vận hành ưu tiên dữ liệu, quyền truy cập và tốc độ thao tác.

Tách vai trò không có nghĩa phải xây hai hệ thống ngay từ đầu. Web22 có thể đề xuất giai đoạn đầu xử lý việc cấp thiết, sau đó mở rộng khi luồng đã được kiểm chứng bằng người dùng thật.

Không phải nghiệp vụ nào cũng nên đưa lên web

Một bước hiếm khi xảy ra, thay đổi liên tục hoặc cần phán đoán của người có kinh nghiệm có thể chưa đáng tự động hóa. Giữ thao tác đó cho nhân viên đôi khi rẻ và an toàn hơn xây một chức năng phức tạp chỉ dùng vài lần trong năm.

Mục tiêu của làm theo yêu cầu là giúp công việc chạy thuận lợi, không phải biến mọi việc thành phần mềm. Web22 sẽ nói rõ phần nào đáng xây, phần nào nên giữ thủ công và dữ liệu nào cần theo dõi trước khi quyết định.