Onay limitleri olan bir seyahat talep uygulaması oluşturun

Ekip seyahati talepleri neden takılır?

Bir seyahat talebi genellikle birkaç basit ayrıntıyla başlar: tarihler, varış noktası ve tahmini maliyet. Sonra bilgiler e-postalara, sohbetlere ve elektronik tablolara dağılır. Çalışan uçuş seçeneklerini e-postayla gönderir, otel maliyetlerini bir tabloya ekler ve müşteri toplantısından sohbette bahseder. Yönetici talebin yalnızca bir bölümünü görür ve geri kalanını istemek zorunda kalır.

Bu küçük boşluklar gecikmelere yol açar. Birisi ek dosya ararken fiyatlar değişir. Finans ekibi toplam tutara bagaj, yerel ulaşım veya otel vergisinin dahil olup olmadığını anlayamaz. Ücret yükselmek üzereyken çalışan onay gelmeden rezervasyon yapabilir.

E-posta, güncel sürümü belirlemeyi de zorlaştırır. Bir çalışan, yönetici onay verdikten sonra seyahat planını değiştirebilir, ancak onay hâlâ önceki tahmine dayanır. Paylaşılan bir elektronik tablo görünürlüğü artırır, fakat genellikle kimin hangi maliyeti ne zaman onayladığını veya daha sonra neyin değiştiğini kaydetmez.

Belirsiz onay limitleri de sık rastlanan başka bir gecikme nedenidir. Bir yönetici, finans ekibinin 750 doların üzerindeki seyahatleri incelemesi gerektiğini fark etmeden 900 dolarlık bir seyahati onaylayabilir. Ya da çalışan her talebi, doğrudan yöneticisi onaylayabileceği hâlde departman başkanına gönderebilir. Her iki yaklaşım da süreci yavaşlatır ve kararların tutarsızlaşmasına neden olur.

Politika istisnaları da seyahat ayrıntıları kadar görünür olmalıdır. Geç saatteki bir uçuş, müşteri konumuna yakın daha pahalı bir otel veya kısa sürede planlanan bir seyahat makul olabilir. Sorun, açıklama ayrı bir mesajda kaldığında veya hiç kaydedilmediğinde başlar. Finans ekibi daha sonra bütçeyi aşan bir makbuz gördüğünde, bu kararın neden alındığına dair açıklama bulamaz.

Pratik bir seyahat talep uygulaması, kararı tek bir kayıtta tutar. Her talepte seyahat tahmini, iş amacı, beklenen toplam, gerekiyorsa istisna nedeni ve onay geçmişi bulunmalıdır. Seyahat sonrasında aynı kayda masraf takip bağlantıları eklenebilir. Böylece ekip gerçekleşen harcamaları onaylanan planla karşılaştırabilir.

Amaç basittir: çalışanlara net bir yol sunmak, onay verenlere ihtiyaç duydukları bilgileri vermek ve finans ekibine gelen kutularını aramadan kontrol edebileceği bir kayıt sağlamak.

Oluşturmadan önce kimin ne yapacağına karar verin

Bir seyahat talep uygulaması, herkesin sorumluluğu net olduğunda daha iyi çalışır. Seyahati planlayan çalışanla, seyahatin iş açısından anlamlı olup olmadığını kontrol eden yöneticiyle ve bütçe ile politikayı inceleyen finans ekibiyle başlayın. Bazı ekiplerin onaylanan seyahatleri rezerve edecek bir seyahat koordinatörüne veya yüksek maliyetler için yönetici onayına da ihtiyacı olabilir.

Rolleri belirgin tutun. Çalışanlar talep oluşturur, tarihleri, varış noktalarını, tahminleri ve iş gerekçesini ekler. Yöneticiler talepleri onaylar, reddeder veya değişiklik ister. Finans ekibi, harcama limitini aşan, politikaya uymayan veya özel ödeme işlemi gerektiren talepleri inceler. Seyahat sonrasında çalışan masraf kaydını ya da makbuz bağlantısını ekler.

Gönderimden sonra nelerin değişebileceğine karar verin

