CRM gần đáp ứng được: nên tùy chỉnh, kết nối công cụ khác hay thay thế?

Bắt đầu từ công việc đang bị vướng

CRM của bạn có thể quản lý liên hệ, cơ hội bán hàng và việc theo dõi rất tốt. Nhưng khi đến lúc gia hạn, một khoản giảm giá cần được phê duyệt và công việc lại chuyển sang email.

Đó là lý do để xem xét tác vụ gia hạn. Chưa thể từ đó kết luận nên đổi một cài đặt, bổ sung tính năng được hỗ trợ, kết nối công cụ khác hay thay CRM.

Trước tiên, hãy quan sát một người hoàn thành tác vụ đó, kể cả những chỗ bất tiện. Ghi lại họ nhập gì, tìm thông tin ở đâu, ai quyết định và mọi người biết công việc đã xong bằng cách nào. Lập danh sách riêng những việc CRM hiện làm tốt. Mọi phương án thay đổi cần giữ được các việc đó.

Một lần gia hạn cần phê duyệt

Xét ví dụ giả định này: nhân viên kinh doanh chuẩn bị đề nghị gia hạn, người quản lý phê duyệt mọi khoản giảm giá, rồi nhân viên gửi đề nghị đã thống nhất cho khách hàng. Hiện nay, nhân viên chép nội dung gia hạn vào email và sau đó nhập lại quyết định vào CRM.

Lời phàn nàn rất rõ: “Chúng tôi cứ phải đi nhắc mọi người duyệt.” Nhưng nguyên nhân cần được xem kỹ hơn.

• CRM đã có thể giao tác vụ phê duyệt nhưng mọi người không tìm thấy hoặc chưa được hướng dẫn sử dụng?
• CRM có thể lưu lần gia hạn và áp dụng đúng quyền truy cập, nhưng cần một phần bổ sung được hỗ trợ cho các bước phê duyệt?
• Quyết định có phụ thuộc vào thông tin trong một hệ thống khác, nơi vẫn nên chịu trách nhiệm về thông tin đó?
• CRM có thể biểu diễn chính xác nhiều hợp đồng và những lần gia hạn riêng của cùng một khách hàng không?

Mỗi câu trả lời dẫn đến một thay đổi khác nhau. Thêm màn hình sẽ không giải quyết được việc mọi người không tìm thấy tác vụ. Kết nối các hệ thống cũng không sửa được lần gia hạn đã được lưu dưới sai loại bản ghi.

Kiểm tra CRM bạn đang dùng thực sự làm được gì

Hãy yêu cầu quản trị viên hoặc nhà cung cấp trình diễn toàn bộ tác vụ trên đúng phiên bản sản phẩm bạn dùng, với đúng quyền mà nhân viên đang có. Bản trình diễn của phiên bản đắt hơn không chứng minh gói thuê bao hiện tại có tính năng đó.

Kiểm tra cấu hình và việc hướng dẫn sử dụng trước. Một trường dữ liệu, cách hiển thị, tác vụ hoặc cài đặt quyền hiện có có thể giải quyết thiếu sót. Hãy để nhân viên và người quản lý thử các bước đã ghi lại. Nếu họ hoàn thành đúng công việc, bước tiếp theo có thể là làm màn hình rõ hơn hoặc đào tạo, thay vì phát triển phần mềm.

Nếu thực sự thiếu một khả năng, hãy tìm cách mở rộng sản phẩm hiện tại mà nhà cung cấp hỗ trợ. Xác định điểm mở rộng nào được hỗ trợ, phiên bản của bạn cho phép gì, ai sẽ bảo trì phần bổ sung và kiểm thử nó sau các lần cập nhật ra sao. Dòng chữ “có thể tùy chỉnh” trên trang bán hàng mới chỉ là điểm bắt đầu để đặt câu hỏi.

Hướng dẫn ứng dụng dựa trên mô hình của Microsoft đưa ra một ví dụ có giới hạn rõ ràng: mô hình hóa dữ liệu, xác định quy trình, xây dựng ứng dụng và cấu hình vai trò bảo mật là những phần việc riêng. Hướng dẫn mô tả nền tảng đó, không chứng minh mọi CRM đều có cùng khả năng kiểm soát.

Viết ra ba phương án có cơ sở

Với tình huống gia hạn giả định, ghi chú ra quyết định có thể nêu ba phương án sau. Mỗi phương án mô tả khi nào nó có thể phù hợp và cần bằng chứng gì trước khi chọn.

Với tình huống giả định này, lựa chọn tạm thời có thể là: “Trước tiên thử khả năng phê duyệt hiện có của CRM. Chúng ta chưa xác định phiên bản này có hỗ trợ quyền cần thiết và lịch sử gia hạn hay không. Tiếp tục nếu thử nghiệm xác nhận cả hai; đánh giá phần mở rộng hoặc kết nối nếu thiếu một khả năng cụ thể. Tìm hiểu phương án thay thế nếu hệ thống không thể chứa các bản ghi hợp đồng và gia hạn thiết yếu.”

Khi nào một kết nối là hợp lý

Nên cân nhắc kết nối khi mỗi hệ thống có nhiệm vụ rõ ràng. Trong ví dụ gia hạn, một dịch vụ riêng có thể đang giữ các điều khoản hợp đồng cần cho việc phê duyệt. Đưa thông tin liên quan đến nơi ra quyết định có thể hợp lý hơn việc sao chép toàn bộ công việc của dịch vụ đó vào CRM.

