Buat aplikasi pengajuan perjalanan dengan batas persetujuan

Mengapa pengajuan perjalanan tim sering tertunda

Pengajuan perjalanan biasanya dimulai dengan beberapa detail sederhana: tanggal, tujuan, dan perkiraan biaya. Setelah itu, informasinya tersebar di email, chat, dan spreadsheet. Karyawan mengirim pilihan penerbangan melalui email, menambahkan biaya hotel ke spreadsheet, lalu menyebutkan rapat dengan klien di chat. Manajer hanya melihat sebagian pengajuan dan harus meminta informasi lainnya.

Celah kecil seperti ini menimbulkan keterlambatan. Harga dapat berubah saat seseorang mencari lampiran. Tim keuangan tidak tahu apakah total biaya sudah mencakup bagasi, transportasi lokal, atau pajak hotel. Pelancong mungkin memesan sebelum mendapat persetujuan karena harga tiket akan segera naik.

Email juga menyulitkan tim untuk mengetahui versi terbaru. Karyawan dapat memperbarui rencana perjalanan setelah manajer menyetujuinya, sementara persetujuan masih mengacu pada perkiraan sebelumnya. Spreadsheet bersama memang meningkatkan visibilitas, tetapi biasanya tidak mencatat siapa yang menyetujui biaya, kapan persetujuan diberikan, atau apa yang berubah setelahnya.

Batas persetujuan yang tidak jelas juga sering menyebabkan keterlambatan. Manajer mungkin menyetujui perjalanan senilai $900 tanpa mengetahui bahwa tim keuangan harus meninjau perjalanan di atas $750. Sebaliknya, karyawan mungkin mengirim semua pengajuan kepada kepala departemen, padahal manajer langsungnya dapat memberikan persetujuan. Kedua pendekatan ini memperlambat proses dan menghasilkan keputusan yang tidak konsisten.

Pengecualian kebijakan perlu terlihat sama jelasnya dengan detail perjalanan. Penerbangan yang terlambat, tarif hotel yang lebih tinggi di dekat lokasi klien, atau perjalanan mendadak bisa saja masuk akal. Masalah muncul ketika penjelasannya berada di pesan terpisah atau tidak pernah dicatat. Akibatnya, tim keuangan menemukan tanda terima yang melebihi anggaran tanpa mengetahui alasan keputusan tersebut.

Aplikasi pengajuan perjalanan yang praktis menyimpan keputusan dalam satu catatan. Setiap pengajuan sebaiknya mencakup perkiraan rencana perjalanan, tujuan bisnis, total yang diharapkan, alasan pengecualian bila diperlukan, dan riwayat persetujuan. Setelah perjalanan selesai, catatan yang sama dapat memuat tautan pelacakan pengeluaran sehingga tim dapat membandingkan pengeluaran aktual dengan rencana yang disetujui.

Tujuannya sederhana: memberi pelancong alur yang jelas, memberi pemberi persetujuan informasi yang dibutuhkan, dan memberi tim keuangan catatan yang dapat diperiksa tanpa mencari-cari di kotak masuk.

Tentukan tanggung jawab sebelum mulai membangun

Aplikasi pengajuan perjalanan bekerja paling baik ketika setiap orang memiliki tanggung jawab yang jelas. Mulailah dengan karyawan yang merencanakan perjalanan, manajer yang menilai kebutuhan bisnisnya, dan tim keuangan yang meninjau anggaran serta kebijakan. Beberapa tim juga memerlukan koordinator perjalanan untuk memesan perjalanan yang sudah disetujui atau pemberi persetujuan eksekutif untuk pengeluaran besar.

Jaga agar setiap peran tetap fokus. Karyawan membuat pengajuan dan menambahkan tanggal, tujuan, perkiraan biaya, serta alasan bisnis. Manajer menyetujui, menolak, atau meminta perubahan. Tim keuangan meninjau pengajuan yang melebihi batas pengeluaran, melanggar kebijakan, atau memerlukan penanganan pembayaran khusus. Setelah perjalanan selesai, pelancong menambahkan catatan pengeluaran atau tautan tanda terima.

Tentukan apa yang boleh berubah setelah pengajuan dikirim