Çalışanların uçuş tahminini düzeltmesi veya toplantı tarihini değiştirmesi gerekebilir. Taslakları serbestçe düzenlemelerine izin verin, gönderimden sonra ise açık kurallar uygulayın. Onaydan önce yapılan küçük değişiklikler sorun değildir. Onaydan sonra tahmini toplam, varış noktası veya seyahat tarihleri değişirse talep yeniden incelemeye gönderilmelidir.

Örneğin bir çalışan Chicago'ya yapılacak 900 dolarlık bir seyahat talebi gönderir ve yönetici bunu onaylar. Ücretlerin artması nedeniyle tahmin 1.450 dolara çıkarsa uygulama yöneticiyi uyarmalı ve önceki tutarı değişiklik nedeni ile birlikte saklamalıdır.

Çalışanların onaylanmış bir talebi haber vermeden değiştirmesine izin vermeyin. Finans ekibi onaylanan bütçeyi nihai masraf kayıtlarıyla karşılaştırmalıdır. Sessiz değişiklikler bu karşılaştırmayı güvenilmez hâle getirir.

Açık onay sınırları belirleyin

Formları veya otomasyonları oluşturmadan önce onay limitlerini yazılı hâle getirin. Limitleri seyahat maliyetine, departmana veya her ikisine göre belirleyin. Bir satış yöneticisi rutin müşteri ziyaretlerini onaylayabilirken finans ekibi uluslararası seyahatleri veya belirli bir tutarın üzerindeki talepleri inceleyebilir.

Basit bir politika şöyle olabilir:

• Yöneticiler kendi departmanları için 1.000 dolara kadar olan seyahatleri onaylar.
• Departman başkanları 1.001 ile 3.000 dolar arasındaki talepleri onaylar.
• Finans ekibi 3.000 doların üzerindeki talepleri, uluslararası seyahatleri ve politika istisnalarını inceler.
• Departman bütçesini aşan seyahatleri yöneticiler onaylar.

Bu limitleri şirketin harcama kararlarını gerçekte nasıl aldığıyla uyumlu hâle getirin. Küçük bir şirketin genellikle beş onay seviyesine ihtiyacı yoktur. Süreç fazla yavaşlarsa çalışanlar onu atlatmanın yollarını arar.

AppMaster ile oluşturulan kodsuz bir seyahat uygulamasında her çalışanın departmanını, yöneticisini ve onay limitini veri modelinde saklayabilirsiniz. İş akışı daha sonra talepleri tahmine ve seyahat ayrıntılarına göre yönlendirebilir. Finans ekibi ilgilenmesi gereken talepleri görürken rutin seyahatler daha hızlı ilerler.

Bir reddi kimin geçersiz kılabileceğine, onaylanmış bir seyahati kimin iptal edebileceğine ve yönetici izinliyken kimin süreci devralacağına da karar verin. Bu küçük kurallar, rezervasyon tarihi yaklaşırken taleplerin beklemede kalmasını önler.

Her seyahat talebi için alanları seçin

Bir seyahat talep uygulaması, hızlı karar vermek için yeterli ayrıntıyı sunmalı, kısa bir seyahati uzun bir forma dönüştürmemelidir. Çalışanın kim olduğunu, nereye gittiğini ve seyahatin neden gerekli olduğunu açıklayan bilgilerle başlayın.

Çalışanın adını ve ekibini formun üst kısmına yerleştirin. Bir kişi başka bir çalışan adına talep gönderiyorsa hem talep sahibini hem de seyahat edeni belirtin. Finans ekibinin daha sonra seyahatleri gruplayabilmesi için varış noktasını serbest metin yerine şehir ve ülke olarak kaydedin. Belirli bir amaç da yöneticilere daha fazla bağlam sağlar. «Mayıs lansmanını planlamak için müşteriyle görüşme» ifadesi, «Müşteri toplantısı» ifadesinden daha açıklayıcıdır.

Gidiş ve dönüş tarihlerini zorunlu tutun. Saat alanlarını yalnızca rezervasyon veya günlük harcırah kuralları için gerekiyorsa ekleyin. Uygulama gece sayısını hesaplayabilir. Böylece onay verenler talebin tamamını açmadan önce yararlı bir bağlama sahip olur.

Tahminleri ayrı tutun

