Cổng thông tin yêu cầu bảo trì: xây dựng quy trình tốt hơn cho người thuê

Vì sao các yêu cầu bảo trì thường bị bỏ sót hoặc chậm trễ

Các cuộc gọi điện, tin nhắn, thư thoại và email rải rác tạo ra hồ sơ sửa chữa thiếu rõ ràng. Một người thuê có thể mô tả đường ống bị rò rỉ trong lúc quản lý đang bận, sau đó người quản lý phải nhớ các chi tiết, tìm nhà thầu và cập nhật cho người thuê. Chỉ một tin nhắn bị bỏ sót cũng có thể khiến mọi người không biết bước tiếp theo thuộc về ai.

Những thông tin quan trọng ban đầu thường bị thất lạc. Nhân viên có thể chỉ biết «bếp bị rò nước» nhưng không biết số căn hộ, người thuê phát hiện từ khi nào, nước còn chảy hay không hoặc có ai có thể vào nhà hay không. Một bức ảnh chụp đường ống nứt, trần nhà ẩm hoặc thiết bị hỏng thường giải thích vấn đề tốt hơn một đoạn mô tả ngắn.

Cổng thông tin yêu cầu bảo trì cho người thuê một nơi duy nhất để gửi yêu cầu sửa chữa. Biểu mẫu có thể thu thập bất động sản và căn hộ, loại sự cố, mô tả, ảnh, thông tin liên hệ và lựa chọn truy cập. Người thuê không phải lặp lại thông tin nhiều lần, còn nhân viên nhận được dữ liệu có thể sử dụng ngay.

Nhân viên cũng cần một hồ sơ sửa chữa dùng chung. Hồ sơ nên cho biết ai đã nhận yêu cầu, ai xử lý, trạng thái hiện tại, ghi chú lịch hẹn và các tin nhắn đã gửi cho người thuê. Nếu không có hồ sơ này, nhân viên cho thuê có thể nói rằng nhà thầu đã được đặt lịch trong khi đội bảo trì vẫn chưa phân công ai.

Các vấn đề khẩn cấp cần một quy trình riêng. Cổng thông tin nên yêu cầu người thuê gọi dịch vụ khẩn cấp khi có nguy hiểm tức thời như hỏa hoạn, nghi ngờ rò rỉ gas hoặc cấp cứu y tế. Cổng thông tin cũng nên cung cấp số liên hệ khẩn cấp của bất động sản cho các vấn đề nghiêm trọng của tòa nhà, chẳng hạn như ngập nước đang diễn ra hoặc mất hoàn toàn hệ thống sưởi trong những trường hợp quy định địa phương yêu cầu phản hồi nhanh.

Các yêu cầu thông thường có thể đi theo một trình tự đơn giản: người thuê gửi vấn đề cùng đủ thông tin và ảnh, nhân viên đặt mức độ ưu tiên và phân công công việc, người được phân công ghi lại thông tin cập nhật và thời gian dự kiến đến sửa, còn người thuê theo dõi tiến độ mà không phải gọi nhiều người.

Thông tin trạng thái rõ ràng rất quan trọng. «Đã tiếp nhận», «đã lên lịch», «đang thực hiện» và «đã hoàn tất» cho người thuê biết chuyện gì đang xảy ra. Tránh các nhãn mơ hồ như «đang mở» khi nhân viên đã sắp xếp lịch đến. Ứng dụng bảo trì bất động sản không thể làm mọi việc sửa chữa nhanh hơn, nhưng có thể ngăn yêu cầu bị thất lạc giữa các hộp thư.

Chọn những việc cổng thông tin cần thực hiện

Hãy bắt đầu bằng những thao tác hằng ngày thay vì thêm mọi tính năng có thể ngay từ ngày đầu. Người thuê cần một quy trình ngắn để báo lỗi, đính kèm ảnh, cho biết thời gian có thể vào nhà và xem trạng thái sửa chữa sau đó. Một biểu mẫu yêu cầu quá nhiều thông tin thường khiến họ quay lại gọi điện và gửi báo cáo thiếu dữ liệu.

