Aplikasi intake untuk perusahaan layanan profesional: rencana praktis

Mengapa intake yang tersebar menimbulkan keterlambatan yang sebenarnya bisa dihindari

Permintaan dari klien baru sering dimulai lewat email, lalu menyebar ke pesan yang diteruskan, catatan panggilan, dan spreadsheet yang diperbarui belakangan. Nama perusahaan tersimpan di satu tempat, ruang lingkup proyek di tempat lain, sementara tenggat yang dijanjikan terkubur di kotak masuk. Staf akhirnya meminta informasi yang sebenarnya sudah diberikan klien kepada orang lain.

Celah kecil ini cepat menumpuk. Partner tidak dapat menilai kecocokan tanpa ringkasan yang jelas. Tim operasional tidak dapat membagi pekerjaan tanpa perkiraan tanggal mulai. Satu orang mengira rekannya akan menindaklanjuti, sementara rekannya mengira permintaan tersebut masih ditinjau.

Pemeriksaan konflik memiliki risiko yang lebih besar. Sebelum siapa pun memulai pekerjaan substantif atau membuat komitmen, perusahaan perlu meninjau klien, entitas terkait, pihak lawan, dan detail perkara yang relevan. Saat informasi itu terpisah di berbagai pesan, peninjau mungkin hanya melihat sebagian gambaran. Pemeriksaan yang dilakukan terburu-buru dapat melewatkan hubungan yang memengaruhi keputusan perusahaan untuk menerima pekerjaan tersebut.

Aplikasi intake untuk perusahaan layanan profesional menempatkan informasi penting dalam satu catatan bersama sejak pertanyaan pertama masuk. Setiap permintaan memiliki status yang jelas, seperti Baru, Menunggu peninjauan konflik, Disetujui, atau Ditugaskan. Tim dapat melihat informasi terkini tanpa menyusun ulang cerita dari berbagai email.

Setiap langkah berikutnya juga membutuhkan penanggung jawab. Koordinator pengembangan bisnis dapat mengumpulkan detail yang kurang, peninjau yang ditunjuk dapat menyelesaikan pemeriksaan konflik, dan pimpinan praktik dapat memutuskan apakah pekerjaan akan dilanjutkan. Penanggung jawab yang jelas mencegah permintaan yang menjanjikan terabaikan selama berhari-hari karena tidak ada yang tahu siapa yang harus bertindak.

Alur kerja intake klien yang baik seharusnya terasa sederhana. Alur ini mengumpulkan konteks yang cukup untuk mengambil keputusan yang tepat, meneruskan permintaan kepada orang yang sesuai, dan menyimpan riwayat singkat tentang apa yang terjadi. Setelah perusahaan menerima pekerjaan, catatan yang sama dapat diteruskan ke tim pelaksana dengan ruang lingkup yang disetujui, kontak, kisaran anggaran, dan komitmen yang tetap utuh.

Catatan bersama ini menggantikan pekerjaan detektif dengan serah terima yang dapat diulang. Manajer juga dapat melihat permintaan yang masih terbuka, tahap yang sedang menahan setiap permintaan, dan siapa yang perlu bertindak.

Petakan orang dan keputusan yang terlibat

Setiap permintaan membutuhkan jalur yang jelas di dalam perusahaan. Sebelum membuat bidang atau layar, tentukan siapa saja yang menangani permintaan dan keputusan apa yang dibuat oleh masing-masing orang. Dengan begitu, masalah kotak masuk bersama yang membuat semua orang mengira orang lain akan menjawab dapat dihindari.

Sebagian besar perusahaan membutuhkan empat peran: orang yang mengirimkan permintaan, orang yang memeriksa apakah perusahaan dapat menerimanya, orang yang menyetujui pekerjaan, dan orang yang melaksanakannya. Di perusahaan kecil, satu orang mungkin memegang beberapa peran. Aplikasi tetap perlu mencatat setiap keputusan secara terpisah.

Calon klien mungkin mengirimkan formulir intake proyek setelah berbicara dengan konsultan. Koordinator intake memeriksa apakah detail permintaan sudah cukup. Peninjau konflik memeriksa nama dan pihak terkait. Pimpinan praktik memutuskan apakah perusahaan akan melanjutkan. Konsultan yang ditugaskan kemudian menerima permintaan yang telah disetujui, tindakan berikutnya, dan tenggatnya.