Ulaşım, otel ve yemek için ayrı sayı alanları kullanın. Tek bir toplam tutar paranın nereye gittiğini gizler ve iş seyahati politikasıyla karşılaştırmayı zorlaştırır. Taksi, kiralık araç veya tren önemli maliyetler oluşturuyorsa yerel ulaşımı da ekleyin.

Tahmini toplamı otomatik olarak hesaplayın. Berlin'e iki geceliğine giden bir çalışan uçuş için 320 dolar, otel için 440 dolar, yemek için 120 dolar ve yerel ulaşım için 60 dolar girebilir. Talep 940 dolarlık bir tahmin gösterirken her maliyet görünür kalır.

Finans ekibinin beklediği para birimini kullanın. Uluslararası seyahatlerde talep edilen para birimini ve yerel para birimine çevrilmiş tahmini tutarı ekleyin. Böylece yönetici, 900 tutarının dolar, avro veya sterlin cinsinden olup olmadığını bilmeden onay vermez.

Gereken yerlerde kanıt ve bağlam ekleyin

Uçuş veya otel teklifleri, etkinlik davetleri ve müşteri gündemleri için bir ek alanı ekleyin. Not alanı, zorunlu konferans oteli veya tarihi değişen bir toplantı gibi standart alanlara sığmayan ayrıntıları tutabilir.

Notları isteğe bağlı bırakın, ancak talep bir maliyet eşiğini aşıyor veya istisna içeriyorsa ekleri zorunlu kılın. Çalışan formu doldururken yalnızca geçerli alanları gösterin. Bu, rutin talepleri kısa tutar.

Seyahatten önce makbuz istemeyin. Bunun yerine, seyahat sona erdikten sonra finans ekibinin veya çalışanın doldurabileceği bir seyahat sonrası masraf bağlantısı alanı ekleyin. Bu alan, onaylanan talebi nihai masraf kaydına bağlar.

Politika istisnalarını gizlemeden yönetin

Uygulama, politika istisnalarını biri uçuş rezervasyonu yaptıktan sonra bulmak veya bir yorumun içine gömmek yerine erkenden göstermelidir. Çalışanlar yine istisna talep edebilir, ancak hem seyahat eden hem de onay veren kişi ek maliyeti veya kural ihlalini açıkça görmelidir.

Kuralları sade bir dille yazın. «Makul uçak bileti» gibi belirsiz ifadelerden kaçının. Limiti ve koşulu açıkça belirtin: altı saatten kısa seyahatlerde ekonomi sınıfı uçuş, gecelik 220 dolara kadar otel odası ve kısa bir uçuşa göre daha ucuzsa tren yolculuğu. İlgili alanın yanına kısa bir politika notu koyun.

Girilen maliyetleri politika kuralıyla karşılaştırın. Çalışan 220 dolarlık limite karşılık gecelik 310 dolarlık otel ücreti girerse aradaki farkı gösterin ve gönderimden önce neden belirtmesini isteyin. Özel bir neden alanı, insanların istisnayı açıklamayı unuttuğu genel bir not kutusundan daha iyi çalışır.

Ayrıntı eklenmesine izin veren kısa bir neden listesi kullanın:

• Politika limiti içinde uygun bir seçenek yok
• Müşteri konumu veya toplantı programı bu seçimi gerektirdi
• Erişilebilirlik veya sağlık ihtiyacı
• Güvenlik endişesi
• Diğer neden, yazılı açıklama gerekli

Farklı istisnalar farklı inceleyiciler gerektirir. Müşteri toplantısı nedeniyle gerekli olan daha yüksek otel ücretini genellikle yönetici onaylayabilir. Bütçeyi, vergi uygulamasını, geri ödemeyi veya departmanın harcama limitini etkileyen istisnaları finans ekibi incelemelidir. Seyahat onay iş akışı, her onay verenden her kuralı değerlendirmesini istemek yerine talepleri buna göre yönlendirmelidir.

