Ứng dụng tiếp nhận cho công ty dịch vụ chuyên nghiệp: kế hoạch thực tế

Vì sao thông tin tiếp nhận rời rạc gây ra những chậm trễ không đáng có

Một yêu cầu từ khách hàng mới thường bắt đầu bằng email, rồi lan sang các thư chuyển tiếp, ghi chú cuộc gọi và một bảng tính được cập nhật sau đó. Tên công ty nằm ở một nơi, phạm vi dự án ở nơi khác, còn thời hạn đã hứa thì bị chôn trong hộp thư. Nhân viên phải hỏi lại những thông tin mà khách hàng đã cung cấp cho một người khác.

Những khoảng trống nhỏ đó nhanh chóng cộng dồn. Đối tác không thể đánh giá mức độ phù hợp nếu thiếu bản tóm tắt rõ ràng. Bộ phận vận hành không thể phân công công việc nếu chưa biết thời điểm bắt đầu dự kiến. Một người nghĩ rằng đồng nghiệp sẽ theo dõi, trong khi đồng nghiệp lại cho rằng yêu cầu vẫn đang được xem xét.

Kiểm tra xung đột tiềm ẩn rủi ro lớn hơn. Trước khi bắt đầu công việc chuyên môn hoặc đưa ra cam kết, công ty cần xem xét khách hàng, các bên liên quan, bên đối lập và những thông tin quan trọng của vụ việc. Khi các dữ liệu này nằm rải rác trong nhiều tin nhắn, người kiểm tra có thể chỉ thấy một phần bức tranh. Một lần kiểm tra vội vàng có thể bỏ sót mối quan hệ ảnh hưởng đến khả năng nhận hợp đồng của công ty.

Ứng dụng tiếp nhận cho các công ty dịch vụ chuyên nghiệp đưa những thông tin cần thiết vào cùng một bản ghi dùng chung ngay từ yêu cầu đầu tiên. Mỗi yêu cầu có trạng thái rõ ràng, chẳng hạn như Mới, Đang chờ kiểm tra xung đột, Đã phê duyệt hoặc Đã phân công. Đội ngũ nhìn thấy thông tin hiện tại thay vì phải dựng lại câu chuyện từ các email.

Mỗi bước tiếp theo cũng cần có người phụ trách. Điều phối viên phát triển kinh doanh có thể thu thập thông tin còn thiếu, người kiểm tra được chỉ định có thể hoàn tất việc kiểm tra xung đột, còn trưởng bộ phận có thể quyết định có tiếp tục hay không. Việc phân công rõ ràng giúp một yêu cầu đầy tiềm năng không bị bỏ quên nhiều ngày chỉ vì không ai biết ai cần hành động.

Một quy trình tiếp nhận khách hàng tốt phải đơn giản. Quy trình đó thu thập đủ bối cảnh để đưa ra quyết định đúng đắn, chuyển yêu cầu đến đúng người và lưu lại lịch sử ngắn gọn về những gì đã xảy ra. Khi công ty nhận công việc, cùng một bản ghi có thể được chuyển cho đội ngũ triển khai cùng với phạm vi đã duyệt, thông tin liên hệ, khoảng ngân sách và các cam kết còn nguyên vẹn.

Bản ghi dùng chung thay thế việc lần tìm thông tin bằng một quy trình bàn giao có thể lặp lại. Quản lý cũng có thể xem các yêu cầu đang mở, từng yêu cầu đang chờ ở đâu và ai cần hành động.

Xác định những người và quyết định liên quan

Mỗi yêu cầu cần có một lộ trình rõ ràng trong công ty. Trước khi xây dựng các trường hoặc màn hình, hãy xác định ai sẽ xử lý yêu cầu và mỗi người đưa ra quyết định gì. Cách này tránh được vấn đề quen thuộc của hộp thư chung, khi ai cũng nghĩ người khác sẽ phản hồi.

Hầu hết công ty cần bốn vai trò: người gửi yêu cầu, người kiểm tra xem công ty có thể nhận việc hay không, người phê duyệt công việc và người thực hiện. Ở công ty nhỏ, một người có thể đảm nhiệm nhiều vai trò. Tuy vậy, ứng dụng vẫn nên ghi nhận từng quyết định riêng biệt.