Karyawan sering perlu memperbaiki perkiraan penerbangan atau mengubah tanggal rapat. Biarkan mereka mengedit draf dengan bebas, lalu terapkan aturan yang jelas setelah pengajuan dikirim. Perubahan kecil sebelum persetujuan tidak menjadi masalah. Jika total perkiraan, tujuan, atau tanggal perjalanan berubah setelah persetujuan, kirim kembali pengajuan untuk ditinjau.

Sebagai contoh, karyawan mengajukan perjalanan senilai $900 ke Chicago dan manajer menyetujuinya. Jika perkiraan naik menjadi $1.450 karena harga tiket meningkat, aplikasi harus memberi tahu manajer dan menyimpan jumlah sebelumnya beserta alasan perubahan.

Jangan biarkan karyawan mengubah pengajuan yang sudah disetujui tanpa pemberitahuan. Tim keuangan perlu membandingkan anggaran yang disetujui dengan catatan pengeluaran akhir, dan perubahan yang tidak terlihat membuat perbandingan itu tidak dapat diandalkan.

Tetapkan batas persetujuan yang jelas

Tuliskan batas persetujuan sebelum membuat formulir atau otomatisasi. Dasarkan batas tersebut pada biaya perjalanan, departemen, atau keduanya. Manajer penjualan dapat menyetujui kunjungan rutin ke klien, sementara tim keuangan meninjau perjalanan internasional atau pengajuan di atas jumlah tertentu.

Kebijakan sederhana dapat dibuat seperti ini:

• Manajer menyetujui perjalanan hingga $1.000 untuk departemennya.
• Kepala departemen menyetujui pengajuan antara $1.001 dan $3.000.
• Tim keuangan meninjau pengajuan di atas $3.000, perjalanan internasional, dan pengecualian kebijakan.
• Eksekutif menyetujui perjalanan yang melebihi anggaran departemen.

Sesuaikan batas ini dengan cara perusahaan mengambil keputusan pengeluaran saat ini. Perusahaan kecil biasanya tidak memerlukan lima tingkat persetujuan. Jika proses terlalu lambat, orang akan mencari jalan lain.

Dalam aplikasi perjalanan tanpa kode yang dibuat dengan AppMaster, Anda dapat menyimpan departemen, manajer, dan batas persetujuan setiap karyawan di dalam model data. Alur kerja kemudian dapat mengarahkan pengajuan berdasarkan perkiraan dan detail perjalanan. Tim keuangan hanya melihat pengajuan yang memerlukan perhatian, sementara perjalanan rutin dapat diproses lebih cepat.

Tentukan juga siapa yang dapat membatalkan penolakan, membatalkan perjalanan yang sudah disetujui, atau mengambil alih ketika manajer sedang tidak ada. Aturan kecil ini mencegah pengajuan terabaikan sebelum batas waktu pemesanan.

Pilih kolom untuk setiap pengajuan perjalanan

Aplikasi pengajuan perjalanan memerlukan detail yang cukup untuk mengambil keputusan dengan cepat, tanpa mengubah perjalanan singkat menjadi formulir yang panjang. Mulailah dengan informasi yang menjelaskan siapa yang bepergian, ke mana tujuannya, dan mengapa perjalanan itu diperlukan.

Letakkan nama pelancong dan tim di bagian atas. Jika seseorang mengajukan perjalanan atas nama karyawan lain, sertakan kolom untuk pemohon dan pelancong. Catat tujuan sebagai kota dan negara, bukan kalimat bebas, agar tim keuangan dapat mengelompokkan perjalanan nantinya. Tujuan yang spesifik juga membantu, misalnya "Bertemu klien untuk merencanakan peluncuran bulan Mei" memberi manajer lebih banyak konteks daripada "Rapat dengan klien".

Wajibkan tanggal keberangkatan dan kepulangan. Tambahkan kolom waktu hanya jika tim memerlukannya untuk pemesanan atau aturan uang harian. Aplikasi dapat menghitung jumlah malam, sehingga pemberi persetujuan mendapat konteks penting sebelum membuka pengajuan lengkap.

Pisahkan perkiraan biaya