Örneğin bir çalışan, büyük bir konferans sırasında müşteriyi ziyaret edebilir ve yakındaki oteller normal limitin üzerinde olabilir. Talepte standart limit, seçilen ücret, gecelik ek tutar ve çalışanın açıklaması gösterilebilir. Yönetici seyahatin gerekli olup olmadığına karar verir. İstisna iş seyahati politikasındaki eşiği aşmıyorsa finans ekibi yalnızca gerektiğinde inceleme yapar.

İstisna ayrıntılarını gönderimden sonra da görünür tutun. Bunları onay ekranında, onay geçmişinde ve seyahat sonrası masraf takip bağlantılarının yanında gösterin. Nihai masraf tahminden farklıysa ekip, ilk onayın daha yüksek maliyete neden izin verdiğini anlayabilir.

İnsanların uygulayabileceği onay limitleri oluşturun

Çalışanlar, gönderimden önce bir talebin hangi yoldan ilerleyeceğini tahmin edebilmelidir. Yolu yalnızca uçak bileti ücretine değil, seyahatin tahmini toplam maliyetine göre belirleyin. Konaklama, yerel ulaşım, kayıt ücretleri ve makul yemek tahminini dahil edin. 450 dolarlık bir uçuş, planın geri kalanıyla birlikte 1.600 dolarlık bir seyahate dönüşebilir.

Çalışanların bir talebin neden yöneticiye, diğerinin finans ekibine gittiğini anlaması için limitleri uygulamada görünür tutun. Örneğin:

• 750 dolara kadar olan talepler doğrudan yöneticiye gider.
• 751 ile 2.500 dolar arasındaki talepler yöneticiye ve departman başkanına gider.
• 2.500 doların üzerindeki talepler yöneticiye, departman başkanına ve finans ekibine gider.
• Politika dışındaki tüm talepler, maliyeti ne olursa olsun finans ekibine gider.

İnceleyicileri otomatik olarak seçmek için talep sahibinin departman ve yönetici bilgilerini kullanın. İnsanlar uzun bir listede arama yapmak veya bir sonraki karardan kimin sorumlu olduğunu tahmin etmek zorunda kalmamalıdır. Yönetici izinliyse aynı onay rolüne sahip bir yedek yönetici atayın.

Finans incelemesi yalnızca yüksek toplamları kapsamaz. Finans ekibinin premium koltukları, uluslararası varış noktalarını, farklı para birimlerini veya önceden rezervasyon kuralını ihlal eden rezervasyonları da incelemesi gerekebilir. Talep sahibinden istisnayı bir veya iki doğrudan cümleyle açıklamasını isteyin.

Her kararı inceleyenin adı, kararı, tarih ve saati ile yorumuyla kaydedin. Reddetmeler ve politika istisnaları için yorumları zorunlu kılın. «Müşteri toplantıyı pazartesiye aldığı için onaylandı» gibi bir not, çalışana ve finans ekibine daha sonra yararlı bağlam sağlar.

Limitleri iş akışı mantığının içine gömmek yerine düzenlenebilir bir politika tablosunda saklayın. Operasyon ekibi bütçeler değiştikçe eşikleri güncelleyebilir. Onay geçmişinin açık kalması için geçmiş talepleri, inceleyenin kararı verdiği sırada geçerli olan kurala bağlayın.

İş akışını adım adım oluşturun

Her talebe net bir durum verin. Çalışanlar mesajları kontrol etmeden veya finans ekibine sormadan seyahatin hangi aşamada olduğunu bilmelidir. Basit bir akış yeterlidir: Taslak, Gönderildi, Değişiklik gerekiyor, Onaylandı, Rezerve edildi, Tamamlandı ve Reddedildi.

Çalışanlar talepleri Taslak durumunda oluşturur ve serbestçe düzenleyebilir. Gönderdiklerinde uygulama tarihi kaydeder ve talebi doğru yöneticiye iletir. Yönetici talebi onaylayabilir, reddedebilir veya yorum ekleyerek geri gönderebilir. Kimsenin bağlamı kaybetmemesi için önceki kararları ve yorumları kayıtta tutun.

Yalnızca ek bilgi gerektiğinde değişen tek bir talep formu kullanın. Her talepte seyahat eden kişi, varış noktası, tarihler, iş amacı, ulaşım tahmini, konaklama tahmini ve toplam maliyet bulunmalıdır. Çalışanların destekleyici belgeleri varsa teklif bağlantısı veya ek alanı ekleyin.