Nhân viên cần góc nhìn đầy đủ hơn. Họ phải xem xét từng yêu cầu, quyết định mức độ khẩn cấp, giao cho nhân viên bảo trì hoặc nhà thầu, thêm thông tin cập nhật và đóng công việc khi đã hoàn tất. Hãy ghi lại mọi thay đổi. Nếu người thuê hỏi vì sao việc sửa chữa mất một tuần, nhân viên cần xem được ai đã nhận yêu cầu, khi nào họ liên hệ với nhà thầu và công việc nào đã được thực hiện.

Cung cấp giao diện phù hợp cho từng người

Người thuê chỉ nên thấy những thông tin giúp họ hiểu bước tiếp theo. Ghi chú nội bộ có thể chứa thông tin liên hệ của nhà thầu, dự toán chi phí, nguyên nhân nghi ngờ hoặc vấn đề truy cập. Hãy tách những ghi chú này khỏi tin nhắn dành cho người thuê để tránh vô tình tiết lộ thông tin.

Trong cổng thông tin người thuê, hãy dùng một nhóm trạng thái nhỏ và dễ hiểu:

• Đã gửi: đội ngũ bất động sản đã nhận yêu cầu.
• Đang xem xét: nhân viên đang kiểm tra vấn đề và quyết định cách xử lý.
• Đã lên lịch: chuyến sửa chữa đã có ngày hoặc khung giờ dự kiến.
• Đang thực hiện: nhân viên đã bắt đầu sửa chữa.
• Đã hoàn tất: nhân viên đã ghi nhận công việc hoàn thành.

Nhân viên có thể sử dụng thêm các trạng thái nội bộ như «đang chờ linh kiện» hoặc «đang chờ báo giá của nhà thầu». Người thuê không cần phải giải mã mọi chi tiết vận hành. Nếu vòi nước trong bếp cần một linh kiện thay thế, thông báo «Chúng tôi đã đặt linh kiện và sẽ xác nhận ngày đến sửa» hữu ích hơn nhiều.

AppMaster hỗ trợ các giao diện riêng cho người thuê và nhân viên, cơ sở dữ liệu yêu cầu và quy trình trực quan kiểm soát việc thay đổi trạng thái. Hãy xây dựng hành trình yêu cầu cơ bản trước, sau đó thêm quy trình cho nhà thầu hoặc lời nhắc tự động khi đội ngũ đã sử dụng cổng thông tin ổn định.

Lập kế hoạch cho biểu mẫu yêu cầu và hồ sơ sửa chữa

Biểu mẫu nên thu thập đủ thông tin để cử đúng người mà không biến một báo cáo đơn giản thành thủ tục rườm rà. Người thuê chỉ nên phải mô tả vấn đề một lần. Đội ngũ của bạn không nên gọi điện hoặc gửi email để hỏi những thông tin cơ bản.

Bắt đầu mỗi hồ sơ sửa chữa bằng một tiêu đề ngắn, dễ hiểu và phần mô tả. «Nước dưới bồn rửa bếp» cho nhân viên bảo trì biết nhiều hơn «vấn đề hệ thống nước». Yêu cầu người thuê chọn vị trí như bếp, phòng tắm, phòng ngủ, hành lang hoặc khu vực chung. Danh mục cũng giúp nhân viên phân tuyến công việc: hệ thống nước, sưởi, điện, thiết bị, côn trùng hoặc sửa chữa chung.

Hãy dùng những câu hỏi về mức độ ưu tiên mà người thuê có thể hiểu. Thay vì yêu cầu họ tự đánh giá mức độ khẩn cấp kỹ thuật, hãy hỏi liệu có nước đang chảy, mất nhiệt, nguy cơ an toàn hoặc hư hỏng lan rộng hay không. Sau đó nhân viên có thể đặt mức độ ưu tiên.

Hồ sơ cũng cần số căn hộ, tên, số điện thoại và email của người thuê. Nếu người thuê đăng nhập, hãy tự động điền các thông tin này và cho phép họ sửa số điện thoại khi cần. Nhờ vậy sẽ tránh được những báo cáo như «đèn bị hỏng» nhưng không có địa điểm rõ ràng để cử người đến.