Gunakan kolom angka terpisah untuk transportasi, hotel, dan makanan. Satu total biaya akan menyembunyikan penggunaan dana dan menyulitkan perbandingan dengan kebijakan perjalanan bisnis. Tambahkan transportasi lokal jika taksi, mobil sewaan, atau kereta menimbulkan biaya yang berarti.

Hitung total perkiraan secara otomatis. Pelancong yang pergi ke Berlin selama dua malam dapat memasukkan $320 untuk penerbangan, $440 untuk hotel, $120 untuk makanan, dan $60 untuk transportasi lokal. Pengajuan akan menampilkan perkiraan $940, sementara setiap biaya tetap terlihat.

Gunakan mata uang yang diharapkan oleh tim keuangan. Untuk perjalanan internasional, tambahkan mata uang yang diminta dan perkiraan yang dikonversi ke mata uang utama perusahaan. Dengan begitu, manajer tidak menyetujui angka 900 tanpa mengetahui apakah itu dolar, euro, atau pound.

Tambahkan bukti dan konteks bila diperlukan

Sediakan area lampiran untuk penawaran penerbangan atau hotel, undangan acara, dan agenda klien. Kolom catatan dapat menampung detail yang tidak sesuai dengan kolom standar, seperti hotel konferensi yang wajib digunakan atau rapat yang tanggalnya berubah.

Jadikan catatan bersifat opsional, tetapi wajibkan lampiran ketika pengajuan melebihi batas biaya atau mencakup pengecualian. Tampilkan hanya kolom yang relevan saat karyawan mengisi formulir. Dengan begitu, pengajuan rutin tetap singkat.

Jangan meminta tanda terima sebelum perjalanan. Sebagai gantinya, sediakan kolom tautan pengeluaran pascaperjalanan yang dapat dilengkapi oleh tim keuangan atau pelancong setelah perjalanan selesai. Kolom ini menghubungkan pengajuan yang disetujui dengan catatan pengeluaran akhir.

Tangani pengecualian kebijakan secara terbuka

Aplikasi harus menampilkan pengecualian kebijakan sejak awal, bukan menyembunyikannya di komentar atau baru menemukannya setelah seseorang memesan penerbangan. Karyawan tetap dapat meminta pengecualian, tetapi pelancong dan pemberi persetujuan harus melihat tambahan biaya atau pelanggaran aturan dengan jelas.

Tuliskan aturan dalam bahasa sederhana. Hindari label samar seperti "harga tiket yang wajar". Sebutkan batas dan kondisinya: penerbangan kelas ekonomi untuk perjalanan di bawah enam jam, kamar hotel hingga $220 per malam, dan perjalanan kereta ketika biayanya lebih rendah daripada penerbangan singkat. Letakkan catatan kebijakan singkat di samping kolom terkait.

Bandingkan biaya yang dimasukkan dengan aturan kebijakan. Jika pelancong memasukkan tarif hotel $310 per malam sementara batasnya $220, tampilkan selisihnya dan wajibkan alasan sebelum pengajuan dikirim. Kolom alasan khusus lebih baik daripada kotak catatan umum, karena orang sering lupa menjelaskan pengecualian di sana.

Gunakan beberapa pilihan alasan, dengan ruang untuk detail:

• Tidak ada pilihan yang sesuai dalam batas kebijakan
• Lokasi klien atau jadwal rapat mengharuskan pilihan ini
• Kebutuhan aksesibilitas atau medis
• Kekhawatiran terkait keselamatan
• Alasan lain, dengan penjelasan tertulis

Pengecualian yang berbeda memerlukan peninjau yang berbeda. Manajer biasanya dapat menyetujui tarif hotel yang lebih tinggi ketika rapat dengan klien memang memerlukannya. Tim keuangan harus meninjau pengecualian yang memengaruhi anggaran, perlakuan pajak, penggantian biaya, atau batas pengeluaran departemen. Alur kerja persetujuan perjalanan harus mengarahkan pengajuan sesuai kebutuhan, bukan meminta setiap pemberi persetujuan menilai semua aturan.