Otel tahmini şirket limitini aşıyorsa politika kuralı, limitin üzerindeki tutar ve kısa açıklama alanlarını gösterin. Çalışan, talep yöneticiye ulaşmadan önce durumu açıklamalıdır.

Onay ayrıntılarını aynı kayıtta saklayın: onaylanan tutar, karar tarihi, onay verenin adı, yorumlar ve koşullar. Yönetici 1.200 dolarlık bir seyahati onaylayıp çalışandan daha ucuz bir uçuş seçmesini isteyebilir. Bu koşulu sohbet akışında bırakmak yerine talebe ekleyin.

Ayrı görünümler işin odaklanmasını sağlar. Çalışanların taslaklarını, gönderimlerini, kararlarını ve masraf bağlantılarını görmesi gerekir. Yöneticilerin karar bekleyen talepleri, maliyet tahminlerini, istisnaları ve onay limitlerini görmesi gerekir. Finans ekibinin onaylanan seyahatleri, beklenen harcamayı, rezervasyon durumunu ve seyahat sonrası masraf kayıtlarını görmesi gerekir.

AppMaster bu yapıyı görsel kullanıcı arayüzü oluşturucuları, PostgreSQL veri modeli ve tutarları kontrol eden, talepleri yönlendiren ve durumları güncelleyen iş süreçleriyle destekleyebilir. Düzenleme yetkilerini role göre sınırlayın. Çalışanlar, yeniden inceleme olmadan onaylanmış toplamı değiştirememelidir. Finans ekibi ise masraf takip bağlantısı ekleyip ödeme tamamlandıktan sonra talebi Tamamlandı olarak işaretleyebilir.

Böylece aynı kayıt, ilk tahminden nihai masraf raporuna kadar seyahati takip eder.

Örnek: istisna içeren bir müşteri ziyareti

Maya'nın bir müşteriyi iki gün ziyaret etmesi gerekir. Tarihleri, varış noktasını, müşteri adını ve iş amacını girer. Uygulama uçuş, otel, yerel ulaşım ve yemek tahminlerini ister ve toplamı 1.860 dolar olarak hesaplar.

Yöneticisi 1.500 dolara kadar olan seyahatleri onaylayabilir. Maya'nın tahmini bu limiti aştığı için iş akışı talebi yöneticisine öneri için, ardından nihai karar için departman direktörüne gönderir. Her iki inceleyici de ikinci onayın neden gerektiğini görebilir.

Maya müşterinin ofisine yakın bir otel seçer. Gecelik ücret politika limitinin 25 dolar üzerindedir, ancak daha ucuz bir otel her yönde 45 dakika ek yolculuk gerektirecek ve geç varışını karşılayamayacaktır. Uygulama gönderimden önce istisna notu ister. Maya şöyle yazar: «Müşteri çalıştayı her iki gün de sabah 08.00'de başlıyor. Bu otel yürüme mesafesinde ve akşam uçuşundan sonra geç varışı kabul ediyor.»

Yönetici maliyet özetini, onay limitini ve otel açıklamasını tek bir yerde görür. Talebi onaylar ve direktöre şu notu ekler: «Müşteri çalıştayı erken başlamayı gerektiriyor. Onaylanmasını öneriyorum.»

Direktör, limiti aşan ve politika istisnası içeren bir talep alır. Onaydan sonra uygulama kararı, onay verenlerin adlarını, zaman damgalarını ve yorumları kaydeder. Maya, onayı e-postayla takip etmek yerine net bir durum görür.

Seyahat sonrasında Maya uçuş makbuzu, otel faturası ve masraf raporuna bağlantılar ekler. Nihai toplamı 1.792 dolar olarak girer. Ekip tahmini gerçekleşen harcamayla karşılaştırabilir ve onaylanan otel istisnasının 50 dolar eklediğini, uçuşun ise beklenenden daha ucuz olduğunu görebilir.

Finans ekibi tüm görüşmeyi yeniden açmadan masraf raporunu inceleyebilir. Yöneticiler de çalışanların ne sıklıkla istisna istediğini, hangi seyahatlerin limitleri aştığını ve tahminlerin nihai maliyetlerle ne kadar örtüştüğünü görebilir.