Nhưng trước hết phải thống nhất ý nghĩa của thông tin. “Đã duyệt” nghĩa là người quản lý đồng ý mức giảm giá đề xuất, hay khách hàng đã chấp nhận gia hạn? Ai được thay đổi trạng thái đó? Nếu nội dung gia hạn đổi sau khi duyệt thì sao?

Hướng dẫn của Microsoft về việc chuyển đổi ý nghĩa giữa các hệ thống giải thích rằng những hệ thống khác nhau có thể hiểu khác nhau cùng một khái niệm kinh doanh. Tài liệu cũng chỉ ra công việc bổ sung để duy trì sự chuyển đổi đó. Bạn không cần chọn đúng kiến trúc nêu trong tài liệu để hỏi điều quan trọng: ai sẽ giữ cho các ý nghĩa này nhất quán?

Trước khi chọn công cụ riêng, hãy chứng minh kết nối cần thiết được hỗ trợ trong đúng sản phẩm và phiên bản liên quan. Sau đó quyết định ai xử lý những lần cập nhật thất bại. Một gói thuê bao thứ hai và một bộ kết nối vẫn cần người chịu trách nhiệm.

Khi cấu trúc cơ bản của CRM là vấn đề

Điểm không phù hợp cốt lõi là sản phẩm không thể biểu diễn đầy đủ những đối tượng doanh nghiệp cần quản lý hoặc các quy tắc áp dụng cho chúng.

Ví dụ, một khách hàng có thể có nhiều hợp đồng, mỗi hợp đồng có lần gia hạn, phê duyệt và lịch sử riêng. Nếu phương án đề xuất cứ ghi đè một “ngày gia hạn” trong hồ sơ khách hàng, hãy hỏi những lần gia hạn khác sẽ được giữ thế nào. Kiểm tra sản phẩm có hỗ trợ các bản ghi liên quan cần thiết hay không trước khi kết luận phải thay thế.

Nếu có, một phần mở rộng được hỗ trợ có thể hợp lý. Nếu không, nhiều cách xử lý tạm bợ nối tiếp nhau có thể vẫn để nguyên vấn đề thiết yếu. Đó là bằng chứng mạnh hơn cho việc thay thế so với cảm giác khó chịu chung về một màn hình.

Thay thế cũng kéo theo công việc: chuyển bản ghi và tệp đính kèm, giữ lịch sử hữu ích, thiết lập quyền, xây dựng lại các kết nối cần thiết và giúp mọi người làm việc trên hệ thống mới. Hãy yêu cầu trình diễn tác vụ gia hạn khó đó trên hệ thống mới trước khi xem một bản demo bán hàng trau chuốt là bằng chứng phù hợp.

So sánh cả công việc sau khi đưa vào sử dụng

Đặt cùng câu hỏi cho cả ba phương án: ai có thể đề nghị và phê duyệt gia hạn, ai bảo trì giải pháp, điều gì xảy ra sau bản cập nhật của nhà cung cấp và còn những chi phí liên tục nào?

Tính đến gói thuê bao và phiên bản cần có, cấu hình hoặc phát triển, đào tạo nhân viên, hỗ trợ, bảo trì kết nối và công việc khi rời hệ thống về sau, nếu có liên quan. Dùng điều khoản và ước tính thực tế cho tác vụ này. Một phần mở rộng nhỏ vẫn có trách nhiệm duy trì; việc thay thế có thể phát sinh nhiều công việc hơn hẳn tính năng gây ra vấn đề ban đầu.

Hướng dẫn mua sắm công nghệ của chính phủ Anh xem xét việc điều chỉnh sản phẩm hiện có và xây dựng phần mềm cùng với nhu cầu, năng lực và việc quản lý nhà cung cấp lâu dài. Đó là khung so sánh hữu ích, không phải câu trả lời chung cho mọi quyết định CRM thương mại.

Thử thay đổi nhỏ nhất nhưng có cơ sở

Chọn phương án nhỏ nhất thực sự có thể giải quyết thiếu sót đã xác định. Dùng bản ghi giả nhưng có tính đại diện trong môi trường thử nghiệm được hỗ trợ. Không để thử nghiệm tác động đến các lần gia hạn thật, tin nhắn khách hàng hay cập nhật trên hệ thống đang vận hành; giữ quy trình hiện tại cho đến khi thử nghiệm đủ cơ sở để triển khai rộng hơn.

Với ví dụ gia hạn, hãy thử một lần duyệt thông thường, một lần từ chối, một đề nghị đã sửa cần được duyệt lại và thao tác của người không có quyền phê duyệt. Nếu có hệ thống khác tham gia, hãy thử cả việc cập nhật bị thiếu và cách khôi phục. Quyết định trước cách dừng thử nghiệm, xóa bản ghi và cài đặt thử, đồng thời lưu lại kết quả. Đừng dựa vào khả năng đảo ngược một quyết định thật của khách hàng.

Kết quả hữu ích cần cụ thể: nhân viên thấy việc cần xử lý, đúng người quản lý ra quyết định và bản ghi gia hạn lưu quyết định cùng bối cảnh của nó. Ghi lại các bước còn làm thủ công và giao người phụ trách từng bước. Sau đó cập nhật ghi chú ra quyết định bằng những gì thử nghiệm cho thấy.

Chúng tôi cung cấp phần mềm tùy chỉnh và dịch vụ tích hợp API. Nếu muốn được hỗ trợ đánh giá chỗ thiếu của CRM, hãy mang theo tác vụ gây khó khăn, một bản ghi ví dụ và những phần của hệ thống hiện tại bạn muốn giữ. Phạm vi, giấy phép, bàn giao và việc chăm sóc lâu dài được thỏa thuận cho từng công việc cụ thể.

Câu hỏi trước khi thay đổi CRM