Doanh nghiệp bán hàng dự án thường có một cách làm việc rất khác so với mô hình bán hàng thông thường. Một cơ hội có thể xuất hiện từ lúc dự án mới bắt đầu hình thành, sau đó kéo dài qua nhiều tháng với nhiều bên cùng tham gia như chủ đầu tư, tư vấn, nhà thầu, bộ phận kỹ thuật và mua hàng. Trong suốt thời gian đó, sản phẩm có thể được thay đổi nhiều lần, yêu cầu kỹ thuật có thể điều chỉnh, báo giá có nhiều phiên bản và người cuối cùng phát hành đơn hàng chưa chắc là người đã quyết định chọn sản phẩm từ đầu.
Vì vậy CRM cho doanh nghiệp bán hàng dự án không nên chỉ là nơi lưu khách hàng rồi kéo Deal qua vài cột trạng thái. Điều quan trọng hơn là hệ thống phải hiểu được một dự án thực sự được hình thành và đi tới đơn hàng như thế nào. Khi cấu trúc này được làm đúng ngay từ đầu, sales dễ theo dự án hơn, quản lý nhìn được cơ hội rõ hơn và dữ liệu cũng có giá trị lâu dài hơn nhiều.
CRM phải quản lý được “Dự án” như một đối tượng riêng
Với nhiều CRM thông thường, cách tổ chức khá đơn giản: có một công ty, bên trong có các Contact và sau đó tạo Deal khi xuất hiện cơ hội bán hàng. Cấu trúc này hợp lý với nhiều ngành, nhưng bắt đầu gặp vấn đề khi áp dụng vào bán hàng dự án vì một dự án thực tế có thể liên quan tới rất nhiều công ty khác nhau.
Ví dụ doanh nghiệp đang theo một dự án nhà máy. Chủ đầu tư là công ty A, đơn vị tư vấn là công ty B, tổng thầu là công ty C và phần M&E lại được giao cho công ty D. Doanh nghiệp của mình có thể đang tiếp cận cả tư vấn để đưa sản phẩm vào thiết kế, vừa làm việc với nhà thầu để chuẩn bị báo giá, vừa duy trì quan hệ với chủ đầu tư. Nếu CRM chỉ nhìn từng công ty và từng Deal riêng biệt, sau một thời gian dữ liệu rất dễ bị tách thành nhiều mảnh dù tất cả đều đang nói về cùng một dự án.
Vì vậy nên có một hồ sơ Dự án riêng. Khi mở dự án đó lên, người dùng có thể thấy dự án nằm ở đâu, đang ở giai đoạn nào, những công ty nào tham gia, mình đang theo những hạng mục nào và các thông tin quan trọng hiện tại là gì. Các khách hàng, người liên hệ và cơ hội bán hàng sau đó mới được gắn vào dự án. Cách tổ chức này gần với thực tế hơn nhiều vì dự án là thứ tồn tại xuyên suốt, còn người mua, nhà thầu hoặc từng cơ hội bán hàng có thể thay đổi theo thời gian.
Giai đoạn của dự án và giai đoạn bán hàng là hai chuyện khác nhau
Đây là một điểm rất dễ bị trộn chung khi thiết kế CRM. Một dự án ngoài thị trường có thể đang ở giai đoạn thiết kế, chuẩn bị đấu thầu, lựa chọn nhà thầu hoặc đã bắt đầu thi công. Trong khi đó, hoạt động bán hàng của doanh nghiệp lại có tiến độ riêng: mới phát hiện dự án, đang tiếp cận, đang lên giải pháp, đã gửi báo giá hoặc đang thương lượng.
Hai quá trình này không nhất thiết chạy cùng nhau. Có trường hợp sales đã làm việc với tư vấn từ rất sớm và sản phẩm gần như đã được chấp nhận về kỹ thuật, nhưng dự án vẫn còn nhiều tháng nữa mới phát hành yêu cầu mua hàng. Ngược lại, có dự án đã sắp đặt hàng nhưng doanh nghiệp mình mới biết tới và bắt đầu tiếp cận quá muộn. Nếu CRM chỉ có một cột “Trạng thái”, cả hai tình huống rất khác nhau này dễ bị nhìn giống nhau.
Vì vậy một CRM dành cho bán hàng dự án nên cho doanh nghiệp theo dõi song song dự án đang đi tới đâu và cơ hội bán hàng của mình đang đi tới đâu. Khi tách được hai lớp này, quản lý sẽ nhìn rõ hơn rất nhiều. Một báo giá đã gửi trong dự án còn đang thiết kế phải được đánh giá khác với một báo giá đã gửi trong dự án chuẩn bị phát hành đơn hàng. Đây cũng là cơ sở để dự báo doanh thu sát thực tế hơn thay vì chỉ nhìn vào việc sales đã làm được bao nhiêu bước.
Một dự án có thể tạo ra nhiều cơ hội bán hàng khác nhau
Trong bán hàng dự án, không nên mặc định một dự án chỉ tương ứng với một Deal. Một nhà cung cấp thiết bị có thể cùng lúc theo nhiều hạng mục trong một công trình. Hạng mục thứ nhất có khả năng thắng rất cao, hạng mục thứ hai đang cạnh tranh mạnh với một thương hiệu khác, còn hạng mục thứ ba chưa có báo giá chính thức vì yêu cầu kỹ thuật vẫn đang thay đổi.
Nếu tất cả bị gom thành một Deal duy nhất, người quản lý chỉ nhìn thấy một con số tổng nhưng không hiểu phần nào thực sự có khả năng mang lại doanh thu. Ngược lại, nếu mỗi hạng mục được tạo thành một Deal riêng nhưng không có một dự án chung phía trên, dữ liệu lại bị chia nhỏ và khó nhìn được toàn cảnh.
Cách hợp lý hơn là để một dự án có thể chứa nhiều cơ hội bán hàng. Mỗi cơ hội có thể có nhóm sản phẩm, giá trị dự kiến, khách hàng mua cuối cùng, người phụ trách, tình hình cạnh tranh và kết quả riêng. Nhờ đó doanh nghiệp vừa nhìn được toàn bộ giá trị đang theo trong một dự án, vừa biết cụ thể hạng mục nào đang tốt, hạng mục nào có nguy cơ mất và hạng mục nào chưa tới thời điểm cần đầu tư nhiều nguồn lực.
CRM phải cho thấy ai đang thực sự ảnh hưởng tới dự án
Một trong những đặc điểm khó nhất của bán hàng B2B dự án là người đặt hàng chưa chắc là người quyết định sản phẩm nào được sử dụng. Tư vấn có thể là bên định hướng thương hiệu từ đầu, kỹ thuật của chủ đầu tư có thể quyết định sản phẩm có đạt yêu cầu hay không, nhà thầu là đơn vị thương lượng giá còn bộ phận mua hàng cuối cùng mới là bên phát hành đơn đặt hàng.
Nếu CRM chỉ lưu một Contact chính cho mỗi Deal thì sales rất dễ mất bức tranh quan trọng này. Điều cần biết không chỉ là “đang làm việc với anh A của công ty B”, mà còn phải biết công ty B đang giữ vai trò gì trong dự án, anh A có ảnh hưởng tới quyết định nào và mình còn thiếu quan hệ với bên nào.
Khi mở một dự án, một sales có kinh nghiệm thường muốn nhìn được ngay: ai là chủ đầu tư, ai tư vấn, ai là nhà thầu đang có khả năng mua, người nào đang ủng hộ giải pháp của mình và còn người quan trọng nào chưa tiếp cận được. CRM làm tốt phần này sẽ giúp doanh nghiệp quản lý được mạng lưới quan hệ xung quanh dự án, chứ không chỉ lưu một danh sách số điện thoại.
Có những dự án đã gần thắng trước cả khi báo giá được gửi đi
Bán hàng dự án không phải lúc nào cũng bắt đầu cạnh tranh ở thời điểm gửi báo giá. Trong nhiều ngành kỹ thuật, vị thế của nhà cung cấp đã được hình thành từ rất sớm. Một thương hiệu được tư vấn đưa vào thiết kế, một giải pháp kỹ thuật được chấp thuận, một mẫu sản phẩm được duyệt hoặc tên nhà cung cấp được đưa vào danh sách cho phép có thể tạo lợi thế rất lớn trước khi bộ phận mua hàng chính thức hỏi giá.
Nếu CRM chỉ đo hoạt động bằng số cuộc gọi, số cuộc họp hoặc việc “đã gửi báo giá chưa”, doanh nghiệp có thể bỏ qua những tín hiệu quan trọng nhất. Một sales gửi rất nhiều email chưa chắc đang có vị thế tốt bằng một sales đã khiến giải pháp của mình được chấp nhận ở giai đoạn thiết kế.
Vì vậy hệ thống nên cho phép doanh nghiệp tự xác định những mốc quan trọng của quá trình theo dự án. Với công ty này có thể là đã được duyệt mẫu, với công ty khác là đã được tư vấn chấp thuận giải pháp hoặc đã được đưa vào danh sách nhà cung cấp. Khi những mốc này được lưu lại, quản lý sẽ không chỉ biết sales “đang bận”, mà còn biết công sức đó đang làm cơ hội tiến gần tới đơn hàng hay không.
Yêu cầu kỹ thuật của khách hàng phải được giữ lại một cách có tổ chức
Với nhiều doanh nghiệp kỹ thuật, khách hàng hiếm khi gửi ngay một yêu cầu hoàn chỉnh đủ để báo giá. Một dự án có thể bắt đầu bằng bản vẽ, một vài thông số, hình ảnh hiện trường hoặc một mô tả còn thiếu nhiều dữ liệu. Sales phải trao đổi thêm với khách, nhờ kỹ thuật kiểm tra, đôi khi phải khảo sát hiện trường rồi mới xác định được sản phẩm hoặc giải pháp phù hợp.
Nếu tất cả thông tin này chỉ được ghi thành một đoạn note hoặc nằm rải rác trong nhiều file thì rất khó kiểm soát khi yêu cầu thay đổi. Sau vài tháng, người dùng có thể không nhớ con số nào là thông số ban đầu, con số nào đã được khách xác nhận lại và tại sao cuối cùng lại chọn model hiện tại.
CRM không cần biến thành phần mềm thiết kế kỹ thuật, nhưng nên giữ được các thông tin đủ để người khác hiểu câu chuyện. Khách đã yêu cầu gì, dữ liệu nào là dữ liệu cuối cùng, kỹ thuật đã đề xuất phương án nào và phương án đó dựa trên những điều kiện gì. Với doanh nghiệp có nghiệp vụ sâu hơn, phần này còn có thể kết nối với thư viện sản phẩm, công cụ chọn model, tính toán kỹ thuật hoặc BOQ để giảm việc phải nhập lại cùng một thông tin nhiều lần.
Báo giá phải quản lý được từng phiên bản, không chỉ có một file cuối cùng
Doanh nghiệp bán hàng dự án gần như đều gặp chuyện báo giá thay đổi nhiều lần. Ban đầu khách yêu cầu một số lượng, sau đó điều chỉnh phạm vi. Kỹ thuật đổi model vì thông số thay đổi. Sales thương lượng lại chiết khấu. Một vài hạng mục bị cắt ra và một số hạng mục mới lại được thêm vào. Sau vài vòng như vậy, báo giá ban đầu và báo giá cuối cùng có thể khác nhau rất nhiều.
Vì vậy chỉ có nút “Tạo báo giá” chưa đủ. CRM phải giúp người dùng hiểu được báo giá đã thay đổi như thế nào theo thời gian. Phiên bản nào đang có hiệu lực, phiên bản nào đã gửi khách, phiên bản nào mới chỉ dùng nội bộ, ai đã duyệt và phiên bản mới thay đổi gì so với phiên bản trước. Khi khách quay lại hỏi về một mức giá từ sáu tháng trước, sales cần tìm đúng tài liệu thay vì đoán xem file nào là file cũ.
Điều này cũng đặc biệt quan trọng khi thay đổi nhân sự. Người mới nhận dự án không chỉ nhìn thấy một folder chứa năm file báo giá gần giống nhau, mà có thể hiểu rõ quá trình thay đổi từ phiên bản đầu tiên tới phương án cuối cùng. Trong bán hàng dự án, lịch sử báo giá chính là một phần của lịch sử thương lượng.
Dự báo doanh thu phải dựa trên tình hình thật của dự án
Nhiều CRM cho phép sales chọn tỷ lệ thắng cho từng Deal, ví dụ 30%, 50% hoặc 80%, sau đó hệ thống lấy giá trị Deal nhân với tỷ lệ đó để dự báo doanh thu. Cách tính này tiện nhưng với bán hàng dự án, nó rất dễ trở thành một con số cảm tính. Một người có thể đánh 80% vì cảm thấy quan hệ với khách khá tốt, nhưng thực tế dự án còn chưa xác định bên mua hoặc sản phẩm của mình chưa được duyệt về kỹ thuật.
Một dự báo có giá trị hơn nên nhìn vào nhiều tín hiệu thực tế cùng lúc. Dự án đang ở giai đoạn nào, yêu cầu mua hàng đã phát hành chưa, giải pháp kỹ thuật đã được chấp nhận chưa, bên mua cuối cùng đã rõ chưa, báo giá đã qua bao nhiêu vòng, thời gian dự kiến đặt hàng có bị lùi liên tục không và đối thủ đang có lợi thế gì. CRM không nhất thiết phải tự động tính ra một con số “thông minh” tuyệt đối, nhưng ít nhất hệ thống phải đưa những thông tin này lên cùng một chỗ để người quản lý tự đánh giá được chất lượng của cơ hội.
Nhờ đó dashboard không chỉ khoe một pipeline trị giá vài chục tỷ rồi tạo cảm giác doanh thu tương lai rất lớn. Nó giúp tách được những dự án có giá trị cao trên giấy khỏi những dự án thực sự đang tiến gần tới đơn hàng. Với lãnh đạo doanh nghiệp, sự khác biệt này quan trọng hơn rất nhiều so với một biểu đồ đẹp.
Chốt được đơn hàng rồi vẫn phải bàn giao được đúng những gì sales đã bán
Trong bán hàng dự án, trạng thái “Won” chưa phải kết thúc của câu chuyện. Sau khi khách đồng ý mua, thông tin thường được chuyển cho kỹ thuật, dự án, kho, mua hàng hoặc một bộ phận thực hiện khác. Nếu lúc này các bộ phận phía sau vẫn phải hỏi lại sales rằng khách chốt model nào, báo giá phiên bản nào, phạm vi cung cấp đến đâu và có cam kết đặc biệt gì thì dữ liệu trong CRM vẫn chưa hoàn thành nhiệm vụ.
Một CRM phù hợp nên giúp tạo ra một điểm bàn giao rõ ràng. Khi Deal được chốt, hệ thống phải chỉ ra đâu là báo giá cuối cùng, sản phẩm nào được khách xác nhận, những hạng mục nào thuộc phạm vi cung cấp, điều khoản nào cần chú ý và có lời hứa đặc biệt nào với khách hay không. Bộ phận thực hiện có thể tiếp nhận đúng thông tin đã được thống nhất mà không phải ghép lại câu chuyện từ hàng loạt trao đổi cũ.
CRM không cần quản lý toàn bộ quá trình thi công hay triển khai sau bán hàng. Nhưng nó phải đảm bảo những gì sales bán và những gì doanh nghiệp chuẩn bị thực hiện là cùng một phiên bản của sự thật. Đây là một điểm rất nhỏ trên giao diện nhưng có thể tránh được rất nhiều sai sót và tranh cãi trong quá trình thực hiện dự án.
Với bán hàng dự án, vấn đề nằm ở cách phần mềm hiểu dữ liệu chứ không chỉ ở số lượng tính năng
Hai CRM đều có thể quảng cáo rằng mình có khách hàng, Deal, báo giá, Task, file và dashboard. Nhìn danh sách tính năng thì gần như giống nhau, nhưng trải nghiệm khi đưa vào doanh nghiệp bán hàng dự án có thể khác hoàn toàn. Lý do là một hệ thống có thể hiểu mọi thứ chủ yếu dưới dạng khách hàng và Deal, trong khi hệ thống còn lại hiểu được mối quan hệ giữa dự án, các bên tham gia, nhiều cơ hội bán hàng, yêu cầu kỹ thuật, nhiều phiên bản báo giá và quá trình bàn giao sau khi chốt.
Đây cũng là lý do việc chỉ thêm vài trường tùy chỉnh chưa chắc giải quyết được bài toán. Nếu ngay từ đầu phần mềm không có khái niệm Project riêng, doanh nghiệp có thể phải dùng Deal để giả làm Project. Sau đó khi một Project phát sinh ba cơ hội bán hàng, hệ thống lại bắt đầu khó tổ chức. Khi thêm nhiều nhà thầu, nhiều báo giá và nhiều hạng mục, những cách xử lý tạm thời ban đầu dần trở thành giới hạn của chính phần mềm.
Với CRM custom, SYP có thể thiết kế cấu trúc từ đúng cách doanh nghiệp bán hàng thực tế: một dự án gồm những bên nào, doanh nghiệp đang theo những hạng mục nào, ai ảnh hưởng tới quyết định, yêu cầu kỹ thuật thay đổi ra sao, báo giá đã đi qua những phiên bản nào và khi thắng thì thông tin nào cần được bàn giao tiếp. Giao diện hay automation được làm sau đó để phục vụ cấu trúc này, chứ không phải xây trước một CRM chung rồi tìm cách nhét quy trình của doanh nghiệp vào.
CRM cho doanh nghiệp bán hàng dự án phải giúp nhìn được toàn bộ cuộc chơi
Với một công ty bán hàng thông thường, biết khách hàng là ai, Deal bao nhiêu tiền và đang ở stage nào đôi khi đã đủ để quản lý. Nhưng với B2B Project Sales, những câu hỏi quan trọng hơn thường là: dự án thực sự đang ở đâu, những bên nào đang tham gia, ai đang ảnh hưởng tới quyết định, doanh nghiệp mình đang theo những hạng mục nào, giải pháp đã được chấp nhận tới đâu, báo giá hiện tại là phiên bản nào và khả năng biến cơ hội đó thành đơn hàng còn phụ thuộc vào điều gì.
Khi CRM trả lời được những câu hỏi này, hệ thống mới thực sự phù hợp với bán hàng dự án. Nó không chỉ giúp sales ghi lại công việc đã làm mà còn giúp doanh nghiệp hiểu được toàn bộ cấu trúc của một cơ hội kinh doanh dài hạn, từ lúc dự án mới xuất hiện cho tới khi đơn hàng được bàn giao sang giai đoạn thực hiện.
Đó cũng là điểm khác biệt quan trọng của CRM theo yêu cầu trong nhóm doanh nghiệp này. Không phải vì phần mềm custom có nhiều nút hơn, mà vì ngay từ đầu nó có thể được xây để hiểu đúng cách doanh nghiệp thực sự bán hàng.