Onay sorunlarına yol açan hatalar

Onay kuralları ekiplerin gerçekte nasıl seyahat ettiğini göz ardı ettiğinde başarısız olur. Bir satış yöneticisinin 1.800 dolarlık müşteri ziyaretini onaylaması gerekebilirken destek ekibi lideri 500 doların altındaki kısa yurt içi seyahatleri yönetebilir. Her departman için tek bir limit belirlemek, rutin taleplerin gereğinden uzun beklemesine veya yüksek maliyetli taleplerin doğru bütçe yetkisine sahip olmayan birine gitmesine neden olur.

Gerektiğinde limitleri departmana, role, seyahat türüne veya bunların birleşimine göre belirleyin. İlk sürümü basit tutun. Bir ekip lideri 750 dolara kadar, departman başkanı 2.500 dolara kadar olan seyahatleri onaylayabilir; bunun üzerindeki her şeyi finans ekibi inceleyebilir.

Onaylanan tutarları koruyun. Çalışan onaydan sonra uçuş tahminini 420 dolardan 690 dolara çıkarırsa talebi yeniden incelemeye gönderin. Aksi hâlde yönetici bir tutarı onaylar, şirket başka bir tutarı öder.

Şu durumlarda yeniden inceleme başlatın:

• Tahmin onaylanan tutarın üzerine çıkar.
• Değişen bir kalem seyahati daha yüksek bir onay aralığına taşır.
• Çalışan onaydan sonra bir politika istisnası ekler.
• Varış noktası, tarihler veya iş amacı değişir.

İstisnalar için serbest metin notlarına güvenmeyin. «Geç rezervasyon» gibi bir yorum, talebin hangi politika kuralını ihlal ettiğini yöneticiye anlatmaz. İstisnalara kendi alanlarını verin: tür, neden, ek maliyet ve kısa açıklama. Uygulama istisnayı bir sohbet akışında gizlemek yerine seyahat toplamının yanında gösterebilir.

Çalışan döndüğü anda seyahati kapatmayın. Çalışan masraf takip bağlantılarını ekleyene veya başka masraf kalmadığını doğrulayana kadar talebi açık tutun. Bir çalışan 900 dolarlık konferans seyahati için onay alıp daha sonra 1.040 dolarlık masraf gönderirse uygulama farkı kaydetmeli ve incelemeden sorumlu kişiye iletmelidir. «Masraf bağlantısı bekleniyor» gibi bir durum talebi görünür tutar.

Yayına almadan önce uygulamayı kontrol edin

Uygulamayı seyahat talebi gönderecek, onaylayacak ve inceleyecek kişilerle test edin. Bir ekran tamamlanmış gibi görünebilir, ancak talebi yanlış kişiye yönlendirebilir veya finans ekibinin ihtiyaç duyduğu bir maliyet ayrıntısını gizleyebilir.

Bir asistan başka biri adına giriş yapsa bile her talepte adı belirli bir çalışan veya sorumlu bulunmalıdır. Bu kişi durum güncellemelerini almalı ve eksik ayrıntıları sağlamalıdır. Böylece yönetici tarihler, amaç veya güncellenmiş tahmin hakkında soru sorduğunda karışıklık yaşanmaz.

Onay limitlerini gerçekçi tutarlarla test edin. Bir yöneticinin limitinin altında, hemen üzerinde ve çok üstünde bir talep oluşturun. İnceleyiciler tahmini toplamı, incelemeyi tetikleyen kuralı ve önceki kararları görebilmelidir.

Yayına alma öncesi kısa bir kontrol listesi kullanın:

• Standart bir seyahat gönderin ve doğru yöneticinin aldığını doğrulayın.
• Bir politika istisnası gönderin ve nedenin görünür kaldığını doğrulayın.
• Bir talebi yorumla reddedin, ardından çalışanın talebi düzenleyip yeniden gönderebildiğini doğrulayın.
• Seyahat sonrası makbuz klasörüne veya masraf raporu URL'sine bağlantı ekleyin ve finans ekibinin erişebildiğini doğrulayın.
• Çalışanların, yöneticilerin, finans ekibinin ve yöneticilerin neleri görebildiğini ve düzenleyebildiğini kontrol edin.