Pisahkan pertanyaan klien dari catatan internal

Klien hanya perlu melihat pertanyaan yang dapat mereka jawab: nama perusahaan, tujuan proyek, tenggat, kontak, dan kisaran anggaran yang diharapkan. Simpan bidang internal di luar formulir yang dilihat klien. Bidang ini dapat mencakup catatan risiko, komentar tentang kapasitas, panduan biaya, detail konflik, dan keputusan perusahaan.

Langkah ini melindungi informasi sensitif dan membuat formulir terasa lebih mudah diisi. Klien tidak perlu memahami proses peninjauan konflik perusahaan hanya untuk memulai percakapan.

Tentukan hak akses sebelum membangun alur kerja:

• Pengirim dapat membuat permintaan dan melihat status permintaan mereka sendiri.
• Staf intake dapat memperbaiki detail, meminta informasi yang kurang, dan meneruskan permintaan.
• Peninjau konflik dapat melihat nama para pihak dan menambahkan catatan internal.
• Pimpinan praktik dapat melihat anggaran, detail kapasitas, dan keputusan persetujuan.
• Tim pelaksana dapat melihat pekerjaan yang disetujui dan informasi yang diperlukan untuk memulai.

Aturan akses harus mengikuti cara perusahaan menangani perkara rahasia. Peninjau mungkin perlu melihat nama klien dan pihak lawan, tetapi tidak perlu melihat biaya yang diusulkan. Tim pelaksana mungkin memerlukan ruang lingkup yang telah ditandatangani, tetapi tidak perlu melihat catatan konflik.

Tetapkan satu penanggung jawab untuk setiap tahap

Tetapkan satu penanggung jawab untuk setiap tahap, meskipun beberapa orang dapat membantu. Penanggung jawab menerima pengingat dan harus memajukan permintaan, mengembalikannya untuk dilengkapi, atau menutupnya. Tanggung jawab bersama biasanya membuat pekerjaan terabaikan.

Alur sederhana dapat menugaskan koordinator intake untuk memeriksa kelengkapan, tim konflik untuk melakukan peninjauan, pimpinan praktik untuk memberikan persetujuan, dan manajer proyek untuk melakukan serah terima. Catat tahap saat ini dan nama penanggung jawab dalam permintaan.

AppMaster dapat memodelkan peran, izin, dan serah terima secara visual. Dengan begitu, tim dapat membangun alur kerja intake klien berdasarkan keputusan yang benar-benar mereka buat, bukan berdasarkan formulir generik.

Tentukan konteks proyek yang perlu dikumpulkan

Aplikasi intake yang berguna dimulai dengan gambaran permintaan yang jelas. Formulir harus memberi tim detail yang cukup untuk menentukan siapa yang perlu meninjau perkara, seberapa mendesak permintaan tersebut, dan apa yang harus dilakukan berikutnya. Formulir tidak perlu meminta calon klien menyiapkan ringkasan lengkap sebelum perusahaan menyatakan kesediaannya untuk membantu.

Mulailah dengan bidang yang mengidentifikasi pekerjaan: organisasi klien, nama proyek, dan layanan yang diminta. Nama perusahaan tetap penting meskipun pertanyaan diajukan oleh satu orang, karena informasi ini membantu tim menghubungkan permintaan terkait dan memulai proses pemeriksaan konflik. Sediakan daftar singkat jenis layanan, dengan opsi «Lainnya» untuk pekerjaan yang tidak sesuai dengan pilihan yang ada.

Minta deskripsi masalah dengan bahasa sederhana. Pertanyaan seperti «Dalam hal apa Anda membutuhkan bantuan dan hasil apa yang Anda harapkan?» biasanya menghasilkan jawaban yang lebih baik daripada kotak besar berlabel «Detail proyek». Jawaban tersebut mungkin mengungkap tanggal peluncuran yang ketat, masalah regulasi, atau pekerjaan yang mencakup beberapa wilayah.

Kumpulkan waktu dan ruang lingkup sejak awal

Tanggal memengaruhi penempatan staf dan prioritas tanggapan. Kumpulkan tanggal mulai yang diinginkan, tenggat yang tidak dapat berubah, dan pilihan urgensi sederhana. Hindari pilihan yang tidak jelas seperti «secepatnya». Gunakan pilihan yang dapat ditafsirkan secara konsisten, seperti «dalam 48 jam», «minggu ini», atau «tidak ada tenggat tetap».