Một khách hàng tiềm năng có thể gửi biểu mẫu tiếp nhận dự án sau khi trao đổi với chuyên gia tư vấn. Điều phối viên tiếp nhận kiểm tra xem yêu cầu đã đủ chi tiết chưa. Người kiểm tra xung đột xem xét tên và các bên liên quan. Trưởng bộ phận quyết định có nên tiếp tục hay không. Sau đó, chuyên gia tư vấn được phân công nhận yêu cầu đã duyệt, hành động tiếp theo và thời hạn.

Tách câu hỏi dành cho khách hàng khỏi ghi chú nội bộ

Khách hàng chỉ nên thấy những câu hỏi mà họ có thể trả lời: tên công ty, mục tiêu dự án, thời hạn, thông tin liên hệ và khoảng ngân sách dự kiến. Hãy giữ các trường nội bộ bên ngoài biểu mẫu dành cho khách hàng. Những trường này có thể gồm ghi chú rủi ro, nhận xét về năng lực, hướng dẫn phí, thông tin xung đột và quyết định của công ty.

Cách này bảo vệ thông tin nhạy cảm và giúp biểu mẫu bớt nặng nề. Khách hàng không cần hiểu quy trình kiểm tra xung đột của công ty để bắt đầu trao đổi.

Hãy thiết lập quyền xem trước khi xây dựng quy trình:

• Người gửi có thể tạo yêu cầu và xem trạng thái các yêu cầu của chính mình.
• Nhân viên tiếp nhận có thể sửa thông tin, yêu cầu bổ sung dữ liệu và chuyển yêu cầu đến nơi phù hợp.
• Người kiểm tra xung đột có thể xem tên các bên và thêm ghi chú nội bộ.
• Trưởng bộ phận có thể xem ngân sách, thông tin năng lực và các quyết định phê duyệt.
• Đội ngũ triển khai có thể xem công việc đã duyệt và những thông tin cần thiết để bắt đầu.

Quy tắc truy cập cần phản ánh cách công ty xử lý các vấn đề bảo mật. Người kiểm tra có thể cần tên khách hàng và bên đối tác nhưng không cần biết mức phí đề xuất. Đội ngũ triển khai có thể cần phạm vi công việc đã ký nhưng không cần xem ghi chú xung đột.

Giao một người phụ trách cho từng giai đoạn

Hãy chỉ định một người phụ trách cho mỗi giai đoạn, ngay cả khi nhiều người có thể hỗ trợ. Người phụ trách nhận lời nhắc và phải đưa yêu cầu tiến lên, trả lại để bổ sung thông tin hoặc đóng yêu cầu. Việc phân công chung thường khiến công việc bị bỏ ngỏ.

Một quy trình đơn giản có thể giao cho điều phối viên tiếp nhận việc kiểm tra tính đầy đủ, đội ngũ kiểm tra xung đột việc xem xét, trưởng bộ phận việc phê duyệt và quản lý dự án việc bàn giao. Hãy ghi lại cả giai đoạn hiện tại lẫn tên người phụ trách trong yêu cầu.

AppMaster có thể mô hình hóa trực quan vai trò, quyền hạn và các bước bàn giao, giúp đội ngũ xây dựng quy trình tiếp nhận khách hàng dựa trên những quyết định thực tế thay vì một biểu mẫu chung chung.

Chọn thông tin về bối cảnh dự án cần thu thập

Một ứng dụng tiếp nhận hữu ích bắt đầu bằng bức tranh rõ ràng về yêu cầu. Biểu mẫu cần cung cấp đủ chi tiết để đội ngũ quyết định ai cần xem xét, mức độ khẩn cấp và bước tiếp theo. Không nên yêu cầu khách hàng tiềm năng chuẩn bị một bản mô tả đầy đủ trước khi công ty đồng ý hỗ trợ.

Hãy bắt đầu với các trường nhận diện công việc: tổ chức khách hàng, tên dự án và dịch vụ được yêu cầu. Tên công ty rất quan trọng, ngay cả khi chỉ một người gửi yêu cầu, vì nó giúp đội ngũ kết nối các yêu cầu liên quan và bắt đầu quy trình kiểm tra xung đột. Cung cấp một danh sách ngắn các loại dịch vụ, kèm tùy chọn «Khác» cho những công việc không phù hợp với danh sách.

