Onarım talepleri, fotoğraflar, bildirimler ve yönetici araçlarıyla bir onarım talebi uygulamasını nasıl planlayıp tasarlayıp oluşturacağınızı öğrenin—başlatma ve büyüme için ipuçlarıyla.
Onarım talebi uygulaması basit bir söz verir: bir sorun fark eden herkes birkaç dakika içinde bildirimde bulunabilir ve işin içinde olan herkes bir daha ne olduğunu görebilir—telefon trafiği, tekrar eden e-postalar veya “mesajımı aldın mı?” takipleri olmadan.
Aynı iş akışı birçok ortamda görülür, sadece etiketler farklıdır:
Temelde uygulama, doğru ayrıntıları baştan yakalayarak ve durum değişikliklerini görünür kılarak gereksiz yazışmayı azaltmalıdır.
İyi bir sistem:
Bu deseni mülk bakımı, ofis ve kampüsler için tesis bakım iş akışı, perakende/servis merkezlerinde cihaz onarımları ve sıhhi tesisat veya elektrik gibi ev hizmetleri içinde görürsünüz.
Başarı “daha fazla özellik” değil, ölçülebilir çıktılardır:
Bir onarım talebi uygulaması, insanların gerçekten nasıl bildirdiği, triage ettiği ve sorunları düzelttiğiyle eşleştiğinde işe yarar. Ekranları tasarlamadan önce bilete kim dokunur, hangi kararları verir ve “mutlu yol”un nasıl göründüğünü tanımlayın.
Talep eden (kiracı/çalışan/rezident): sorunu bildirir, fotoğraf ekler, konum seçer ve aramadan durum kontrol eder.
Teknisyen (bakım/yüklenici): atamaları alır, konum detaylarını görür, müsaitlik bildirir, işi kaydeder ve kanıtla kapatır.
Dispatcher/Admin: yeni talepleri triage eder, bilgiyi doğrular, öncelik belirler, uygun teknisyeni atar ve erişimi koordine eder (anahtarlar, randevular, güvenlik).
Yönetici (mülk/tesis sorumlusu): bekleyen işleri, SLA’ları, tekrarlayan sorunları ve performans trendlerini izler; gerekirse masrafları onaylar.
İş akışını basit tutun, net devir teslimlerle:
Hangi olayların uygulama içi güncelleme, e-posta, SMS ve push bildirim tetikleyeceğine karar verin. Yaygın tetikleyiciler: bilet alındı, randevu ayarlandı, teknisyen yolda, iş tamamlandı ve mesaj yanıtları.
En azından: kesin konum (bina/kat/oda/daire), kategori, öncelik, SLA hedefleri (yanıt ve çözüm), atanan kişi, zaman damgaları, durum geçmişi, fotoğraflar/ekler ve bir mesaj kaydı. Bu veriler güvenilir iş emri durum güncellemeleri ve anlamlı raporlama sağlar.
Talep edenler bir onarım uygulamasını iki şeye göre değerlendirir: sorunu ne kadar hızlı bildirebildikleri ve sonrasında neler olduğunu ne kadar net görebildikleri. Amaç, formu evrak işine çevirmeden yazışmayı azaltmaktır.
İyi bir talep akışı, yönlendirme ve raporlama için yapılandırılmış alanları serbest metin açıklamayla birleştirir. İçerik:
Formu kısa tutun; varsayılanlar ve akıllı öneriler ekleyin (son kullanılan birimi hatırla, son kategorileri sun).
Medya, özellikle sızıntılar, hasarlar ve hata kodları için ilk seferde çözümü büyük ölçüde iyileştirir. Fotoğraf ve kısa video eklemeyi kolaylaştırın, ancak sınırlar koyun:
Hedef kitleniz kiracılardan oluşuyorsa, medyayı kimlerin görebileceğini ve ne kadar süre saklanacağını belirtin.
Talep edenlerin “open”ın ne anlama geldiğini öğrenmek için arama yapmaması gerekir. Zaman çizelgesinde zaman damgalarıyla basit bir akış gösterin:
Submitted → Accepted → Scheduled → In Progress → Completed
Her adım ne bekleyeceğini açıklamalı (“Scheduled: teknisyen Salı 13:00–15:00 arası planlandı”) ve kimin sorumlu olduğunu belirtmelidir. Bir şey bloke olduysa (parça bekleniyor gibi), bunu sade bir dille gösterin.
İki yönlü iletişim kaçırılan randevuları ve tekrar ziyaretleri azaltır. Her bilet üzerinde yorumlar veya sohbeti destekleyin, ancak hesap verilebilir kalmasını sağlayın:
Talep edenler sıklıkla tekrarlayan sorun bildirir. Onlara filtreli (durum, kategori, konum) aranabilir bir geçmiş ve hızlı “benzer talep gönder” eylemi verin. Bu güven oluşturur: kullanıcılar sonuçları, tamamlama notlarını ve gerçekten neyin düzeltildiğini görebilir.
Teknisyenler için uygulama sürtünmeyi kaldırmalı, eklememeli. Gündelik işin hızla devam etmesini sağlayacak erişim, net bağlam (ne, nerede, aciliyet) ve bileti masaüstüne dönmeden kapatma yeteneği öncelikli olmalıdır. Tek el kullanımına, zayıf bağlanıma ve saha koşullarına göre optimize edin.
Varsayılan ekran iş listesi olmalı; teknisyenlerin iş planlamasına uyan filtrelerle: öncelik, vade, konum/bina ve “bana atanan”.
Hafif sıralama seçenekleri (örn. en yakındaki konum veya en eski açık) ekleyin ve önemli bilgileri anında görünür kılın: bilet numarası, durum, SLA/son tarih ve istekte fotoğraf olup olmadığı.
Durum güncellemeleri tek dokunuşla yapılabilmeli—ör. Start, On hold, Needs parts, Completed—opsiyonel ek alanlar zorunlu olmamalı.
Durum değişikliğinden sonra önemli olanları isteyin:
Burada iş emri durum güncellemeleri güvenilir hale gelir: uygulama “doğru olanı yapmayı” en kolay iş yapmalıdır.
Saha servis uygulaması için pratik bir çevrimdışı mod şarttır. En azından, teknisyenin atandığı işleri (fotoğraflar ve konum bilgisi dahil) önbelleğe alın, çevrimdışı güncellemeler taslağı oluşturmasına izin verin ve bağlantı geri geldiğinde otomatik senkronize edin.
Senkron durumunu açıkça gösterin. Bir güncelleme beklemedeyse bunu net gösterin ve çift gönderimleri engelleyin.
“Önce/sonra” fotoğraflarını basit rehberlikle destekleyin ("Before" ve "After" gibi etiketler). Fotoğraflar, orijinal sorun teknisyen geldiğinde farklı görünse bile özellikle değerlidir.
Bazı ortamlarda (örn. ticari tesisler veya kiracı bakım senaryoları) isteğe bağlı müşteri imzası tamamlanmayı doğrulayabilir. Her bilete imza zorunlu kılmayın—bunu adminlerin mülk veya iş türüne göre etkinleştirebileceği bir iş akışı kuralı yapın.
Önemli zaman damgalarını, uygulamayı kronometreye çevirmeden yakalayın:
Bu alanlar daha iyi raporlama sağlar (örn. konuma göre ortalama tamamlama süresi) ve bakım yönetimi uygulamasının yükümlülüğünü artırır, teknisyenleri zorlamadan.
Eğer teknisyenlerin uygulamayı benimsemesini istiyorsanız, her özellik şu soruyu yanıtlamalı: “Bu bana işi daha hızlı ve daha az tekrarla bitirmemde yardım edecek mi?”
Talep edenler ve teknisyenler birkaç ekran görürken, yöneticilerin işleri ilerleten, biletlerin kaybolmasını önleyen ve veri üreten bir kontrol merkezine ihtiyacı vardır.
En azından yönetici panosu bilet oluşturma, düzenleme ve atamayı hızlıca yapmayı sağlamalı—beş sekme açmak zorunda kalmadan. Hızlı filtreler (site/bina, kategori, öncelik, durum, teknisyen) ve toplu eylemler (ata, öncelik değiştir, çakışmaları birleştir) ekleyin.
Yöneticiler ayrıca işin “sözlüğünü” yönetme araçlarına ihtiyaç duyar: kategoriler (sıhhi tesisat, HVAC, elektrik), konumlar (site, bina, kat, birim/oda) ve sık kullanılan sorun şablonları. Bu yapı, dağınık serbest metin biletleri azaltır ve raporlamayı güvenilir kılar.
İstisnalar için manuel atama gerekli, ama kurallara dayalı yönlendirme her gün zaman kazandırır. Tipik yönlendirme kuralları:
Pratik yaklaşım: “önce kurallar, yönetici her zaman geçersiz kılabilir.” Biletin neden belirli şekilde yönlendirildiğini yöneticilere gösterin ki sisteme güvenip gerektiğinde düzeltebilsinler.
Yanıt süreleri vaat ediyorsanız uygulama bunları denetlemeli. Öncelik/kategori başına SLA zamanlayıcıları ekleyin ve biletlerin gecikmek üzereyken değil geç kaldıktan sonra tetiklenecek yükseltmeler başlatın. Yükseltmeler atanan teknisyeni yeniden bilgilendirebilir, bir süpervizörü uyarabilir veya önceliği artırabilir; her adımın denetim izi olmalı.
Raporlamayı karar vermeye odaklı tutun:
Kimlerin hangi biletleri görebileceğini site, bina, departman veya müşteri hesabı bazında tanımlayın. Örneğin, bir okul müdürü sadece kendi kampüsünü görürken ilçe yöneticisi hepsini görebilir. Sıkı görünürlük kuralları gizliliği korur ve aynı sistemi paylaşan birden fazla ekip olduğunda kafa karışıklığını önler.
İnsanlar onarım taleplerini formları sevdiği için vermezler—güvencelenmek isterler. Durum UI’ınız bir bakışta üç soruyu yanıtlamalı: Şimdi biletim nerede? Sonraki adım ne? Sahibi kim?
Mobilde dikey basit bir zaman çizelgesi iyi işler: her adımın net bir etiketi, zaman damgası ve sahibi olsun.
Örnek:
Bir şey bekliyorsa bunu açıkça gösterin (örn. On Hold — waiting for parts) ki kullanıcılar unutulduğunu düşünmesin.
Mevcut durumun altında kısa bir “sonraki adım” mesajı ekleyin:
Bu mikro-taahhütler, daha fazla bildirim göndermeden “güncelleme var mı?” mesajlarını azaltır.
“Kullanıcıya yönelik olmayan” iç terimlerden kaçının: örn. “WO Created” veya “Dispatched” gibi. Her yerde aynı fiilleri kullanın: Submitted, Scheduled, In Progress, Completed. İç durumları desteklemeniz gerekirse, bunları kullanıcı dostu etiketlere eşleyin.
Yorum ekle, Fotoğraf ekle ve Konum detayları ekle düğmelerini istek ekranına doğrudan koyun, menülerin içinde gizlemeyin. Kullanıcılar detay eklediğinde zaman çizelgesinde yansısın (“Talep eden fotoğraf ekledi — 14:14”).
Okunabilir yazı boyutları, güçlü kontrast ve açık durum etiketi kartları kullanın (yalnızca renge bağlı kalmayın). Formları kısa tutun, alan adlarını sade dilde yazın ve hata mesajları tam olarak neyi düzeltmeleri gerektiğini açıklasın.
Bildirimler, öngörülebilir, ilgili ve eyleme dönük olduğunda yardımcı olur. İyi bir onarım talebi uygulaması bildirimleri gürültü değil iş akışının parçası olarak ele alır.
Kullanıcıların “Biletimle ne oluyor?” sorusunu yanıtlayan tetikleyicilerle başlayın:
Teknisyen notları gibi küçük iç değişiklikler hakkında bildirim göndermekten kaçının; kullanıcı açıkça tercih etmediyse bu tür bildirimleri sınırlayın.
Farklı kullanıcılar farklı kanallar ister. Ayarlarda rol bazlı tercihler sunun:
Ayrıca “sadece kritik” vs. “tüm güncellemeler” seçenekleri verin; bu kiracı bakım uygulamalarında faydalıdır.
Her mesaj iki şeyi cevaplamalı: ne değişti ve sonraki adım ne.
Örnekler:
Sessiz saatler (örn. 21:00–07:00) ve frekans limitleri (önemsiz güncellemeleri birleştir) ekleyin. Bu, bildirim yorgunluğunu azaltır ve güveni artırır.
Her bildirim, kullanıcıyı ilgili bilet görünümüne açmalı (app ana ekranına değil). Deep linkler doğru sekmeye veya durum zaman çizelgesine gitmeli; örn. /tickets/1842?view=status.
Bir onarım talebi uygulaması kullanıcılara “basit” görünse de, altında yatan veri ve durum kuralları tutarlı olmadıkça basit kalamaz. Burada zaman harcarsanız kafa karışıklığını, takılı kalan biletleri ve dağınık raporlamayı önlersiniz.
Gerçek işe uyan varlıklarla başlayın:
Küçük bir durum seti ve katı geçişler tanımlayın (örn. New → Triaged → Assigned → In Progress → Waiting on Parts → Completed → Closed).
Belgelendirin:
Önemli olaylar için değiştirilemez bir denetim kaydı saklayın: durum güncellemeleri, atama değişiklikleri, öncelik/konum düzenlemeleri ve ek silme işlemleri. Aktörü, zaman damgasını, eski ve yeni değeri ve kaynağı (mobil/web/API) dahil edin.
S3 uyumlu nesne depolama kullanın ve süresi dolan yükleme URL’leriyle çalışın. Saklama beklentilerini baştan belirleyin: ekleri biletler var olduğu sürece saklayabilir veya gizlilik için X ay sonra otomatik silebilirsiniz. Kırpma/kaldırma iş akışlarını destekleyin.
Basit bir hunuyu takip edin: ticket created, first response, assigned, work started, completed, closed. Çözüm süresi, yeniden atama sayısı ve “beklemede” süresini yakalayın ki nerede gecikme olduğunu bile incelemeden anlayabilesiniz.
Doğru teknoloji yığını seçiminde çoğunlukla takaslar vardır: bütçe, zaman çizelgesi, dahili beceriler ve uygulamanın ne kadar “gerçek zamanlı” hissetmesi gerektiği.
Bir çapraz platform uygulama (Flutter veya React Native gibi) genellikle onarım talebi uygulamaları için uygundur; tek kod tabanından iOS ve Android gönderebilirsiniz. Bu, MVP ve pilot için daha hızlı teslimat ve düşük maliyet sağlar.
Ağır cihaz özellikleri, olağanüstü performans veya güçlü yerel ekipleriniz varsa yerel (iOS için Swift, Android için Kotlin) tercih edin. Çoğu servis talebi ve mobil iş emri uygulaması için çapraz platform yeterlidir.
Güvenilir bir bakım yönetimi uygulaması için backend şarttır. Planlayın:
“Boring” (sıkıcı) mimari kazanır: tek bir API + veritabanı, birçok parçaya bölünmüş sistemden daha kolay yönetilir.
Kullanıcılar hızlı durum güncellemeleri istiyor ama her zaman gerçek zamanlı akışa gerek yok.
Pratik yaklaşım: push bildirimleri ile kullanıcıyı uyarın, kullanıcı bildirime dokunduğunda veriyi yenileyin.
Akışı hızlı doğrulamak istiyorsanız, Koder.ai gibi bir araçla bir “vibe-coding” yaklaşımı düşünün. Talep eden akışını, teknisyen iş listesini ve yönetici panosunu sohbet içinde tanımlayarak planlama modunda yineleyebilir ve React + backend (Go + PostgreSQL) ile çalışan bir web uygulaması oluşturabilirsiniz. Mobil için Koder.ai Flutter istemcisi de iskeletleyebilir ve API sözleşmelerini korumanıza yardımcı olur.
Bu, pilotlarda yararlı olur: anlık görüntüler ve geri alma riski azaltır; durum geçişlerini, bildirimleri ve izinleri gerçek kullanım verisine göre ayarlarken kaynak kodunu dışa aktarabilirsiniz.
MVP'ye eklemeseniz bile gelecekte için entegrasyonları tasarlayın:
Saha uygulamaları, laboratuvar tarzı testlerle başarısız olur. Şunları test edin:
Burası, saha servis uygulamanızın sinir bozucu değil güvenilir olmasını sağlar.
Onarım talebi uygulamaları genellikle hassas detaylar içerir: birinin nerede yaşadığı veya çalıştığı, neyin bozulduğu ve fotoğraflarda yanlışlıkla görünen yüzler, belgeler veya güvenlik cihazları. Güvenlik ve gizliliği temel ürün özellikleri olarak ele alın.
Başlangıçta düşük sürtünme, sonra ölçekleyin:
Hesap kurtarmayı basit yapın ve kötüye kullanımı azaltmak için oturum açma denemelerini sınırlayın.
Erişim kontrolünü roller ve konumlar etrafında tasarlayın. Bir kiracı sadece kendi birimiyle ilgili biletleri görmeli; bir teknisyen kendi bölgesindeki biletleri görebilmeli.
İyi bir kural: kullanıcılar işlerini yapmak için gereken asgari erişime sahip olur, geniş görüş yetkisi admin tarafından açıkça verilir. Çoklu bina veya müşteri desteği varsa her birini ayrı “alan” gibi düşünün ki veriler birbirine sızmasın.
Fotoğraflar çok yardımcıdır, ama kişisel bilgileri açığa çıkarabilir. Kamera düğmesinin yanında kısa bir uyarı gösterin: “Yüzleri, kimlikleri veya şifreleri çekmeyin.” Kullanıcılar sık sık belge veya ekran fotoğrafı çekiyorsa, kırpma/gizleme rehberliği (veya ileride basit bir bulanıklaştırma aracı) sunmayı düşünün.
HTTPS ile şifrelenmiş aktarım kullanın ve dosyaları özel bir bucket içinde saklayın. Tahmin edilebilir veya paylaşılabilir doğrudan dosya URL’lerinden kaçının. Görselleri süre sınırlı, izin kontrolü yapılmış bağlantılar üzerinden sunun.
Uyumluluk gereksinimleri sektöre ve bölgeye göre değişir. İddiaları genel tutun (örn. “veriyi aktarım sırasında şifreleriz”), veri işleme politikalarını belgeleyin ve düzenlenmiş veri türleri veya kurumsal sözleşmeler söz konusuysa hukuki danışmanlık alın.
Onarım talebi uygulamanızın işe yaradığını kanıtlamanın en hızlı yolu ilk sürümü en gerekli şeylerle sınırlamaktır: talep oluşturmak, ne olduğunu anlamak ve döngüyü kapatmak.
MVP’yi gönderebilecek kadar küçük ama güven oluşturacak kadar tamamlayıcı tutun:
Bir özellik talep oluşturma, güncelleme veya işi bitirmeye yardımcı olmuyorsa sonraya itin.
İnşa etmeden önce tıklanabilir bir prototip (Figma/ProtoPie vb.) oluşturun ve şunları kapsadığından emin olun:
Kısa testler (15–20 dakika) ile 5–8 gerçek kullanıcı (kiracılar, ofis personeli, teknisyenler) ile çalışın. Durumlar, ifadeler ve kullanıcıların bildirim beklentilerindeki kafa karışıklığını gözleyin.
Eğer Koder.ai kullanıyorsanız, aynı akışları erken aşamada çalışan bir uygulama olarak da prototipleyebilir, kopyayı, durum etiketlerini ve izinleri gerçek tıklama davranışıyla doğrulayabilirsiniz.
MVP’yi 2–4 hafta boyunca tek bir bina, kat veya bakım ekibine yayın. Şunları takip edin: ilk yanıt süresi, tamamlama süresi, “biletim nerede?” takipleri ve bildirim kapatma oranları.
Kimlerin talepleri triage edeceğini, kimin atama yapacağını, “acil”in ne anlama geldiğini ve yanıt süre beklentilerini kararlaştırın. Uygulama sahiplik belirsizliğini telafi edemez.
Doğrulamadan sonra önceliklendirin: SLA kuralları, periyodik bakım, envanter/parçalar, çevrimdışı mod ve daha derin raporlama—ancak önce temel durum güncellemeleri ve bildirimleri güvenilir hale gelmeli.
İlk sürümü göndermek işin yarısıdır. Diğer yarısı kullanımı kolaylaştırmak, öğrenimi kolay kılmak ve gerçek kullanım verisine göre sürekli geliştirmektir.
Dağıtım modelinizi ortamınıza göre seçin:
Hem talep edenleri hem teknisyenleri destekliyorsanız, rol bazlı erişimli tek bir uygulama veya iki ayrı uygulama (kiracı uygulaması ve teknisyen saha uygulaması) yayınlamayı düşünün. Hangi yolu seçerseniz seçin, giriş akışlarını ve izinleri açmadan önce doğrulayın.
Çoğu düşük kaliteli servis bileti belirsiz beklentilerden gelir. Onboarding bunu kurallar koymadan öğretmeli. Kısa bir rehber (3–5 ekran) ve ardından bir örnek talep gösterin:
Formda hafif ipuçları ekleyerek başlangıçta yazışmayı azaltın.
Kullanıcıların takıldığı anda yardım almasını kolaylaştırın:
Bunları onay ekranı ve durum sayfasından görünür yapın, sadece ayarlarda saklamayın.
Uygulamayı birkaç anahtar sayı ile instrument edin:
Bu metrikler sorunun personel, triage kuralları, form belirsizliği veya eksik teknisyen araçlarından mı kaynaklandığını belirlemenize yardımcı olur.
Düzenli bir tempo belirleyin (örn. her 2–4 haftada bir) geri bildirimi ve metrikleri gözden geçirip küçük değişiklikler yayınlayın:
Koder.ai üzerinde inşa ediyorsanız, bu yineleme döngüsü özellikle hızlı olabilir: iş akışını sohbette güncelleyin, planlama modunda doğrulayın ve anlık görüntü/geri alma güvenliği ile değişiklikleri yayınlayın—istediğinizde kaynağı dışa aktarın ve tam kontrolü elinize alın.
Her güncellemeyi uygulamayı daha kullanışlı hale getirme fırsatı olarak görün; sadece daha fazla özellik eklemek değil, işi daha hızlı yaptırmak hedefiyle.
Bir onarım talebi uygulaması güvenilir şekilde üç şeyi yapmalıdır:
Formu kısa ama yapılandırılmış tutun, böylece talepler uygulanabilir olur:
Zaman damgası ve sahibi ile küçük bir kullanıcı dostu durum seti kullanın. Pratik bir zaman çizelgesi:
İş bloke olduysa bunu açıkça gösterin (ör. ) ve bileti sadece “open” bırakarak belirsiz bırakmayın.
Tekrar ziyaretleri azaltır ve ön incelemeyi hızlandırır çünkü teknisyenler genellikle gelmeden önce sorun hakkında teşhis yapabilir. Fotoğraf yüklemelerini pratik hale getirin:
Güncellemeleri kolay ve tutarlı yapın:
Amaç doğru iş akışını uygulamayı göz ardı etmekten daha hızlı hale getirmek.
Temel bir çevrimdışı mod şu özelliklere sahip olmalıdır:
Senkronizasyon durumunu şeffaf gösterin ve aynı güncellemenin iki kez gönderilmesini engelleyin.
Kullanıcı sorusuna yanıt veren olaylarla başlayın ("Biletimde ne oluyor?"):
Kullanıcılara kanal seçme imkânı verin (push/e-posta/SMS) ve sessiz saatler, frekans limitleri gibi ayarlar sunun. Ayrıca her bildirimin doğrudan ilgili bilet görünümüne açıldığından emin olun (deep link). Örnek: .
En azından şu varlıkları modelleyin:
Sıkı durum geçiş kuralları ve önemli değişiklikler için bir denetim (audit) kaydı ekleyin ki raporlama ve hesap verebilirlik güvenilir olsun.
Rol ve konuma dayalı asgari ayrıcalık prensibini kullanın:
Ekleri güvenli depolayın (özel depolama, zaman sınırlı bağlantılar) ve yüklenen medyayı kimlerin görebileceğini, ne kadar süreyle saklanacağını açıkça bildirin.
Pratik bir MVP şunları tam olarak desteklemelidir:
MVP'yi bir bina veya ekipte 2–4 hafta pilot edin ve ilk yanıt süresi, tamamlama süresi ve “biletim nerede?” geri bildirimlerini takip edin.
/tickets/1842?view=status