Ảnh đính kèm thường giúp tránh một chuyến đi đầu tiên không cần thiết. Cho phép người thuê thêm nhiều ảnh cho mỗi yêu cầu và giữ ảnh trong hồ sơ sửa chữa thay vì gửi đến một hộp thư riêng. Yêu cầu họ chụp khu vực bị lỗi, không chụp giấy tờ cá nhân hoặc người cư dân khác.

Giữ thông tin truy cập cùng với yêu cầu

Đội sửa chữa cần biết quyền truy cập và thời gian phù hợp trước khi lên lịch. Thêm các lựa chọn đơn giản như «Tôi sẽ có mặt», «Bạn có thể vào khi tôi vắng nhà» và «Hãy liên hệ với tôi trước khi vào». Bao gồm ngày hoặc khung giờ có thể đến cùng một trường ghi chú thực tế.

Ghi chú có thể nêu việc có thú cưng trong căn hộ, trẻ đang ngủ, mã cổng hoặc yêu cầu gõ cửa thay vì bấm chuông. Giới hạn người có thể xem các chi tiết này và giữ chúng trong hồ sơ để nhân viên được phân công thấy hướng dẫn mới nhất.

Trong AppMaster, bạn có thể mô hình hóa các trường này trong Data Designer và kết nối biểu mẫu người thuê với hồ sơ sửa chữa thông qua các quy trình trực quan. Hãy giữ thông tin cập nhật trạng thái tách khỏi báo cáo ban đầu để quản lý và người thuê luôn có thể xem những chi tiết đã bắt đầu công việc.

Giúp người thuê báo lỗi dễ dàng

Cổng thông tin yêu cầu bảo trì nên đủ đơn giản để sử dụng khi một người đang mệt, bận hoặc phải xử lý đường ống bị rò rỉ. Dùng các danh mục dễ hiểu như hệ thống nước, sưởi, thiết bị, điện, côn trùng và an toàn. Tránh những nhãn đòi hỏi người thuê phải hiểu cách một tòa nhà vận hành.

Hãy hỏi phòng hoặc khu vực ngay từ đầu biểu mẫu. Một danh sách ngắn như bếp, phòng tắm, phòng ngủ, hành lang hoặc khu vực bên ngoài giúp đội bảo trì sắp xếp yêu cầu. Thêm lựa chọn «khác» cho phòng giặt chung, chỗ đỗ xe và những địa điểm ít phổ biến hơn.

Ô mô tả cần có gợi ý, không nên chỉ là một trường trống. Hãy hỏi người thuê vấn đề bắt đầu khi nào, họ nhìn thấy hoặc nghe thấy gì, sự cố có xảy ra liên tục không và nước, điện, nhiệt hoặc quyền truy cập có thay đổi không. Ví dụ: «Nước rò từ đường ống dưới bồn rửa bếp mỗi khi tôi mở vòi. Sự cố bắt đầu sáng nay.»

Cho phép người thuê đính kèm ảnh trực tiếp từ điện thoại hoặc máy tính và đặt nút tải lên ở vị trí dễ thấy. Ảnh chụp nhãn thiết bị, vết ố trên trần hoặc nước quanh một bộ phận giúp đội sửa chữa hiểu tình hình trước khi đến.

Giữ biểu mẫu tiêu chuẩn tập trung vào các yêu cầu sửa chữa thông thường. Đặt hướng dẫn khẩn cấp phía trên biểu mẫu trong một thông báo riêng. Yêu cầu người thuê gọi dịch vụ khẩn cấp khi có nguy hiểm tức thời như hỏa hoạn, mùi gas hoặc chấn thương nghiêm trọng. Cung cấp một số liên hệ bảo trì khẩn cấp riêng cho các vấn đề cấp bách của bất động sản như rò rỉ lớn đang diễn ra hoặc mất hoàn toàn hệ thống sưởi.