Lokasi dapat memengaruhi tim yang ditugaskan, kebutuhan perjalanan, aturan yang berlaku, atau format pelaksanaan. Tanyakan lokasi proyek jika memang relevan. Kemudian kumpulkan hasil yang diharapkan dengan istilah sederhana: opini tertulis, lokakarya, pengajuan, rencana implementasi, dukungan berkelanjutan, atau hasil lain yang disepakati.

Formulir intake proyek yang praktis biasanya mencakup:

• Organisasi klien dan nama proyek
• Layanan yang diminta dan ringkasan singkat
• Tanggal mulai yang diinginkan, tenggat, dan tingkat urgensi
• Lokasi atau yurisdiksi yang relevan
• Hasil yang diharapkan dan batasan yang sudah diketahui

Batasi bidang wajib pada hal yang benar-benar diperlukan

Setiap bidang wajib menambah hambatan. Jadikan bidang wajib hanya jika tim tidak dapat meneruskan atau menilai permintaan tanpa informasi tersebut. Organisasi klien, layanan yang diminta, ringkasan, dan metode kontak sering kali memenuhi syarat ini. Ruang lingkup terperinci, dokumen, anggaran, dan nomor referensi internal biasanya tidak.

Calon klien mungkin tahu bahwa mereka membutuhkan bantuan dalam sengketa karyawan, tetapi belum mengetahui hasil pekerjaan atau tenggat yang tepat. Biarkan mereka mengirimkan informasi dasar. Penanggung jawab intake dapat mengumpulkan detail yang kurang melalui tindak lanjut singkat, alih-alih kehilangan permintaan karena formulir terlalu ketat.

Dengan AppMaster, tim dapat menggunakan bidang bersyarat. Aplikasi dapat menanyakan lokasi hanya ketika lokasi memengaruhi layanan yang dipilih, atau menanyakan alasan tenggat yang mendesak hanya ketika pengirim menandai perkara sebagai mendesak. Formulir tetap singkat, sementara peninjau memperoleh konteks yang dibutuhkan.

Hubungkan kontak klien dengan permintaan

Permintaan jarang datang dari satu orang saja. Email pertama mungkin dikirim oleh manajer operasional, sementara pimpinan keuangan menyetujui pekerjaan dan kepala departemen mengambil keputusan akhir. Hubungkan semua orang tersebut ke permintaan yang sama, bukan menyebarkannya di kotak masuk dan catatan terpisah.

Mulailah dengan satu kontak utama. Kumpulkan nama lengkap, email kantor, nomor telepon, jabatan, dan metode kontak yang diutamakan. Staf harus dapat melihat detail ini di bagian atas catatan permintaan, tanpa mencari pesan lama sebelum menelepon kembali.

Catat peran setiap orang

Biarkan staf menambahkan kontak seiring berkembangnya percakapan. Setiap kontak harus terhubung ke organisasi dan permintaan proyek.

Label yang berguna meliputi:

• Kontak utama atau koordinator harian
• Pengambil keputusan untuk ruang lingkup atau waktu
• Kontak penagihan
• Kontak teknis untuk akses atau persyaratan
• Kontak hukum atau pengadaan untuk kontrak

Label ini mencegah kesalahan umum saat serah terima, seperti mengirim proposal kepada orang yang tidak dapat menyetujuinya atau mengirim faktur kepada orang yang hanya meminta pertemuan. Satu kontak dapat memiliki lebih dari satu peran, jadi izinkan beberapa label jika diperlukan.

Sebagai contoh, Maya, seorang direktur operasional, dapat menjelaskan proyek sambil menyebutkan CFO sebagai penyetuju anggaran dan manajer TI sebagai orang yang dapat menjawab pertanyaan sistem. Mencatat ketiganya di bawah satu permintaan memberi tim keuangan dan pimpinan proyek kontak yang tepat ketika pekerjaan berlanjut.

Periksa organisasi sebelum membuat catatan baru

Minta staf mencari organisasi sebelum membuat catatan baru. Cocokkan berdasarkan nama perusahaan, domain email, dan, jika tersedia, nomor telepon. Langkah ini menangkap perbedaan kecil seperti «Acme Ltd» dan «Acme Limited» yang dapat memisahkan satu klien menjadi dua catatan.