Hãy yêu cầu mô tả vấn đề bằng ngôn ngữ đơn giản. Câu hỏi như «Bạn cần hỗ trợ điều gì và mong muốn đạt được kết quả nào?» thường cho câu trả lời tốt hơn một ô lớn có nhãn «Chi tiết dự án». Câu trả lời có thể cho thấy thời điểm triển khai gấp, vấn đề pháp lý hoặc công việc trải rộng trên nhiều khu vực.

Thu thập sớm thời gian và phạm vi

Ngày tháng ảnh hưởng đến việc bố trí nhân sự và thứ tự ưu tiên phản hồi. Hãy thu thập ngày bắt đầu mong muốn, thời hạn bắt buộc nếu có và một lựa chọn đơn giản về mức độ khẩn cấp. Tránh những lựa chọn mơ hồ như «Càng sớm càng tốt». Hãy dùng các lựa chọn có thể được hiểu thống nhất, chẳng hạn «trong vòng 48 giờ», «trong tuần này» hoặc «không có thời hạn cố định».

Địa điểm có thể ảnh hưởng đến đội ngũ được phân công, nhu cầu đi lại, quy định áp dụng hoặc hình thức bàn giao. Hãy hỏi địa điểm dự án khi thông tin này quan trọng. Sau đó, thu thập các kết quả cần bàn giao bằng cách diễn đạt đơn giản: ý kiến bằng văn bản, hội thảo, hồ sơ, kế hoạch triển khai, hỗ trợ liên tục hoặc một đầu ra khác đã thống nhất.

Một biểu mẫu tiếp nhận dự án thực tế thường gồm:

• Tổ chức khách hàng và tên dự án
• Dịch vụ được yêu cầu và phần tóm tắt ngắn
• Ngày bắt đầu mong muốn, thời hạn và mức độ khẩn cấp
• Địa điểm hoặc khu vực pháp lý liên quan
• Kết quả cần bàn giao và các ràng buộc đã biết

Giữ số trường bắt buộc ở mức tối thiểu

Mỗi trường bắt buộc đều tạo thêm trở ngại. Chỉ bắt buộc một trường khi đội ngũ không thể chuyển hoặc đánh giá yêu cầu nếu thiếu trường đó. Tổ chức khách hàng, dịch vụ được yêu cầu, phần tóm tắt và phương thức liên hệ thường đáp ứng tiêu chí này. Phạm vi chi tiết, tài liệu, ngân sách và mã tham chiếu nội bộ thường thì không.

Một khách hàng tiềm năng có thể biết họ cần hỗ trợ về tranh chấp lao động nhưng chưa biết kết quả bàn giao hoặc thời hạn chính xác. Hãy cho phép họ gửi những thông tin cơ bản. Người phụ trách tiếp nhận có thể thu thập phần còn thiếu qua một lần trao đổi ngắn thay vì để mất yêu cầu vì biểu mẫu quá nghiêm ngặt.

Với AppMaster, đội ngũ có thể dùng các trường có điều kiện. Ứng dụng chỉ hỏi về địa điểm khi thông tin này ảnh hưởng đến dịch vụ đã chọn, hoặc hỏi lý do thời hạn gấp khi người gửi đánh dấu yêu cầu là khẩn cấp. Biểu mẫu vẫn ngắn gọn trong khi người xem xét nhận được bối cảnh cần thiết.

Giữ thông tin liên hệ khách hàng gắn với yêu cầu

Một yêu cầu hiếm khi chỉ đến từ một người. Email đầu tiên có thể do quản lý vận hành gửi, trong khi giám đốc tài chính phê duyệt công việc và trưởng bộ phận đưa ra quyết định cuối cùng. Hãy giữ những người này gắn với cùng một yêu cầu thay vì để thông tin nằm rải rác trong hộp thư và ghi chú.

Hãy bắt đầu với một người liên hệ chính. Thu thập họ tên đầy đủ, email công việc, số điện thoại, chức danh và phương thức liên hệ ưu tiên. Nhân viên nên nhìn thấy các thông tin này ở đầu bản ghi yêu cầu thay vì phải tìm lại tin nhắn cũ trước khi gọi.