Sebagai contoh, karyawan dapat mengunjungi klien saat konferensi besar berlangsung, ketika hotel di sekitar lokasi melebihi batas normal. Pengajuan dapat menampilkan batas standar, tarif yang dipilih, tambahan biaya per malam, dan penjelasan karyawan. Manajer memutuskan apakah perjalanan itu diperlukan. Tim keuangan hanya meninjaunya jika pengecualian melewati batas dalam kebijakan perjalanan bisnis.

Pertahankan detail pengecualian agar tetap terlihat setelah pengajuan dikirim. Tampilkan detail tersebut di layar persetujuan, riwayat persetujuan, dan di samping tautan pelacakan pengeluaran pascaperjalanan. Jika pengeluaran akhir berbeda dari perkiraan, tim dapat melihat alasan persetujuan awal mengizinkan biaya yang lebih tinggi.

Buat batas persetujuan yang mudah diikuti

Karyawan harus dapat memperkirakan jalur pengajuan sebelum mengirimkannya. Dasarkan jalur pada total perkiraan biaya perjalanan, bukan hanya harga penerbangan. Sertakan penginapan, transportasi lokal, biaya pendaftaran, dan perkiraan makanan yang wajar. Penerbangan seharga $450 dapat menjadi perjalanan senilai $1.600 setelah semua biaya lain ditambahkan.

Tampilkan batas tersebut di dalam aplikasi agar karyawan memahami alasan satu pengajuan dikirim ke manajer, sedangkan pengajuan lain dikirim ke tim keuangan. Contohnya:

• Pengajuan hingga $750 dikirim kepada manajer langsung.
• Pengajuan antara $751 dan $2.500 dikirim kepada manajer dan kepala departemen.
• Pengajuan di atas $2.500 dikirim kepada manajer, kepala departemen, dan tim keuangan.
• Semua pengajuan di luar kebijakan dikirim kepada tim keuangan, berapa pun biayanya.

Gunakan detail departemen dan manajer pemohon untuk memilih peninjau secara otomatis. Orang tidak perlu mencari daftar panjang atau menebak siapa yang bertanggung jawab atas keputusan berikutnya. Jika manajer sedang tidak ada, tetapkan manajer pengganti dengan peran persetujuan yang sama.

Peninjauan oleh tim keuangan harus mencakup lebih dari sekadar total yang tinggi. Tim keuangan mungkin juga perlu meninjau kursi premium, tujuan internasional, mata uang lain, atau pemesanan yang melanggar aturan pembelian lebih awal. Minta pemohon menjelaskan pengecualian dalam satu atau dua kalimat yang langsung pada intinya.

Catat setiap keputusan beserta nama peninjau, keputusan, tanggal dan waktu, serta komentar. Wajibkan komentar untuk penolakan dan pengecualian kebijakan. Catatan seperti "Disetujui karena klien memindahkan rapat ke hari Senin" akan membantu karyawan dan tim keuangan di kemudian hari.

Simpan batas dalam tabel kebijakan yang dapat diedit, bukan menyembunyikannya di dalam logika alur kerja. Tim operasional dapat mengubah ambang batas ketika anggaran berubah. Hubungkan pengajuan lama dengan aturan yang berlaku saat peninjau mengambil keputusan, agar riwayat persetujuan tetap jelas.

Bangun alur kerja langkah demi langkah

Berikan status yang jelas untuk setiap pengajuan. Karyawan harus tahu posisi perjalanan mereka tanpa memeriksa pesan atau bertanya kepada tim keuangan. Alur sederhana sudah cukup: Draf, Dikirim, Perlu perubahan, Disetujui, Dipesan, Selesai, dan Ditolak.

Karyawan membuat pengajuan dalam status Draf dan dapat mengeditnya dengan bebas. Saat mengirimkannya, aplikasi mencatat tanggal dan mengirim pengajuan kepada manajer yang tepat. Manajer dapat menyetujui, menolak, atau mengembalikannya dengan komentar. Simpan keputusan dan komentar sebelumnya di dalam catatan agar konteks tidak hilang.

Gunakan satu formulir pengajuan yang hanya berubah ketika informasi tambahan diperlukan. Setiap pengajuan memerlukan pelancong, tujuan, tanggal, tujuan bisnis, perkiraan transportasi, perkiraan penginapan, dan total biaya. Tambahkan kolom tautan penawaran atau lampiran jika karyawan memiliki dokumen pendukung.