Jika organisasi sudah ada, hubungkan permintaan baru dan pastikan kontaknya masih terbaru. Jika belum ada, buat organisasi tersebut sekali dan simpan sumber pertanyaannya. Dengan begitu, alur kerja intake klien menjadi lebih rapi dan pekerjaan sebelumnya, permintaan terbuka, serta riwayat kontak lebih mudah ditemukan.

Data Designer milik AppMaster dapat memodelkan organisasi, kontak, dan permintaan sebagai catatan yang saling terhubung. Staf dapat menggunakan formulir web atau seluler untuk menambahkan kontak tanpa kehilangan hubungan dengan permintaan awal.

Bangun peninjauan konflik yang mudah diikuti

Pemeriksaan konflik membutuhkan lebih dari sekadar kotak teks dan rangkaian email. Aplikasi intake harus mengumpulkan nama-nama yang memberi peninjau konteks cukup untuk membandingkan permintaan baru dengan pekerjaan saat ini dan sebelumnya.

Tanyakan calon klien, organisasi terkait, kontak utama, pihak lawan jika sudah diketahui, serta nama perkara atau proyek. Sertakan bidang teks bebas singkat untuk hubungan yang tidak biasa, seperti perusahaan induk, mantan eksekutif, atau usaha patungan.

Pisahkan informasi konflik dari detail intake umum. Catatan konflik membutuhkan akses yang lebih ketat daripada deskripsi proyek atau kisaran anggaran. Batasi akses hanya kepada orang yang melakukan pemeriksaan dan mengambil keputusan penyelesaian.

Buat status peninjauan terlihat jelas

Berikan satu status yang terlihat pada setiap permintaan dan ubah status tersebut seiring berlangsungnya peninjauan. Hindari label seperti «Sedang ditinjau» jika staf perlu mengetahui siapa yang harus bertindak berikutnya.

• Menunggu: permintaan berisi informasi yang cukup untuk mulai ditinjau.
• Dinyatakan tidak bermasalah: peninjau tidak menemukan konflik yang menghalangi pekerjaan.
• Perlu tindak lanjut: peninjau membutuhkan fakta atau persetujuan tambahan.
• Terblokir: perusahaan tidak dapat menerima permintaan berdasarkan aturan konfliknya.

Pengirim tidak perlu mengakses hasil pencarian yang sensitif. Mereka perlu mengetahui apakah permintaan dapat dilanjutkan, membutuhkan informasi tambahan, atau harus dihentikan. Aplikasi dapat menampilkan status sederhana yang dilihat klien, sementara catatan internal tetap dibatasi.

Simpan catatan keputusan yang singkat

Setiap keputusan harus membuat catatan permanen yang berisi nama peninjau, tanggal, status, dan alasan dalam bahasa sederhana. Contoh: «Dinyatakan tidak bermasalah pada 14 Mei oleh J. Patel. Pekerjaan sebelumnya untuk afiliasi berakhir pada 2022; tidak ditemukan perkara aktif yang merugikan.»

Catatan ini menghemat waktu ketika pimpinan proyek bertanya mengapa intake tertunda atau ketika peninjau lain mengambil alih. Buat alasannya singkat dan berdasarkan fakta. Pemeriksaan konflik harus menjelaskan keputusan, bukan berubah menjadi berkas perkara kedua.

Buat satu aturan alur kerja yang jelas: staf tidak dapat menugaskan pekerjaan pelaksanaan, membuka ruang kerja klien, atau memulai pekerjaan yang dapat ditagihkan sebelum statusnya Dinyatakan tidak bermasalah. Jika peninjau memilih Perlu tindak lanjut, aplikasi harus mengembalikan permintaan dengan pertanyaan spesifik, misalnya meminta entitas hukum di balik sebuah nama merek.

AppMaster dapat mendukung proses ini melalui tabel konflik terbatas, akses berbasis peran, dan Business Process Editor visual yang mengarahkan setiap intake kepada peninjau yang tepat.

Tanyakan anggaran tanpa mengubah intake menjadi penawaran harga