Ghi nhận vai trò của từng người

Cho phép nhân viên thêm người liên hệ khi cuộc trao đổi phát triển. Mỗi người liên hệ cần được kết nối với cả tổ chức và yêu cầu dự án.

Các nhãn hữu ích gồm:

• Người liên hệ chính hoặc điều phối viên hằng ngày
• Người quyết định về phạm vi hoặc thời gian
• Người liên hệ về thanh toán
• Người liên hệ kỹ thuật về quyền truy cập hoặc yêu cầu
• Người liên hệ pháp lý hoặc mua sắm về hợp đồng

Các nhãn này ngăn những lỗi bàn giao phổ biến, chẳng hạn gửi đề xuất cho người không có quyền phê duyệt hoặc gửi hóa đơn cho người chỉ yêu cầu một cuộc họp. Một người có thể giữ nhiều vai trò, vì vậy hãy cho phép dùng nhiều nhãn khi cần.

Ví dụ, Maya, giám đốc vận hành, có thể mô tả dự án, đồng thời cho biết giám đốc tài chính là người phê duyệt ngân sách và quản lý IT là người trả lời các câu hỏi về hệ thống. Ghi nhận cả ba người trong cùng một yêu cầu giúp bộ phận tài chính và trưởng dự án có đúng người liên hệ khi công việc bắt đầu.

Kiểm tra tổ chức trước khi tạo mới

Yêu cầu nhân viên tìm kiếm tổ chức trước khi tạo bản ghi mới. Hãy đối chiếu theo tên công ty, miền email và, nếu có, số điện thoại. Cách này phát hiện những khác biệt nhỏ như «Acme Ltd» và «Acme Limited», vốn có thể tách một khách hàng thành hai bản ghi.

Nếu tổ chức đã tồn tại, hãy gắn yêu cầu mới vào đó và xác nhận thông tin liên hệ vẫn còn chính xác. Nếu chưa tồn tại, hãy tạo tổ chức một lần và lưu lại nguồn của yêu cầu. Cách này giúp quy trình tiếp nhận khách hàng gọn gàng hơn, đồng thời giúp tìm lại công việc trước đây, các yêu cầu đang mở và lịch sử liên hệ dễ dàng hơn.

Data Designer của AppMaster có thể mô hình hóa tổ chức, người liên hệ và yêu cầu thành các bản ghi liên kết. Nhân viên có thể dùng biểu mẫu web hoặc di động để thêm người liên hệ mà không làm mất mối liên hệ với yêu cầu ban đầu.

Xây dựng quy trình kiểm tra xung đột dễ thực hiện

Kiểm tra xung đột cần nhiều hơn một ô văn bản và một chuỗi email. Ứng dụng tiếp nhận cần thu thập những tên giúp người kiểm tra có đủ bối cảnh để đối chiếu yêu cầu mới với công việc hiện tại và trước đây.

Hãy hỏi về khách hàng tiềm năng, các tổ chức liên quan, người liên hệ chính, bên đối lập nếu đã biết và tên vụ việc hoặc dự án. Thêm một trường văn bản ngắn cho các mối quan hệ bất thường, chẳng hạn công ty mẹ, cựu lãnh đạo hoặc liên doanh.

Hãy tách thông tin xung đột khỏi dữ liệu tiếp nhận chung. Bản ghi xung đột cần được bảo vệ chặt chẽ hơn mô tả dự án hoặc khoảng ngân sách. Chỉ những người thực hiện kiểm tra và đưa ra quyết định xác nhận mới được truy cập.

Làm cho trạng thái kiểm tra dễ nhận biết

Mỗi yêu cầu cần có một trạng thái hiển thị rõ ràng và thay đổi theo tiến trình kiểm tra. Tránh các nhãn như «Đang xem xét» khi nhân viên cần biết ai phải hành động tiếp theo.

• Chờ kiểm tra: yêu cầu đã có đủ thông tin để người kiểm tra bắt đầu.
• Đã xác nhận: người kiểm tra không tìm thấy xung đột nào ngăn cản công việc.
• Cần bổ sung: người kiểm tra cần thêm thông tin hoặc phê duyệt.
• Bị chặn: công ty không thể nhận yêu cầu theo quy định về xung đột.