Một biểu mẫu thực tế có thể ngắn gọn:

• Danh mục sự cố và phòng hoặc khu vực
• Mô tả vấn đề và thời điểm bắt đầu
• Ảnh đính kèm nếu có
• Lựa chọn truy cập và thông tin liên hệ

AppMaster giúp bạn tạo loại ứng dụng bảo trì bất động sản này với biểu mẫu trực quan, tính năng tải tệp lên và hồ sơ yêu cầu để nhân viên xem xét. Hãy để các trường tùy chọn đúng là tùy chọn. Người thuê nên gửi được một báo cáo hữu ích trong vài phút, ngay cả khi họ không có ảnh hoặc không biết tên bộ phận bị hỏng.

Thu thập lựa chọn truy cập an toàn

Đội sửa chữa không bao giờ nên phải đoán xem có thể vào nhà người thuê hay không. Thêm lựa chọn truy cập vào mọi yêu cầu và dùng cách diễn đạt dễ hiểu, đặc biệt với các vấn đề khẩn cấp.

Cung cấp một số lựa chọn cho những tình huống thông thường: cho phép vào khi người thuê vắng mặt, hẹn trước khi vào, liên hệ với người thuê trước hoặc vào nhà khẩn cấp trong trường hợp cấp bách. Hỏi người thuê muốn nhân viên liên hệ bằng điện thoại, tin nhắn hay email, sau đó thu thập một vài khung giờ có thể tiếp cận. Người thuê có thể cho phép đến vào các ngày trong tuần sau 17:30 nhưng không thể tiếp khách trong giờ làm việc. Điều này giúp tránh lỡ hẹn và các cuộc gọi lặp lại.

Hãy xem hướng dẫn vào nhà là thông tin nhạy cảm. Chỉ thu thập mã cổng, mã vào tòa nhà, thông tin hộp khóa hoặc cảnh báo về thú cưng khi công việc sửa chữa cần đến chúng. Không bắt buộc các trường này cho mọi yêu cầu. Hạn chế quyền truy cập và xóa hướng dẫn cũ khi người thuê cập nhật thông tin hoặc khi yêu cầu đã đóng.

Hiển thị lựa chọn truy cập mới nhất gần trạng thái công việc, nơi nhân viên bảo trì có thể xem trước khi lên lịch hoặc bắt đầu chuyến đến. Nếu người thuê đổi «cho phép vào» thành «cần hẹn trước», hãy thay hướng dẫn cũ thay vì hiển thị cả hai.

Ví dụ, một người thuê báo đường ống trong bếp bị rò và chọn «liên hệ trước». Quản lý bất động sản gọi điện, thống nhất lịch vào sáng thứ Ba và ghi lại cuộc hẹn. Thợ sửa ống nước thấy thời gian đã xác nhận và hướng dẫn vào nhà hiện tại trước khi đến. Bàn giao đơn giản này giúp tránh chuyến đi không cần thiết đến một cánh cửa bị khóa.

Ứng dụng bảo trì bất động sản được xây dựng bằng AppMaster có thể lưu lựa chọn truy cập cùng hồ sơ sửa chữa và chỉ hiển thị thông tin hiện tại cho nhân viên được phép. Khi trạng thái thay đổi, hệ thống cũng có thể nhắc đội ngũ xác nhận quyền truy cập trước khi đánh dấu chuyến đến là đã lên lịch.

Hiển thị tiến độ sửa chữa mà không gây khó hiểu

Cổng thông tin người thuê nên trả lời một mối quan tâm phổ biến: «Việc sửa chữa của tôi đang diễn ra thế nào?» Một trạng thái ngắn tốt hơn nhật ký công việc quá chi tiết khiến người thuê có thêm câu hỏi.

Hãy dùng cùng một cách diễn đạt cho mọi yêu cầu. Năm giai đoạn thường là đủ:

• Đã tiếp nhận: đội ngũ bất động sản đã nhận yêu cầu và sẽ xem xét.
• Đã lên lịch: chuyến sửa chữa đã có ngày dự kiến hoặc đội ngũ đang sắp xếp lịch.
• Đang thực hiện: kỹ thuật viên đã bắt đầu làm việc hoặc chẩn đoán vấn đề.
• Đang chờ: công việc cần linh kiện, phê duyệt hoặc một chuyến đến khác.
• Đã hoàn tất: đội ngũ đã đánh dấu sửa chữa là xong.

Tránh các nhãn như «đang mở», «đang chờ xử lý» hoặc «đã phân công». Chúng mô tả công việc nội bộ nhưng không cho người thuê biết có ai sẽ đến hay họ cần làm gì.

Mỗi yêu cầu nên hiển thị ngày cập nhật gần nhất và một hành động tiếp theo. Người thuê báo vòi nước bị rò có thể thấy: «Đã lên lịch. Cập nhật ngày 12 tháng 5. Thợ sửa ống nước sẽ đến ngày 14 tháng 5, trong khoảng 9:00 đến 12:00.» Nếu van cần thiết đang hết hàng, thông báo có thể là: «Đang chờ. Cập nhật ngày 14 tháng 5. Chúng tôi đã đặt linh kiện thay thế và sẽ liên hệ khi linh kiện đến.»

Tách thông tin cập nhật cho người thuê khỏi ghi chú nhân viên

Nhân viên bất động sản, quản lý và nhà cung cấp thường cần các chi tiết riêng tư như báo giá, lịch sử tài khoản, ghi chú truy cập tòa nhà hoặc trao đổi nội bộ về trách nhiệm. Không đặt những ghi chú này trong giao diện của người thuê.

Tạo các trường riêng cho ghi chú nội bộ và thông tin cập nhật dành cho người thuê. Nhân viên có thể ghi lại toàn bộ lịch sử sửa chữa, còn người thuê chỉ thấy bản tóm tắt rõ ràng, hành động tiếp theo và thông tin lịch hẹn. AppMaster hỗ trợ việc tách biệt này bằng các giao diện dựa trên vai trò, để nhân viên quản lý hồ sơ sửa chữa còn người thuê chỉ thấy thông tin dành cho họ.

Trạng thái hoàn tất nên có một thông báo kết thúc ngắn, chẳng hạn như «Thợ sửa ống nước đã thay vòng đệm vòi vào ngày 16 tháng 5.» Hãy cho người thuê cách báo rằng vấn đề vẫn còn. Nhờ vậy yêu cầu vẫn được theo dõi nếu chuyến sửa chữa đầu tiên chưa giải quyết được sự cố.

Xây dựng cổng thông tin từng bước

Hãy xây dựng phiên bản đầu tiên xoay quanh một quy trình hoàn chỉnh: người thuê gửi vấn đề, nhân viên xem xét, một nhân viên sửa chữa được phân công và người thuê nhìn thấy thông tin cập nhật. AppMaster có thể tạo dịch vụ backend, cổng thông tin web và ứng dụng di động từ cùng một dự án trực quan, giúp các hồ sơ luôn được kết nối.

1. Tạo tài khoản người thuê và liên kết từng tài khoản với đúng bất động sản và căn hộ. Người thuê chỉ nên thấy các yêu cầu thuộc căn hộ của mình. Nhân viên cần quyền truy cập dựa trên vai trò như quản lý bất động sản hoặc điều phối viên bảo trì.

2. Tạo biểu mẫu có danh mục, tiêu đề ngắn, mô tả, tải ảnh lên, thời gian mong muốn được đến và lựa chọn truy cập. Bắt buộc danh mục và mô tả. Với các vấn đề khẩn cấp như rò rỉ đang diễn ra, hãy hiển thị thêm hướng dẫn gọi số khẩn cấp.

3. Thêm khu vực làm việc cho nhân viên, trong đó các yêu cầu mới được hiển thị trước và có bộ lọc theo bất động sản, trạng thái, danh mục và ngày. Thêm trường cho nhà thầu được phân công, ngày hẹn, ghi chú nội bộ và chi phí sửa chữa nếu đội ngũ của bạn theo dõi thông tin này.