Pertanyaan tentang anggaran membantu staf menentukan apakah permintaan sesuai dengan jenis pekerjaan yang biasanya diterima perusahaan. Pertanyaan ini tidak boleh menjanjikan harga. Intake awal jarang memberikan detail yang cukup untuk memperkirakan jam kerja, perubahan ruang lingkup, dukungan spesialis, atau tekanan tenggat.

Gunakan kisaran yang sesuai dengan pekerjaan yang diterima perusahaan. Perusahaan konsultan dapat menawarkan pilihan «di bawah $10.000», «$10.000 sampai $25.000», «$25.000 sampai $75.000», dan «di atas $75.000». Buat pilihan cukup luas agar klien dapat menjawab dengan cepat.

Tambahkan catatan singkat di samping bidang tersebut: «Kisaran ini membantu kami meneruskan permintaan Anda. Ini bukan penawaran harga atau perjanjian biaya.» Klien dapat menyampaikan tingkat anggaran yang nyaman bagi mereka, sementara perusahaan tetap dapat menilai pekerjaan dengan tepat.

Jika pengeluaran eksternal sering memengaruhi pekerjaan, tanyakan apakah anggaran hanya mencakup biaya perusahaan atau juga biaya luar. Biaya tersebut dapat mencakup biaya pengajuan, perjalanan, kontraktor spesialis, perangkat lunak, atau vendor lain.

Kumpulkan kisaran perkiraan, mata uang jika relevan, status persetujuan anggaran, serta catatan tentang batasan atau aturan pengadaan. Staf juga membutuhkan cara untuk menandai permintaan yang memerlukan perkiraan terperinci. Misalnya, koordinator intake dapat memilih «Perlu perkiraan» ketika calon klien memilih kisaran tertinggi tetapi menjelaskan proyek yang luas dan belum terdefinisi.

Simpan jawaban anggaran awal dalam alur kerja intake klien, tetapi simpan proposal final di catatan terpisah. Jawaban intake menangkap maksud awal. Proposal mencatat ruang lingkup, asumsi, tarif, biaya, dan persetujuan yang telah disepakati. Mencampur keduanya menimbulkan kebingungan ketika ruang lingkup berubah setelah panggilan pertama.

Siapkan alur intake langkah demi langkah

Aplikasi intake yang jelas harus membawa setiap permintaan melewati rangkaian keputusan kecil yang sama. Staf harus dapat melihat siapa penanggung jawabnya, apa yang perlu ditinjau, dan kapan seseorang harus bertindak.

Mulai dengan catatan permintaan

Buat satu catatan untuk setiap potensi pekerjaan. Sertakan nomor referensi, nama klien atau organisasi, layanan yang diminta, dan pengirim. Tetapkan status awal «Baru» agar tim dapat membedakan pekerjaan yang belum ditinjau dari permintaan aktif.

Gunakan status yang menggambarkan titik keputusan nyata:

• Baru: perusahaan menerima permintaan, tetapi belum ada yang meninjaunya.
• Sedang ditinjau: seseorang sedang memeriksa ruang lingkup, kontak, dan konflik.
• Menunggu klien: tim membutuhkan detail yang belum diberikan.
• Disetujui: perusahaan dapat menyiapkan proposal atau membuka proyek.
• Ditolak: perusahaan tidak akan menerima pekerjaan tersebut.

Buat daftarnya singkat. Jika staf tidak dapat memilih status dalam beberapa detik, labelnya perlu diperbaiki.

Teruskan, tugaskan, dan beri tahu

Setelah seseorang membuat permintaan, teruskan berdasarkan detail yang sudah dikumpulkan. Permintaan pajak dapat diteruskan kepada manajer pajak, sedangkan perkara ketenagakerjaan dapat diteruskan kepada peninjau lain. Perusahaan dengan beberapa kantor juga dapat meneruskan permintaan berdasarkan lokasi.

Berikan tenggat kepada peninjau dan tetapkan satu orang sebagai penanggung jawab langkah berikutnya. Kotak masuk tim bersama membantu visibilitas, tetapi tidak menciptakan tanggung jawab.

Notifikasi harus selalu mengarah pada tindakan, seperti «Selesaikan pemeriksaan konflik» atau «Minta detail anggaran». Beri tahu peninjau tentang penugasan baru, kemudian beri tahu koordinator intake jika tenggat terlewati.

Serahkan pekerjaan yang disetujui ke proses berikutnya