Jika perkiraan hotel melebihi batas perusahaan, tampilkan kolom untuk aturan kebijakan, jumlah yang melebihi batas, dan penjelasan singkat. Karyawan harus menjelaskan masalah tersebut sebelum manajer menerima pengajuan.

Simpan detail persetujuan dalam catatan yang sama: jumlah yang disetujui, tanggal keputusan, nama pemberi persetujuan, komentar, dan ketentuan. Manajer mungkin menyetujui perjalanan senilai $1.200 tetapi meminta karyawan memilih penerbangan yang lebih murah. Masukkan ketentuan tersebut ke dalam pengajuan, bukan meninggalkannya di utas chat.

Pisahkan tampilan agar pekerjaan tetap fokus. Karyawan memerlukan draf, pengajuan, keputusan, dan tautan pengeluaran mereka. Manajer memerlukan pengajuan yang menunggu keputusan, perkiraan biaya, pengecualian, dan batas persetujuan. Tim keuangan memerlukan perjalanan yang disetujui, perkiraan pengeluaran, status pemesanan, dan catatan pengeluaran pascaperjalanan.

AppMaster dapat mendukung struktur ini dengan pembuat UI visual, model data PostgreSQL, dan proses bisnis yang memeriksa jumlah, mengarahkan pengajuan, serta memperbarui status. Batasi hak edit berdasarkan peran. Karyawan tidak boleh mengubah total yang sudah disetujui tanpa peninjauan ulang, sedangkan tim keuangan dapat menambahkan tautan pelacakan pengeluaran dan menandai pengajuan sebagai Selesai setelah penyelesaian.

Dengan begitu, catatan yang sama mengikuti perjalanan sejak perkiraan awal hingga laporan pengeluaran akhir.

Contoh: kunjungan klien dengan pengecualian

Maya perlu mengunjungi klien selama dua hari. Ia memasukkan tanggal, tujuan, nama klien, dan tujuan bisnis. Aplikasi meminta perkiraan biaya penerbangan, hotel, transportasi lokal, dan makanan, lalu menghitung total $1.860.

Manajernya dapat menyetujui perjalanan hingga $1.500. Karena perkiraan Maya melebihi batas tersebut, alur kerja mengirim pengajuan kepada manajernya untuk rekomendasi, lalu kepada direktur departemen untuk keputusan akhir. Kedua peninjau dapat melihat alasan persetujuan kedua diperlukan.

Maya memilih hotel di dekat kantor klien. Tarif per malamnya $25 di atas batas kebijakan, tetapi hotel yang lebih murah akan menambah waktu perjalanan 45 menit sekali jalan dan tidak dapat mendukung kedatangannya yang terlambat. Aplikasi mewajibkan catatan pengecualian sebelum pengajuan dikirim. Ia menulis: "Lokakarya klien dimulai pukul 08.00 pada kedua hari. Hotel ini dapat dicapai dengan berjalan kaki dan mendukung kedatangan larut setelah penerbangan malam."

Manajer melihat ringkasan biaya, batas persetujuan, dan penjelasan hotel di satu tempat. Manajer menyetujui pengajuan dan menambahkan catatan untuk direktur: "Lokakarya klien membutuhkan awal yang lebih pagi. Merekomendasikan persetujuan."

Direktur menerima pengajuan yang ditandai sebagai melebihi batas dengan pengecualian kebijakan. Setelah disetujui, aplikasi mencatat keputusan, nama pemberi persetujuan, stempel waktu, dan komentar. Maya melihat status yang jelas tanpa harus mengejar persetujuan melalui email.

Setelah perjalanan selesai, Maya menambahkan tautan tanda terima penerbangan, faktur hotel, dan laporan pengeluaran. Ia memasukkan total akhir $1.792. Tim dapat membandingkan perkiraan dengan pengeluaran aktual dan melihat bahwa pengecualian hotel yang disetujui menambah $50, sementara biaya penerbangan lebih rendah dari perkiraan.