Người gửi không cần truy cập các kết quả tìm kiếm nhạy cảm. Họ cần biết yêu cầu có thể tiếp tục, cần bổ sung thông tin hay phải dừng lại. Ứng dụng có thể hiển thị trạng thái đơn giản cho khách hàng trong khi hạn chế quyền xem ghi chú nội bộ.

Lưu lại quyết định ngắn gọn

Mỗi quyết định cần tạo một bản ghi lâu dài gồm tên người kiểm tra, ngày, trạng thái và lý do diễn đạt bằng ngôn ngữ đơn giản. Ví dụ: «Đã xác nhận ngày 14 tháng 5 bởi J. Patel. Công việc hiện có với một công ty liên kết đã kết thúc vào năm 2022; không tìm thấy vụ việc bất lợi nào đang diễn ra.»

Điều này tiết kiệm thời gian khi trưởng dự án hỏi vì sao quy trình tiếp nhận bị tạm dừng hoặc khi người kiểm tra khác tiếp quản. Lý do nên ngắn gọn và thực tế. Việc kiểm tra xung đột cần giải thích quyết định, không nên trở thành một hồ sơ vụ việc thứ hai.

Hãy làm rõ một quy tắc trong quy trình: nhân viên không được phân công công việc triển khai, mở không gian làm việc cho khách hàng hoặc bắt đầu công việc tính phí cho đến khi trạng thái là Đã xác nhận. Nếu người kiểm tra chọn Cần bổ sung, ứng dụng nên trả lại yêu cầu cùng một câu hỏi cụ thể, chẳng hạn yêu cầu cung cấp pháp nhân đứng sau một tên thương hiệu.

AppMaster có thể hỗ trợ việc này bằng bảng xung đột bị giới hạn quyền truy cập, quyền theo vai trò và Business Process Editor trực quan để chuyển từng yêu cầu tiếp nhận đến đúng người kiểm tra.

Hỏi về ngân sách mà không biến quy trình tiếp nhận thành báo giá

Câu hỏi về ngân sách giúp nhân viên đánh giá yêu cầu có phù hợp với loại công việc công ty thường nhận hay không. Câu hỏi này không nên hứa hẹn một mức giá. Ở giai đoạn đầu, thông tin tiếp nhận hiếm khi đủ để ước tính số giờ, thay đổi phạm vi, hỗ trợ chuyên gia hoặc áp lực thời hạn.

Hãy dùng các khoảng phù hợp với những hợp đồng công ty nhận. Một công ty tư vấn có thể đưa ra các lựa chọn «dưới 10.000 USD», «10.000 đến 25.000 USD», «25.000 đến 75.000 USD» và «trên 75.000 USD». Các lựa chọn nên đủ rộng để khách hàng trả lời nhanh.

Thêm một ghi chú ngắn bên cạnh trường này: «Khoảng ngân sách giúp chúng tôi chuyển yêu cầu đến đúng nơi. Đây không phải báo giá hay thỏa thuận phí.» Khách hàng có thể cho biết mức ngân sách phù hợp, còn công ty vẫn có thể đánh giá công việc đầy đủ.

Khi các khoản chi bên ngoài thường ảnh hưởng đến công việc, hãy hỏi xem ngân sách chỉ bao gồm phí của công ty hay cả chi phí bên ngoài. Những chi phí này có thể gồm phí nộp hồ sơ, đi lại, chuyên gia hợp đồng, phần mềm hoặc nhà cung cấp khác.

Hãy thu thập khoảng ngân sách ước tính, loại tiền tệ khi cần, trạng thái phê duyệt ngân sách và ghi chú về giới hạn hoặc quy định mua sắm. Nhân viên cũng cần cách đánh dấu những yêu cầu cần ước tính chi tiết. Chẳng hạn, điều phối viên tiếp nhận có thể chọn «Cần ước tính» khi khách hàng tiềm năng chọn khoảng cao nhất nhưng mô tả một dự án rộng và chưa xác định rõ.