4. Thiết lập các trạng thái như Mới, Đã xem xét, Đã lên lịch, Đang thực hiện và Đã hoàn tất. Khi nhân viên thay đổi trạng thái, lưu thời gian và tên người thực hiện. Nhờ đó nhân viên có lịch sử sửa chữa để kiểm tra khi người thuê gọi điện.

5. Gửi thông báo khi có yêu cầu mới, lịch hẹn và thông tin cập nhật trạng thái dành cho người thuê. Email hoặc SMS đều có thể dùng, nhưng không thông báo cho người thuê về mọi chỉnh sửa nội bộ. Quá nhiều cảnh báo khiến họ bỏ qua những thông báo hữu ích.

Hãy kiểm thử toàn bộ cổng thông tin bằng tài khoản mẫu trước khi mời người thuê. Gửi ảnh về một đường ống bếp bị rò, chọn lựa chọn truy cập, phân công yêu cầu cho nhân viên và đánh dấu hoàn tất. Xác nhận rằng người thuê thấy đúng thông tin cập nhật, còn các chi tiết nội bộ vẫn riêng tư.

Data Designer của AppMaster có thể mô hình hóa căn hộ, người thuê, yêu cầu, ảnh và lịch sử trạng thái. Business Process Editor có thể chuyển yêu cầu mới đến đúng nhân viên và kích hoạt thông báo mà không cần tự viết mã cho quy trình.

Ví dụ: người thuê báo đường ống bếp bị rò

Maya nhận thấy nước đọng dưới bồn rửa bếp sau khi rửa bát. Cô mở cổng thông tin trên điện thoại, chọn «Hệ thống nước» và viết: «Nước nhỏ từ đường ống dưới bồn rửa khi mở vòi. Sàn tủ bị ướt.»

Cô thêm hai ảnh, một ảnh chụp đường ống bị rò và một ảnh chụp tủ ướt, sau đó chọn rằng vấn đề cần được xử lý sớm vì nước có thể làm hỏng tủ và sàn. Biểu mẫu hỏi khi nào nhân viên có thể vào. Maya chọn «Cần hẹn trước», cho biết cô rảnh sau 16:00 vào các ngày trong tuần và nhập số điện thoại để nhận thông tin lịch hẹn. Cổng thông tin tạo yêu cầu số 1842 và hiển thị «Đã tiếp nhận».

Quản lý bất động sản xem xét yêu cầu vào buổi sáng. Ảnh cho thấy khả năng cao là mối nối thoát nước bị lỏng chứ không phải đường ống vỡ, nên quản lý phân công thợ sửa ống nước và đổi trạng thái thành «Đã lên lịch». Maya thấy khung giờ hẹn vào thứ Ba, từ 16:30 đến 18:00, trên cổng thông tin.

Thợ sửa thay vòng đệm đã mòn, siết chặt mối nối và kiểm tra bồn rửa. Người này thêm ghi chú ngắn: «Đã thay vòng đệm ống thoát và kiểm tra bồn rửa trong năm phút. Không phát hiện rò rỉ thêm.» Sau đó nhân viên đánh dấu yêu cầu là đã hoàn tất.

Maya nhận thông báo hoàn tất qua email hoặc tin nhắn, tùy theo phương thức cô đã chọn. Cô có thể đọc ghi chú sửa chữa và xác nhận tủ vẫn khô. Nếu nước lại rò, cô có thể mở lại yêu cầu cũ thay vì tạo yêu cầu trùng lặp.

Đây là lúc một hồ sơ sửa chữa dùng chung phát huy tác dụng. AppMaster có thể giữ mô tả, ảnh, lựa chọn truy cập, lịch hẹn, ghi chú nhân viên và xác nhận cuối cùng của người thuê trong cùng một nơi, giúp giảm cuộc gọi, tin nhắn thất lạc và trạng thái sửa chữa không rõ ràng.

Những lỗi thường khiến người thuê khó chịu