Tim keuangan dapat meninjau laporan pengeluaran tanpa membuka kembali seluruh pembahasan. Manajer juga dapat melihat seberapa sering staf meminta pengecualian, perjalanan mana yang melebihi batas, dan apakah perkiraan sesuai dengan biaya akhir.

Kesalahan yang menyebabkan masalah persetujuan

Aturan persetujuan tidak akan berjalan baik jika mengabaikan cara tim bepergian sebenarnya. Manajer penjualan mungkin perlu menyetujui kunjungan klien senilai $1.800, sementara pemimpin tim dukungan menangani perjalanan domestik singkat di bawah $500. Satu batas untuk semua departemen dapat membuat pengajuan rutin terlalu lama menunggu atau mengirim pengajuan mahal kepada orang yang tidak memiliki kewenangan anggaran yang tepat.

Tetapkan batas berdasarkan departemen, peran, jenis perjalanan, atau gabungan beberapa faktor jika diperlukan. Jaga versi pertama tetap sederhana. Pemimpin tim dapat menyetujui perjalanan hingga $750, kepala departemen hingga $2.500, dan tim keuangan menangani jumlah di atas itu.

Lindungi angka yang sudah disetujui. Jika karyawan mengubah perkiraan penerbangan dari $420 menjadi $690 setelah persetujuan, kirim kembali pengajuan untuk ditinjau. Jika tidak, manajer menyetujui satu jumlah sementara perusahaan membayar jumlah yang berbeda.

Lakukan peninjauan ulang ketika:

• Perkiraan naik melebihi jumlah yang disetujui.
• Perubahan suatu item membuat perjalanan masuk ke tingkat persetujuan yang lebih tinggi.
• Pelancong menambahkan pengecualian kebijakan setelah persetujuan.
• Tujuan, tanggal, atau tujuan bisnis berubah.

Jangan mengandalkan catatan bebas untuk pengecualian. Komentar seperti "pemesanan terlambat" tidak memberi tahu manajer aturan kebijakan mana yang dilanggar. Berikan kolom khusus untuk pengecualian: jenis, alasan, biaya tambahan, dan penjelasan singkat. Aplikasi dapat menampilkan pengecualian di samping total rencana perjalanan, bukan menyembunyikannya di dalam utas.

Jangan menutup perjalanan segera setelah pelancong pulang. Biarkan statusnya terbuka sampai pelancong menambahkan tautan pelacakan pengeluaran atau mengonfirmasi bahwa tidak ada pengeluaran yang tersisa. Jika karyawan mendapat persetujuan untuk perjalanan konferensi senilai $900 lalu mengajukan pengeluaran $1.040, aplikasi harus mencatat selisihnya dan mengirimkannya kepada pihak yang bertanggung jawab untuk meninjau. Status seperti "Menunggu tautan pengeluaran" menjaga pengajuan tetap terlihat.

Periksa aplikasi sebelum diluncurkan

Uji aplikasi bersama orang-orang yang akan mengirim, menyetujui, dan meninjau perjalanan. Layar dapat terlihat lengkap, tetapi tetap mengarahkan pengajuan kepada orang yang salah atau menyembunyikan detail biaya yang dibutuhkan tim keuangan.

Setiap pengajuan memerlukan satu pelancong atau pemilik yang namanya jelas, bahkan ketika asisten mengisinya untuk orang lain. Orang tersebut harus menerima pembaruan status dan memberikan detail yang belum lengkap. Dengan begitu, kebingungan dapat dihindari ketika manajer menanyakan tanggal, tujuan, atau perkiraan yang diperbarui.

Uji batas persetujuan dengan angka yang realistis. Buat satu pengajuan di bawah batas manajer, satu tepat di atasnya, dan satu jauh di atasnya. Peninjau harus melihat total perkiraan, aturan yang memicu peninjauan, dan keputusan sebelumnya.

Gunakan daftar periksa singkat sebelum peluncuran:

• Kirim perjalanan standar dan pastikan manajer yang tepat menerimanya.
• Kirim pengecualian kebijakan dan pastikan alasannya tetap terlihat.
• Tolak pengajuan dengan komentar, lalu pastikan pelancong dapat memperbaiki dan mengirimkannya kembali.
• Tambahkan folder tanda terima pascaperjalanan atau URL laporan pengeluaran dan pastikan tim keuangan dapat mengaksesnya.
• Periksa apa yang dapat dilihat dan diedit oleh pelancong, manajer, staf keuangan, dan administrator.