Giữ câu trả lời ban đầu về ngân sách trong quy trình tiếp nhận khách hàng, nhưng lưu đề xuất cuối cùng trong một bản ghi riêng. Câu trả lời khi tiếp nhận phản ánh ý định ban đầu. Đề xuất ghi lại phạm vi đã thống nhất, các giả định, mức phí, chi phí và phê duyệt. Trộn hai loại thông tin này sẽ gây nhầm lẫn khi phạm vi thay đổi sau cuộc gọi đầu tiên.

Thiết lập quy trình tiếp nhận từng bước

Một ứng dụng tiếp nhận rõ ràng nên đưa mọi yêu cầu đi qua cùng một nhóm nhỏ các quyết định. Nhân viên cần thấy ai phụ trách yêu cầu, nội dung nào cần kiểm tra và khi nào phải hành động.

Bắt đầu bằng một bản ghi yêu cầu

Tạo một bản ghi cho mỗi cơ hội hợp tác. Bản ghi gồm mã tham chiếu, tên khách hàng hoặc tổ chức, dịch vụ được yêu cầu và người gửi. Đặt trạng thái đầu tiên là «Mới» để đội ngũ phân biệt công việc chưa được xem xét với các yêu cầu đang xử lý.

Hãy dùng các trạng thái mô tả những điểm ra quyết định thực tế:

• Mới: công ty đã nhận yêu cầu nhưng chưa ai xem xét.
• Đang xem xét: có người đang kiểm tra phạm vi, thông tin liên hệ và xung đột.
• Chờ khách hàng: đội ngũ cần thông tin còn thiếu.
• Đã phê duyệt: công ty có thể chuẩn bị đề xuất hoặc mở dự án.
• Từ chối: công ty sẽ không nhận công việc.

Giữ danh sách trạng thái ngắn gọn. Nếu nhân viên không thể chọn trạng thái trong vài giây, các nhãn cần được xem lại.

Chuyển, phân công và thông báo

Sau khi có người tạo yêu cầu, hãy chuyển yêu cầu dựa trên thông tin đã thu thập. Yêu cầu về thuế có thể được chuyển đến quản lý thuế, trong khi vấn đề lao động được chuyển đến một người kiểm tra khác. Công ty có nhiều văn phòng cũng có thể chuyển yêu cầu theo địa điểm.

Giao cho người kiểm tra một thời hạn và chỉ định một người cụ thể làm chủ sở hữu bước tiếp theo. Hộp thư chung giúp mọi người dễ theo dõi hơn, nhưng không tạo ra trách nhiệm.

Thông báo luôn cần hướng đến một hành động, chẳng hạn «Hoàn tất kiểm tra xung đột» hoặc «Yêu cầu bổ sung thông tin ngân sách». Hãy thông báo cho người kiểm tra khi có phân công mới, sau đó thông báo cho điều phối viên tiếp nhận nếu thời hạn đã quá.

Bàn giao công việc đã duyệt sang quy trình tiếp theo

Khi công ty phê duyệt yêu cầu, hãy giữ nguyên thông tin đã thu thập. Danh sách người liên hệ, tóm tắt dự án, khoảng ngân sách và ghi chú kiểm tra nên được chuyển vào bản ghi đề xuất hoặc dự án đang hoạt động. Nhân viên không nên nhập lại những thông tin giống nhau trong biểu mẫu khác.

Một nền tảng no-code như AppMaster có thể tạo quy trình này bằng biểu mẫu yêu cầu, trường trạng thái, quy tắc nghiệp vụ và màn hình theo vai trò. Bước bàn giao có thể tự động tạo bản ghi đề xuất và giao người phụ trách, trong khi bản ghi tiếp nhận ban đầu vẫn lưu lịch sử phê duyệt.

Hãy kiểm thử quy trình bằng những yêu cầu thực tế trước khi chia sẻ với khách hàng. Bao gồm một yêu cầu thiếu thông tin, một yêu cầu có khả năng xung đột và một yêu cầu được phê duyệt. Các trường hợp này sẽ cho thấy trạng thái chưa rõ ràng, quy tắc chuyển chưa đầy đủ và thông báo gửi nhầm người.

Ví dụ: từ liên hệ đầu tiên đến bàn giao