Cổng thông tin yêu cầu bảo trì nên giúp việc báo lỗi dễ hơn, không chuyển thêm công việc quản lý bất động sản cho người thuê. Những lựa chọn nhỏ trong biểu mẫu hoặc hệ thống trạng thái có thể khiến mọi người không biết liệu có ai đã đọc một vấn đề nghiêm trọng hay chưa.

Đừng yêu cầu người thuê chọn các nhãn kỹ thuật như «khẩn cấp», «thông thường» hoặc «phòng ngừa». Hầu hết mọi người không thể đánh giá một mảng ẩm là nhỏ hay một vết rò đang lan rộng. Hãy hỏi bằng ngôn ngữ đơn giản về nước đang chảy, mất nhiệt, nguy cơ an toàn hoặc hư hỏng lan rộng, sau đó để nhân viên quyết định mức độ ưu tiên.

Giữ thông tin nội bộ ngoài giao diện người thuê. Ghi chú nhân viên có thể chứa giá của nhà cung cấp, chi tiết lịch hẹn hoặc các trao đổi mà người thuê không cần đọc. Không công khai số điện thoại trực tiếp của nhà thầu nếu nhà thầu chưa đồng ý liên hệ với người thuê.

Giải thích từng trạng thái

«Đang chờ xử lý» không cho biết nhiều điều. Nó có thể có nghĩa là đang chờ phê duyệt, linh kiện, lịch hẹn hoặc phản hồi của người thuê. Mỗi trạng thái nên cho người thuê biết chuyện gì đang xảy ra và, khi có thể, họ cần làm gì tiếp theo.

Hãy dùng các thông báo như:

• «Chúng tôi đã nhận yêu cầu và sẽ xem xét trước thứ Ba.»
• «Thợ sửa ống nước sẽ đến vào thứ Năm, trong khoảng 9:00 đến 12:00.»
• «Chúng tôi đã đặt linh kiện thay thế và sẽ cập nhật khi linh kiện đến.»
• «Chúng tôi cần biết thời gian bạn có thể cho vào nhà trước khi đặt lịch sửa chữa.»

Chỉ đóng yêu cầu sau khi nhân viên ghi nhận công việc đã hoàn thành. Ghi chú như «Đã thay bẫy nước dưới bồn rửa bị hỏng và kiểm tra rò rỉ» cung cấp hồ sơ hữu ích cho người thuê và giúp nhân viên xử lý nếu sự cố quay lại. Khi phù hợp, hãy giữ yêu cầu đã hoàn tất hiển thị và cho phép người thuê báo rằng vấn đề vẫn còn.

Ảnh giúp nhân viên hiểu lỗi, nhưng không thể thay thế việc liên hệ ngay khi có vấn đề an toàn. Ảnh khói, dây điện hở, mùi gas hoặc ngập nước nghiêm trọng có thể tải lên chậm hoặc không được xem ngoài giờ làm việc. Hãy đặt hướng dẫn khẩn cấp rõ ràng gần biểu mẫu. Cổng thông tin có thể ghi nhận báo cáo sau đó, nhưng không được làm chậm phản ứng an toàn.

Kiểm tra cổng thông tin trước khi mời người thuê

Hãy kiểm thử cổng thông tin theo cách người thuê sử dụng trước khi chia sẻ với một tòa nhà. Biểu mẫu trông ổn trên máy tính văn phòng có thể khó dùng trên điện thoại, nơi nhiều cư dân sẽ báo lỗi.

Gửi một yêu cầu thử nghiệm trên điện thoại và một yêu cầu khác trên trình duyệt máy tính. Kiểm tra xem biểu mẫu có dễ đọc không, các nút có luôn hiển thị không và người thuê có thể gửi báo cáo mà không phải phóng to hoặc nhập lại thông tin sau khi gặp lỗi không.

Dùng một ảnh thật trong quá trình kiểm thử. Tải ảnh chụp một vấn đề mẫu lên, sau đó mở yêu cầu trong giao diện nhân viên. Nhân viên phải xem ảnh rõ ràng và biết ảnh thuộc yêu cầu nào. Kiểm tra điều gì xảy ra khi ảnh có dung lượng lớn hoặc người thuê mất kết nối trong lúc tải lên.