Pemeriksaan izin memerlukan perhatian khusus. Pelancong mungkin memerlukan akses ke rencana perjalanan dan perkiraan miliknya, sementara manajer memerlukan pengajuan timnya. Tim keuangan mungkin memerlukan biaya dan tautan pengeluaran, tetapi tidak memerlukan catatan pribadi yang tidak berkaitan dengan penggantian biaya. Administrator memerlukan akses yang cukup untuk memperbaiki kesalahan pengarah, tanpa menjadi pemberi persetujuan default.

Coba perjalanan klien selama dua hari dengan perkiraan penerbangan $480, perkiraan hotel $360, dan anggaran transportasi lokal $150. Lalu ubah perkiraan hotel menjadi $620 dan tandai sebagai pengecualian. Aplikasi harus menyimpan detail biaya dan penjelasannya, mengarahkan pengajuan sesuai total yang lebih tinggi, serta mencatat keputusan akhir.

Jika Anda membuat aplikasi dengan AppMaster, uji kasus-kasus ini dalam versi yang akan digunakan tim. Logika visualnya dapat mengarahkan pengajuan berdasarkan jumlah, departemen, atau status pengecualian, sementara kontrol akses berbasis peran menentukan siapa yang dapat melihat setiap kolom. Uji coba dengan lima orang biasanya menemukan label yang membingungkan dan celah pengarah lebih cepat daripada tinjauan internal yang panjang.

Mulai dari skala kecil dan tingkatkan proses

Mulailah dengan satu tim, seperti tim penjualan atau dukungan pelanggan, dan beberapa aturan singkat. Versi pertama hanya memerlukan detail yang menentukan apakah perjalanan dapat dilanjutkan: pelancong, tujuan, tanggal, tujuan, perkiraan biaya, dan persetujuan manajer.

Buat batas pertama yang mudah dijelaskan. Manajer dapat menyetujui perjalanan hingga $1.500, sementara kepala departemen meninjau jumlah yang lebih tinggi. Kirim pengajuan di luar kebijakan, seperti penerbangan premium atau pemesanan terlambat, kepada peninjau yang tepat dengan catatan pengecualian.

Hindari menambahkan semua kolom yang mungkin diperlukan pada hari pertama. Formulir yang panjang membuat orang kembali ke email dan menghidupkan lagi masalah pelacakan yang seharusnya diselesaikan aplikasi.

Setelah beberapa pengajuan pertama, tanyakan kepada pelancong dan pemberi persetujuan di bagian mana mereka berhenti atau perlu mengajukan pertanyaan. Jawaban mereka biasanya menunjukkan kolom yang belum tersedia, batas biaya yang tidak jelas, atau langkah persetujuan yang tidak sesuai dengan proses tim sebenarnya.

Perbaikan awal biasanya mencakup penambahan kolom klien atau proyek, pemisahan perkiraan penerbangan dan hotel, kewajiban mengisi alasan pengecualian, penyesuaian batas persetujuan, atau penambahan tautan laporan pengeluaran setelah perjalanan.

Jika memungkinkan, lakukan satu perubahan pada satu waktu. Jika sepuluh aturan berubah bersamaan, akan sulit mengetahui perubahan mana yang menyelesaikan masalah atau menimbulkan keterlambatan baru. Setelah satu bulan, tinjau pengajuan yang tertunda dan ditolak. Cari pengecualian yang berulang, pengajuan yang lama menunggu satu pemberi persetujuan, dan perkiraan yang sering berbeda dari biaya akhir.

AppMaster membantu tim membuat aplikasi perjalanan tanpa kode dengan formulir, persetujuan, dan pelaporan dalam satu aplikasi. Mulailah dengan formulir pengajuan dan aturan persetujuan yang dibutuhkan tim saat ini, lalu tambahkan vendor pilihan, laporan anggaran, atau tautan pelacakan pengeluaran langsung hanya ketika fitur tersebut menyelesaikan masalah nyata.