Một công ty tư vấn nhận được email từ Maya Chen, giám đốc vận hành tại Northline Foods. Công ty của cô đang lên kế hoạch mở rộng khu vực và muốn được hỗ trợ đánh giá thị trường mới, nhà cung cấp và chi phí vận hành. Thay vì chuyển tiếp email qua nhiều người, điều phối viên mở một bản ghi tiếp nhận duy nhất.

Điều phối viên thêm Maya làm người liên hệ chính, sau đó thêm quản lý tài chính của Northline, người sẽ phê duyệt chi tiêu, cùng quản lý dự án, người xử lý các câu hỏi hằng ngày. Biểu mẫu tiếp nhận ghi lại khu vực mở rộng, mục tiêu kinh doanh, ngày triển khai dự kiến và các ràng buộc ban đầu. Maya nhập ngày 30 tháng 9 là thời hạn mục tiêu, đưa ra khoảng ngân sách dự kiến từ 75.000 đến 100.000 USD và ghi chú rằng công ty cần trình bày đề xuất ban đầu trong vòng bốn tuần.

Trước khi bất kỳ ai lên lịch cuộc gọi khám phá, ứng dụng gửi yêu cầu đến người kiểm tra xung đột. Người kiểm tra xem xét các công việc hiện tại và gần đây liên quan đến các nhà phân phối thực phẩm cạnh tranh, nhà cung cấp và dự án thâm nhập thị trường trong cùng khu vực. Họ ghi lại kết quả và mọi giới hạn đối với công việc trong bản ghi tiếp nhận.

Nếu người kiểm tra xác nhận yêu cầu, điều phối viên chuyển yêu cầu sang «Sẵn sàng khám phá». Nếu người kiểm tra cần ý kiến pháp lý hoặc lãnh đạo, yêu cầu vẫn ở trạng thái xem xét phù hợp và đội ngũ có thể thấy lý do cuộc gọi chưa được đặt lịch. Cách này ngăn cuộc trao đổi bán hàng diễn ra trước quy trình kiểm tra xung đột.

Sau đó, điều phối viên phân công một trưởng bộ phận có kinh nghiệm trong lĩnh vực bán lẻ và mở rộng chuỗi cung ứng. Người này nhận toàn bộ yêu cầu, gồm thông tin liên hệ khách hàng, kết quả mong muốn, thời hạn, khoảng ngân sách và quyết định về xung đột. Sau cuộc gọi khám phá, trưởng bộ phận cập nhật ghi chú về phạm vi và quyết định lập đề xuất trong cùng bản ghi.

Ứng dụng được xây dựng với AppMaster có thể giữ biểu mẫu, trạng thái kiểm tra, phân công và công việc theo dõi trong một ứng dụng no-code, thay vì chia nhỏ chúng giữa các chuỗi email và bảng tính.

Những lỗi tiếp nhận phổ biến cần tránh

Ứng dụng tiếp nhận nên giúp lần xem xét đầu tiên dễ dàng hơn, không tạo thêm một công việc thứ hai. Hầu hết vấn đề bắt nguồn từ câu hỏi mơ hồ, quyền quyết định không rõ hoặc những yêu cầu biến mất sau khi được gửi.

Hỏi quá nhiều ngay từ đầu

Các trường văn bản tự do dài khiến việc xem xét chậm và không đồng đều. Khi nhân viên cần biết loại dịch vụ, mức độ khẩn cấp, ngành nghề hoặc ngày bắt đầu dự kiến, hãy cung cấp danh sách lựa chọn ngắn nếu có thể. Giữ một trường ghi chú tùy chọn cho những chi tiết không phù hợp với các lựa chọn có sẵn.

Danh mục dịch vụ, loại vụ việc, thời hạn, khoảng ngân sách và phần tóm tắt ngắn tạo điểm bắt đầu rõ ràng hơn một câu hỏi chung chung. Quy trình tiếp nhận khách hàng có thể thu thập chi tiết bổ sung sau khi công ty biết yêu cầu phù hợp.

Để các quyết định không có người phụ trách

Mỗi yêu cầu mới cần có một người cụ thể chịu trách nhiệm xem xét, đưa yêu cầu tiến lên hoặc giải thích vì sao công ty không nhận. Ứng dụng nên hiển thị tên người đó và trạng thái hiện tại.