Hãy kiểm tra cả thông tin truy cập. Tạo một yêu cầu trong đó người thuê có mặt sau 17:00, một yêu cầu cho phép vào nhà khi đã báo trước và một yêu cầu yêu cầu nhân viên gọi trước. Phân công từng yêu cầu cho một nhân viên và xác nhận người đó nhận được lựa chọn truy cập cùng thông tin yêu cầu. Đừng phụ thuộc vào một tin nhắn riêng hoặc trí nhớ của nhân viên.

Đưa một yêu cầu đi qua mọi trạng thái dự kiến, bao gồm đã gửi, đã lên lịch, đang thực hiện và đã hoàn tất. Xem lại mọi thông báo dành cho người thuê. Mỗi tin nhắn phải giải thích thay đổi bằng ngôn ngữ đơn giản mà không để lộ chi tiết chỉ dành cho nhân viên.

Cuối cùng, hãy kiểm tra quyền riêng tư bằng hai tài khoản người thuê. Mỗi người chỉ được thấy yêu cầu sửa chữa của mình. Họ không được xem ghi chú nội bộ, thông tin liên hệ riêng của nhân viên hoặc yêu cầu của cư dân khác. Với cổng thông tin AppMaster, hãy kiểm tra cùng một bộ quy tắc quyền trong cả giao diện web và di động được tạo ra. Sửa quyền truy cập trước khi ra mắt dễ hơn nhiều so với việc giải thích một lỗi riêng tư sau đó.

Các bước tiếp theo cho cổng thông tin yêu cầu bảo trì

Hãy bắt đầu với một bất động sản hoặc một nhóm căn hộ giới hạn trong vài tuần. Các yêu cầu thực tế sẽ cho thấy biểu mẫu nào chưa rõ, người thuê thường chọn sai danh mục nào và nhân viên có thể xử lý công việc mà không cần các tin nhắn bên ngoài hay không.

Hỏi người thuê và nhân viên những phản hồi cụ thể. Một người thuê có thể khó chọn giữa «hệ thống nước» và «rò rỉ nước», trong khi điều phối viên bảo trì cần cách tốt hơn để ghi lại lịch hẹn hoặc linh kiện đã đặt. Hãy sửa những điểm làm mọi người chậm lại trước khi thêm nhiều lựa chọn hơn.

Giữ phiên bản đầu tiên tập trung vào công việc hằng ngày: biểu mẫu sửa chữa đơn giản có tải ảnh và lựa chọn truy cập, các danh mục sự cố phổ biến, trạng thái giải thích được công việc, lịch sử sửa chữa dùng chung và thông báo khi nhân viên cần thêm thông tin hoặc thay đổi trạng thái.

Xem lại các yêu cầu sau tháng đầu tiên. Nếu nhiều người chọn «khác», hãy thêm các danh mục phù hợp với vấn đề thực tế. Nếu người thuê vẫn hỏi thông tin sau khi yêu cầu hiển thị «đang thực hiện», hãy dùng cách diễn đạt cụ thể hơn như «đã lên lịch» hoặc «đang chờ linh kiện». Ngôn ngữ rõ ràng giúp giảm các cuộc gọi không cần thiết.

Với AppMaster, bạn có thể tạo cổng thông tin no-code gồm hồ sơ sửa chữa, biểu mẫu, quy trình điều phối và giao diện web hoặc di động cho người thuê và nhân viên. Hãy bắt đầu với một loại yêu cầu và một quy trình xem xét của nhân viên, sau đó thêm phân công tự động hoặc quy trình chi tiết hơn khi quy trình cơ bản đã hoạt động tốt.

Một bài kiểm thử ban đầu rất đơn giản: người thuê gửi ảnh bồn rửa bếp bị rò, chọn xem nhân viên có thể vào nhà khi họ vắng mặt hay không và nhận thông tin cập nhật cho đến khi sửa chữa hoàn tất. Nếu quy trình này rõ ràng với tất cả mọi người, cổng thông tin đã sẵn sàng được triển khai rộng hơn.