Ketika perusahaan menyetujui permintaan, pertahankan informasi yang sudah dikumpulkan. Daftar kontak, ringkasan proyek, kisaran anggaran, dan catatan peninjauan harus berpindah ke catatan proposal atau proyek aktif. Staf tidak perlu mengetik ulang fakta yang sama di formulir lain.

Platform tanpa kode seperti AppMaster dapat membuat alur ini dengan formulir permintaan, bidang status, aturan bisnis, dan layar berbasis peran. Serah terima dapat membuat catatan proposal dan menetapkan penanggung jawabnya secara otomatis, sementara catatan intake asli menyimpan riwayat persetujuan.

Uji alur tersebut dengan permintaan yang realistis sebelum membagikannya kepada klien. Sertakan satu permintaan dengan detail yang kurang, satu dengan kemungkinan konflik, dan satu yang menerima persetujuan. Kasus-kasus ini membantu menemukan status yang tidak jelas, aturan penerusan yang kurang, dan notifikasi yang dikirim kepada orang yang salah.

Contoh: dari kontak pertama hingga serah terima

Sebuah perusahaan konsultan menerima email dari Maya Chen, direktur operasional di Northline Foods. Perusahaannya berencana melakukan ekspansi regional dan ingin mendapatkan bantuan untuk menilai pasar baru, pemasok, serta biaya operasional. Alih-alih meneruskan email ke berbagai orang, koordinator membuka satu catatan intake.

Koordinator menambahkan Maya sebagai kontak utama, kemudian menambahkan manajer keuangan Northline, yang akan menyetujui pengeluaran, serta manajer proyek yang akan menangani pertanyaan sehari-hari. Formulir intake mencatat wilayah ekspansi, tujuan bisnis, target peluncuran, dan batasan awal. Maya memasukkan 30 September sebagai target, memberikan kisaran anggaran kerja sebesar $75.000 sampai $100.000, dan mencatat bahwa perusahaan harus menyampaikan rekomendasi awal dalam waktu empat minggu.

Sebelum siapa pun menjadwalkan panggilan penemuan kebutuhan, aplikasi mengirimkan permintaan kepada peninjau konflik. Peninjau memeriksa pekerjaan klien saat ini dan sebelumnya yang berkaitan dengan distributor makanan pesaing, pemasok, dan proyek masuk pasar di wilayah yang sama. Mereka mencatat hasil dan batasan pekerjaan apa pun dalam catatan intake.

Jika peninjau menyatakan permintaan tidak bermasalah, koordinator memindahkannya ke «Siap untuk penemuan kebutuhan». Jika peninjau membutuhkan masukan hukum atau pimpinan, permintaan tetap berada dalam status peninjauan yang sesuai dan tim dapat melihat alasan panggilan belum dijadwalkan. Dengan begitu, percakapan penjualan yang sudah siap berjalan tidak mendahului proses pemeriksaan konflik.

Koordinator kemudian menugaskan pimpinan praktik yang berpengalaman dalam ekspansi ritel dan rantai pasokan. Pimpinan tersebut menerima permintaan lengkap, termasuk kontak klien, hasil yang diharapkan, tenggat, kisaran anggaran, dan keputusan konflik. Setelah panggilan penemuan kebutuhan, pimpinan memperbarui catatan yang sama dengan catatan ruang lingkup dan keputusan proposal.

Aplikasi yang dibangun dengan AppMaster dapat menyimpan formulir, status peninjauan, penugasan, dan pekerjaan tindak lanjut dalam satu aplikasi tanpa kode, bukan memisahkannya antara rangkaian email dan spreadsheet.

Kesalahan intake yang umum dan perlu dihindari

Aplikasi intake seharusnya mempermudah peninjauan awal, bukan menciptakan pekerjaan kedua. Sebagian besar masalah muncul karena pertanyaan yang tidak jelas, kewenangan yang tidak tegas, atau permintaan yang menghilang setelah dikirim.

Meminta terlalu banyak terlalu cepat

Bidang teks bebas yang panjang membuat peninjauan berjalan lambat dan hasilnya tidak seragam. Jika staf membutuhkan jenis layanan, tingkat urgensi, industri, atau perkiraan tanggal mulai, sediakan daftar pilihan singkat jika memungkinkan. Simpan satu bidang catatan opsional untuk detail yang tidak sesuai dengan pilihan.