Các quyết định về xung đột cần được kiểm soát chặt chẽ hơn. Thành viên đội ngũ có thể đánh dấu xung đột tiềm ẩn và thêm người liên hệ liên quan, nhưng chỉ người kiểm tra được ủy quyền mới có thể xác nhận, từ chối hoặc yêu cầu thêm thông tin. Hãy ghi lại quyết định, người kiểm tra, ngày và ghi chú.

Đừng xem biểu mẫu tiếp nhận dự án đã gửi là một hợp đồng được phê duyệt. Gửi biểu mẫu chỉ có nghĩa công ty đã nhận thông tin. Phê duyệt cần một thay đổi trạng thái riêng sau khi kiểm tra xung đột, trao đổi về phạm vi và hoàn tất các bước kiểm tra nội bộ cần thiết.

Giữ mãi những câu hỏi cũ

Biểu mẫu thường dài thêm vì mọi câu hỏi mới đều có vẻ hợp lý. Sau vài tháng, biểu mẫu trở nên quá dài và mọi người bắt đầu bỏ qua các trường hoặc nhập câu trả lời vội vàng. Hãy thường xuyên xem lại các trường cùng những người đánh giá yêu cầu và những người sử dụng dữ liệu sau khi bàn giao.

Xóa những câu hỏi không giúp đưa ra quyết định, chuyển công việc, kiểm tra xung đột hoặc chuẩn bị đề xuất. Nếu một trường chỉ áp dụng cho một lĩnh vực, chỉ hiển thị trường đó khi người gửi chọn lĩnh vực tương ứng. AppMaster hỗ trợ các quy trình có điều kiện để giữ màn hình đơn giản cho những người khác.

Một biểu mẫu ngắn với trách nhiệm rõ ràng tạo ra thông tin tốt hơn một biểu mẫu chi tiết mà mọi người phải điền vội.

Kiểm tra nhanh trước khi ra mắt

Trước khi chia sẻ ứng dụng tiếp nhận trong toàn công ty, hãy xác nhận biểu mẫu thu thập đủ bối cảnh cho lần xem xét đầu tiên: nhu cầu của khách hàng, lĩnh vực dịch vụ, địa điểm hoặc khu vực pháp lý liên quan, thời gian, khoảng ngân sách và thông tin người liên hệ chính.

Hãy mở một yêu cầu thử nghiệm và theo dõi yêu cầu đó như một người kiểm tra. Quy trình kiểm tra xung đột cần có trạng thái rõ ràng, người kiểm tra cụ thể và quyết định được lưu lại. Mỗi yêu cầu cũng cần một người phụ trách hiện tại và một thời hạn. Người phụ trách có thể thay đổi khi công việc chuyển từ bộ phận phát triển kinh doanh sang trưởng bộ phận hoặc đội ngũ triển khai, nhưng ứng dụng phải luôn cho biết ai là người hành động tiếp theo.

Hãy dùng một trường hợp thử nghiệm thực tế với nhiều người liên hệ, thời hạn gấp, xung đột tiềm ẩn và ngân sách chưa đầy đủ. Kiểm tra xem ứng dụng có chuyển yêu cầu đến đúng người kiểm tra, chặn bàn giao trước khi xác nhận xung đột và giữ các ghi chú trong cùng một bản ghi hay không. Yêu cầu nhân viên thử quy trình, sau đó sửa những nhãn gây nhầm lẫn và các trường không cần thiết.

Với một ứng dụng tiếp nhận cần nhiều hơn biểu mẫu tiếp nhận dự án cơ bản, AppMaster cung cấp một không gian no-code cho biểu mẫu, quy tắc nghiệp vụ và quyền truy cập web hoặc di động. Đội ngũ có thể mô hình hóa các bản ghi yêu cầu và người liên hệ, tạo các bước xem xét trong Business Process Editor trực quan và tạo ứng dụng mà không phải duy trì các bảng tính riêng biệt.

Hãy bắt đầu với quy trình nhỏ nhất mà đội ngũ có thể thực hiện nhất quán. Chỉ thêm trường và quy tắc khi nhân viên có thể giải thích chúng ảnh hưởng thế nào đến một quyết định hoặc hành động tiếp theo.