İzin kontrollerine özellikle dikkat edin. Çalışanların kendi seyahat planlarına ve tahminlerine erişmesi gerekirken yöneticilerin ekiplerinin taleplerine erişmesi gerekir. Finans ekibinin maliyetleri ve masraf bağlantılarını görmesi gerekebilir, ancak geri ödemeyle ilgisi olmayan özel notları görmesi gerekmeyebilir. Yöneticiler, yönlendirme hatalarını düzeltecek kadar erişime sahip olmalı, ancak varsayılan onay veren kişi hâline gelmemelidir.

480 dolarlık uçuş, 360 dolarlık otel ve 150 dolarlık yerel ulaşım bütçesi içeren iki günlük örnek bir müşteri ziyareti deneyin. Ardından otel tahminini 620 dolara çıkarın ve bunu istisna olarak işaretleyin. Uygulama maliyet ayrıntılarını ve açıklamayı korumalı, talebi yüksek toplam tutara göre yönlendirmeli ve nihai kararı kaydetmelidir.

Uygulamayı AppMaster ile oluşturuyorsanız bu senaryoları ekibinizin kullanacağı sürümde test edin. Görsel mantığı, talepleri tutara, departmana veya istisna durumuna göre yönlendirebilir; rol tabanlı erişim ise her alanı kimin göreceğini belirler. Beş kişilik bir deneme, belirsiz etiketleri ve yönlendirme eksiklerini uzun bir iç incelemeden daha hızlı ortaya çıkarabilir.

Küçük başlayın ve süreci geliştirin

Satış veya müşteri desteği gibi tek bir ekiple ve kısa bir kural listesiyle başlayın. İlk sürümde yalnızca bir seyahatin devam edip edemeyeceğini belirleyen ayrıntılar bulunmalıdır: çalışan, amaç, tarihler, varış noktası, tahmini maliyet ve yönetici onayı.

İlk limitleri açıklaması kolay tutun. Bir yönetici 1.500 dolara kadar olan seyahatleri onaylayabilir, departman başkanı ise daha yüksek tutarları inceleyebilir. Premium uçuşlar veya geç rezervasyonlar gibi politika dışı talepleri, istisna notuyla uygun inceleyiciye gönderin.

İlk günden olası her alanı eklemekten kaçının. Uzun bir form, insanları yeniden e-postaya yönlendirir ve uygulamanın çözmesi gereken takip sorununu geri getirir.

İlk birkaç talepten sonra çalışanlara ve onay verenlere nerede duraksadıklarını veya hangi noktada soru sormak zorunda kaldıklarını sorun. Yanıtları genellikle eksik bir alanı, belirsiz bir maliyet limitini veya ekibin gerçek süreciyle uyuşmayan bir onay adımını ortaya çıkarır.

İlk iyileştirmeler arasında müşteri veya proje alanı eklemek, uçuş ve otel tahminlerini ayırmak, istisna nedenini zorunlu kılmak, onay limitlerini ayarlamak veya seyahat sonrasına masraf raporu bağlantısı eklemek bulunur.

Mümkün olduğunda her seferinde tek bir değişiklik yapın. On kural aynı anda değişirse hangi değişikliğin sorunu çözdüğünü veya yeni bir gecikmeye neden olduğunu anlamak zorlaşır. Bir ay sonra bekleyen ve reddedilen talepleri inceleyin. Tekrarlanan istisnalara, tek bir onay verende bekleyen taleplere ve nihai maliyetlerden sürekli farklılaşan tahminlere bakın.

AppMaster, ekiplerin formları, onayları ve raporlamayı tek bir uygulamada bir araya getiren kodsuz bir seyahat uygulaması oluşturmasını sağlar. Ekibinizin bugün ihtiyaç duyduğu talep formu ve onay kurallarıyla başlayın. Tercih edilen tedarikçileri, bütçe raporlarını veya doğrudan masraf takip bağlantılarını yalnızca gerçek bir sorunu çözdüklerinde ekleyin.