Kategori layanan, jenis perkara, tenggat, kisaran anggaran, dan ringkasan singkat memberi peninjau titik awal yang lebih rapi daripada satu pertanyaan yang terlalu luas. Alur kerja intake klien dapat mengumpulkan detail lanjutan setelah perusahaan mengetahui bahwa permintaan tersebut sesuai.

Membiarkan keputusan tanpa penanggung jawab

Tetapkan satu orang untuk setiap permintaan baru. Orang tersebut harus meninjaunya, memajukannya, atau menjelaskan mengapa perusahaan tidak akan menerimanya. Aplikasi harus menampilkan nama orang tersebut dan status saat ini.

Keputusan konflik membutuhkan pengendalian yang lebih ketat. Anggota tim dapat menandai kemungkinan konflik dan menambahkan kontak yang relevan, tetapi hanya peninjau berwenang yang boleh menyatakan permintaan tidak bermasalah, menolaknya, atau meminta informasi tambahan. Catat keputusan, peninjau, tanggal, dan catatan.

Jangan menganggap formulir intake proyek yang telah dikirim sebagai pekerjaan yang disetujui. Pengiriman berarti perusahaan telah menerima informasi. Persetujuan membutuhkan perubahan status terpisah setelah peninjauan konflik, pembahasan ruang lingkup, dan pemeriksaan internal yang diperlukan.

Mempertahankan pertanyaan lama selamanya

Formulir cenderung bertambah panjang karena setiap pertanyaan baru terlihat masuk akal. Setelah beberapa bulan, formulir menjadi panjang dan orang mulai melewati bidang atau memberikan jawaban terburu-buru. Tinjau bidang secara berkala bersama orang yang menilai permintaan dan orang yang menggunakan data setelah serah terima.

Hapus pertanyaan yang tidak digunakan untuk mengambil keputusan, meneruskan pekerjaan, memeriksa konflik, atau menyiapkan proposal. Jika bidang hanya berlaku untuk satu area praktik, tampilkan bidang tersebut hanya ketika pengirim memilih area itu. AppMaster mendukung alur bersyarat yang menjaga layar tetap sederhana bagi pengguna lain.

Formulir singkat dengan penanggung jawab yang jelas menghasilkan informasi yang lebih baik daripada formulir terperinci yang diisi dengan terburu-buru.

Pemeriksaan singkat sebelum peluncuran

Sebelum membagikan aplikasi intake ke seluruh perusahaan, pastikan formulir mengumpulkan konteks yang cukup untuk peninjauan awal yang terinformasi: kebutuhan klien, area layanan, lokasi atau yurisdiksi yang relevan, waktu, kisaran anggaran, dan detail kontak utama.

Buka permintaan uji dan ikuti alurnya seperti seorang peninjau. Proses pemeriksaan konflik membutuhkan status yang terlihat, peninjau yang ditunjuk, dan keputusan yang tercatat. Setiap permintaan juga membutuhkan satu penanggung jawab saat ini dan tenggat. Penanggung jawab dapat berubah ketika pekerjaan berpindah dari pengembangan bisnis ke pimpinan praktik atau tim pelaksana, tetapi aplikasi harus selalu menunjukkan siapa yang bertindak berikutnya.

Gunakan kasus uji yang realistis dengan beberapa kontak, tenggat ketat, kemungkinan konflik, dan anggaran yang belum lengkap. Periksa apakah aplikasi meneruskannya kepada peninjau yang tepat, menghalangi serah terima sebelum konflik dinyatakan selesai, dan menyimpan catatan dalam catatan yang sama. Minta staf mencoba alurnya, lalu perbaiki label yang membingungkan dan bidang yang tidak diperlukan.

Untuk aplikasi intake yang membutuhkan lebih dari sekadar formulir intake proyek dasar, AppMaster menyediakan satu ruang kerja tanpa kode untuk formulir, aturan bisnis, serta akses web atau seluler. Tim dapat memodelkan catatan permintaan dan kontak, membuat langkah peninjauan di Business Process Editor visual, serta menghasilkan aplikasi tanpa harus memelihara spreadsheet terpisah.

Mulailah dengan alur terkecil yang dapat diikuti tim secara konsisten. Tambahkan bidang dan aturan hanya jika staf dapat menjelaskan pengaruhnya terhadap keputusan atau tindakan berikutnya.