İç hizmet taleplerini toplamak, onayları yönlendirmek, SLA'ları izlemek ve performansı güvenli şekilde raporlamak için bir web uygulamasını nasıl planlayacağınızı, tasarlayacağınızı ve oluşturacağınızı öğrenin.
Ekranları tasarlamadan veya teknoloji yığını seçmeden önce, iç hizmet talebi uygulamanızın neyi çözdüğünü netleştirin. Çoğu ekip zaten bir “sisteme” sahiptir—sadece e-posta dizileri, sohbet mesajları, tablolar ve koridor konuşmaları arasında dağınıktır. Bu düzen işler saklar, tekrar taleplere yol açar ve basit bir soruyu yanıtlamayı zorlaştırır: “Bunun sahibi kim ve ne zaman bitecek?”
Dar bir problem bildirimi ve bir v1 hedefi yazın, örneğin: “IT erişimi ve Tesis onarımları için net sahiplik, gerektiğinde onaylar ve SLA görünürlüğü ile tek bir çalışan istek portalı sağlayın.”
İç istekler genellikle birkaç kategoriye kümelenir:
İlk günde her kenar durumunu çözmeniz gerekmez; açık bir başlangıç kapsamı seçin (örneğin: “IT erişimi + Tesis onarımları”).
Mevcut başarısızlık noktalarını düz ve anlaşılır bir dille yazın:
Bu liste uygulamanın neyi düzeltmesi gerektiği için kuzey yıldızınız olur.
Birincil kullanıcıları ve her birinin ihtiyaçlarını tanımlayın:
Lansmandan sonra izleyebileceğiniz hedefler koyun: daha hızlı çözüm süresi, bilet başına daha az takip, daha yüksek ilk yanıt hızı ve daha net sorumluluk (ör. “her talebe 1 iş saati içinde bir sahip atansın”). Bu metrikler ürün kararlarını yönlendirir ve uygulamanın işe yarayıp yaramadığını kanıtlamanıza yardımcı olur.
Ekranları veya iş akışlarını tasarlamadan önce, uygulamayı kimin kullanacağını ve her kişinin ne yapmaya yetkili/beklendiğini netleştirin. Çoğu iç hizmet talebi sistemi rollerin belirsiz olmasından başarısız olur: insanlar bir sonraki adımın sahibini bilmez ve talepler etrafta dolaşır.
Çalışan (istekte bulunan)
Çalışanlar birkaç dakika içinde talep gönderebilmeli ve kaybolmayacağından emin hissetmelidir.
Onaylayan
Onaylayanlar harcama, erişim ve politika kararlarını kontrol altında tutar.
Ajan / Çözücü
Ajanlar işi gerçekten yapan ve ilerlemeyi ileten insanlardır.
Admin
Adminler sistemi düzenli ve güvenli tutar.
Her istek türü için tanımlayın:
Spesifikasyonunuzda basit bir RACI tablosu kafa karışıklığını önler ve sonraki iş akışı kararlarını kolaylaştırır.
v1 iç talep portalı birkaç işi mükemmel yapmalı: çalışanların net talepler göndermesini sağlamak, bunları doğru ekibe hızla ulaştırmak ve tamamlanana kadar herkesi bilgilendirmek. İlk günde her kenar durumunu dahil etmeye çalışırsanız teslimatı yavaşlatırsınız ve kullanıcıların gerçekten neye ihtiyacı olduğunu yine de kaçırırsınız.
Küçük sayıda kategoriyle başlayın (örneğin: IT Yardım, Tesis, İK, Satınalma). Her kategori sadece ilgili alanları sormalı; bunun için dinamik alanlar kullanın.
Şunları dahil edin:
v1 için tahmin edilebilir atama gerekir: kategori, departman, lokasyon veya anahtar kelime kurallarıyla. Öncelik (düşük/orta/yüksek) ve tek bir basit yükseltme yolu ekleyin (ör. “24 saat atanmadı” veya “yüksek öncelik 4 saat boşta kaldı”). Kural editörünü minimumda tutun; daha sonra esneklik ekleyebilirsiniz.
Önce tek adımlı onayı destekleyin (yönetici veya bütçe sahibi). Onaylar kritikse koşullu onaylar ekleyin (ör. “500$ üzeri için Finans”). Çok adımlı zincirler, ilk istek tipiniz bunlar değilse bekleyebilir.
Şunlar için e-posta ve uygulama içi bildirimleri dahil edin: talep alındı, atandı, ek bilgi gerekiyor, onaylandı/reddedildi, tamamlandı. Süresi geçen öğeler için onaylayanlar ve atananlara hatırlatmalar ekleyin.
Gönderim öncesi ve istek listesinde kategori, durum, isteyen ile filtreleme sunun. “Benzer talepler” ve bilgi sayfalarına bağlantılar ekleyin ki kullanıcılar yaygın sorunları bilet açmadan çözebilsin.
Net bir talep veri modeli her şeyi kolaylaştırır: formlar tutarlı kalır, iş akışları otomatikleşebilir ve raporlama güvenilir olur. Organizasyonunuzda “talep”in ne olduğunu ve her defasında hangi detayların yakalanması gerektiğini belirleyerek başlayın.
İlk formı sade tutun ama alan ekibi aksiyon almaya yetecek kadar bilgi içersin. Pratik bir temel şunları içerir:
Kategoriler işi nasıl organize ediyorsanız ona göre olmalı (IT, Tesis, İK, Finans), alt kategorilerse tekrarlanabilir iş tiplerini (ör. IT → “Erişim Talebi”, “Donanım”, “Yazılım”) yansıtmalı. İsimleri kullanıcı dostu tutun ve kopyalardan kaçının (“Onboarding” vs “Yeni Çalışan Kurulumu”).
Kategori seçenekleri büyürse, raporlamayı korumak ve kafa karışıklığını azaltmak için bunları versiyonlayın, sessizce yeniden adlandırmayın.
Vagueden kaçınmak ve yönlendirme detaylarını sağlam tutmak için doğrulamalar kullanın:
Takımların farklı yorumlamayacağı basit bir yaşam döngüsü seçin ve her durumun ne anlama geldiğini tanımlayın:
Geçiş kurallarını yazın (kim Pending Approval'a geçirebilir? Waiting for Info ne zaman kullanılır?) ve durum değişiklikleri, atamalar, onaylar ile temel düzenlemelerin audit trailini saklayın.
Bir hizmet talebi web uygulaması, çalışanların talep göndermeyi ne kadar hızlı yaptığı ve ekiplerin bunu ne kadar kolay işlediğiyle başarılı olur veya başarısız olur. İnşa etmeden önce temel ekranları ve her rol için “mutlu yol”u taslaklayın: isteyen, onaylayan ve atanan.
Talep formunu tek bir göz korkutucu sayfa gibi değil, rehberli bir akış olarak ele alın. Kategori seçimine göre yalnızca gerekli alanları gösteren adım adım bölümler (veya progressive disclosure) kullanın.
Beklentileri açıkça gösterin: hangi bilgilerin gerekli olduğu, tipik yanıt süreleri ve gönderim sonrası ne olacağı. İpuçları ve yardımcı metinler geri-dönüşleri önler (“Ne ‘acil’ sayılır?” “Hangi dosyaları eklemeliyim?”).
Talepleri işleyenler için hızlı sıralama ve triaj yapmaya uygun bir inbox tarzı liste gerekir. Gerçek işi yansıtan filtreler ekleyin:
Satır tasarımları şu soruyu hemen cevaplamalı: “Bu ne ve bir sonraki adımım ne?”: başlık, isteyen, öncelik, mevcut durum, teslim tarihi/SLA göstergesi ve sonraki eylem.
Detay sayfası işbirliğinin yapıldığı yerdir. Şunları birleştirmelidir:
Birincil eylemleri belirgin tutun (onayla/reddet, ata, durumu değiştir) ve ikincil eylemleri keşfedilebilir ama dikkat dağıtmayacak şekilde sunun.
İlk wireframelerden itibaren erişilebilirliği planlayın: tüm eylemler için klavye navigasyonu, yeterli renk kontrastı (durum için sadece renge güvenmeyin) ve ekran okuyucularla çalışan okunabilir etiketler.
İş akışları basit bir “form + inbox”ı öngörülebilir bir hizmet deneyimine dönüştürür. Bunları erken tanımlayın ki talepler takılıp kalmasın, onaylar keyfi olmasın ve herkes “bitti”nin ne demek olduğunu bilsin.
Geri-dönüşleri azaltan temiz bir gönderim yolu ile başlayın:
Triaj sistemi paylaşılan bir posta kutusuna dönüşmesini engeller.
Onaylar politika temelli ve tutarlı olmalı:
Yükseltme ceza değil; bir güvenlik ağıdır.
İyi yapılmış iş akışları taleplerin ilerlemesini sağlar, çalışanlara öngörülebilir sonuçlar verir ve takımlara net sorumluluk sunar.
İyi bir veritabanı şeması hizmet talebi web uygulamanızı daha kolay bakım, raporlama ve evrim için hazırlar. Temel tablo seti ile başlayın, sonra esneklik ve analitik için destekleyici tablolar ekleyin.
Her ekranda dokunacağınız tablolarla başlayın:
requests.status kontrollü bir değer seti olsun ve yaşam döngüsü raporlaması için zaman damgalarını saklayın.
Farklı istek tiplerini tablo oluşturmak zorunda kalmadan desteklemek için:
Denetim izi için audit_events oluşturun: request_id, actor_id, event_type, old_value/new_value (JSON) ve created_at. Durum değişiklikleri, atama değişiklikleri ve onayları açıkça takip edin.
Raporlama için görünüm veya gerektiğinde ayrılmış tablolar kullanabilirsiniz:
requests(status, created_at), requests(assigned_team_id) ve audit_events(request_id, created_at) gibi indeksler ile yaygın sorguları hızlı tutun.
Bir hizmet talebi web uygulaması, değiştirmenin kolay olduğu zaman başarılı olur. İlk versiyonunuz yeni istek tipleri, onay adımları ve SLA kuralları eklendikçe evrilecektir—bu yüzden ekibinizin sürdürebileceği teknolojileri seçin, sadece trend olduğu için değil.
Çoğu iç hizmet talebi için “sıkıcı” seçimler kazanır:
Daha da hızlı gitmek istiyorsanız (özellikle iç araçlar için), çalışan bir temel oluşturmak amacıyla Koder.ai ile bir başlangıç üretmeyi düşünün. Koder.ai, sohbetle portalınızı tanımlayıp özelliklerde yineleme yapabildiğiniz bir vibe-coding platformudur. Koder.ai genellikle frontend için React, backend için Go + PostgreSQL hedefler, kaynak kodu dışa aktarma, dağıtım/barındırma, özel alan adları ve geri alma ile snapshot desteği sunar—iş akışı otomasyonunu hızla iyileştirirken faydalıdır. Fiyatlandırma Free, Pro, Business, Enterprise aralığında değişir, böylece taahhütte bulunmadan pilot yapabilirsiniz.
/requests, /approvals, /attachments gibi doğrudan uç noktalara ihtiyaç duyduğunuzda REST kullanın. UI'nız aynı talep verisinin birçok farklı, esnek görünümüne ihtiyaç duyuyorsa ve ekstra karmaşıklığa hazırsanız GraphQL değerlendirin.Mimari olarak, v1 için modüler bir monolit genellikle idealdir: istekler, onaylar, bildirimler, raporlama gibi açıkça ayrılmış modüllerle tek dağıtılabilir uygulama. Bu, mikroservislerden daha kolaydır ama sınırları temiz tutar.
İç talepler genellikle ekran görüntüleri, PDF'ler veya İK belgeleri içerir.
Container (Docker) kullanmak ortamları tutarlı kılar. Barındırma için organizasyonunuzun zaten kullandığı yönetilen platformu (PaaS veya Kubernetes) seçin. Seçiminiz şunları desteklemeli:
Seçim kriterlerinizi kısa ve belgelenmiş tutun—gelecekteki bakım yapanlar size teşekkür edecektir.
Güvenlik, iç bir hizmet talebi web uygulaması için “sonra” işi değildir. Çalışanlar tarafından kullanılsa bile kimlik verileri, talep detayları ve bazen hassas ekler (İK, finans, IT erişimi) ile uğraşacaktır. Erken dönemde birkaç temel uygulama acil yeniden çalışmayı önler.
Çalışanların kurumsal hesaplarını kullanmaları ve parola saklamaktan kaçınmak için SSO (SAML veya OIDC) tercih edin. Organizasyonunuz bir dizine (ör. Entra ID/Active Directory/Google Workspace) dayanıyorsa, joiner/mover/leaver güncellemeleri için onu entegre edin.
Erişimi role göre açık hale getirin: isteyenler, onaylayanlar, ajanlar ve adminler. Atanan destek grubunun yalnızca kendilerine atanan talepleri görmesini, çalışanların yalnızca kendi taleplerini (ve gerekirse departmanlarını) görmesini sağlayın.
Her yerde HTTPS kullanın (taşınmada şifreleme). Saklanan veriler için uygun alanları şifreleyin ve kimlik bilgilerini kodda tutmayın. Bir sır yöneticisi (cloud secret store veya vault) kullanın ve anahtarları düzenli döndürün.
Onaylar, erişim değişiklikleri veya bordro ile ilgili talepler için kim görüntüledi, oluşturdu, düzenledi, onayladı ve ne zaman yaptı şeklinde değiştirilemez bir denetim izi tutun. Denetim kayıtlarını ekleme/append-only olarak ele alın ve erişimi kısıtlayın.
Giriş ve kritik uç noktalar için hız sınırlama ekleyin, girdi doğrulama ve sterilizasyon yapın, dosya yüklemelerini tür/boyut açısından kontrol edin ve gerekiyorsa kötü amaçlı yazılım taraması uygulayın. Bu önlemler biletleme sisteminizin hatalar ve kötü kullanımlar altında güvenilir kalmasına yardımcı olur.
Bir hizmet talebi web uygulaması işe yaramazsa, insanlar talepleri görmez ve harekete geçmez. Entegrasyonlar portalınızı ekiplerin günlük rutinine uyan bir şeye dönüştürür; aksi halde “bir sekme daha” olur.
Eylemi tetikleyen küçük bir bildirim setiyle başlayın:
Mesajları kısa tutun ve isteğe derin linkler (deep links) ekleyin. Organizasyon Slack veya Teams ağırlıklıysa sohbet bildirimleri gönderin; yine de e-posta desteği sağlayın ki audit ve chat dışında kalan kullanıcılar da kapsansın.
Okta, Azure AD, Google Workspace gibi kimlik sağlayıcılardan senkronizasyon yaparak talepleri gerçek organizasyon yapısına bağlayın. Bu şunlara yardımcı olur:
Senkronizasyonu zamanlanmış ve login sırasında çalıştırın; köşe durumlar için basit bir admin geçersiz kılma tutun.
Talepler site içi ziyaret, görüşme veya ekipman teslimi gerektiriyorsa zaman önerileri sunmak ve onaylandığında etkinlik oluşturmak için takvim entegrasyonu ekleyin. Takvim etkinliklerini talepten türetilmiş olarak ele alın; talep ana doğruluk kaynağı olsun.
Yap ve satın al arasında karar verirken entegrasyon ihtiyaçlarınızı paket çözümlerle karşılaştırın; pricing hakkında bilgi veya ortak kalıplar için /blog/it-service-desk-basics gibi içeriğe bakın.
Hizmet talebi web uygulamanız performansı ölçmüyorsa, iyileştiremez. Raporlama darboğazları, personel ihtiyacını ve işin güvenilirliğini nasıl kanıtlayacağınızı gösterir.
Herkesin anlayacağı küçük bir SLA seti ile başlayın.
İlk yanıt süresi: gönderimden ilk insan etkileşimine kadar geçen süre (yorum, netleştirme isteği, atama veya durum güncellemesi). Beklentileri ayarlamak ve “görülüyor mu” takibini azaltmak için birebirdir.
Çözüm süresi: gönderimden tamamlanmaya kadar geçen süre. Uçtan uca teslimatı yansıtır.
SLA kurallarını kategori ve önceliğe göre açık yapın (ör. “Erişim talepleri: ilk yanıt 4 iş saati içinde, çözüm 2 iş günü içinde”). Ayrıca saat sayacını durduran durumları (istekçiden bekleme, üçüncü taraf onayları, eksik bilgi) belirleyin.
Raporlar sadece panolarda yaşamamalı. Ajanlar ve takım liderleri aksiyon alabilecekleri operasyonel ekranlara ihtiyaç duyar:
Bu görünümler SLA takibini aylık bir tablo olmaktan çıkarıp günlük işe dönüştürür.
Yönetimin hızlıca cevap alması için hafif bir pano kullanın:
Grafikleri tıklanabilir yapın ki liderler sayıların arkasındaki gerçek taleplere inebilsin.
İyi bir UI olsa bile bazı paydaşlar offline analiz isteyecektir. Filtrelenmiş listeler için CSV dışa aktarımı sağlayın (takım, kategori, tarih aralığı, SLA durumu gibi) ki finans, operasyon veya denetçiler tercih ettikleri araçlarda çalışsın.
Öncelikle dar, yüksek hacimli bir kapsam seçin (örneğin IT erişim talepleri + Tesis onarımları). Bugün nelerin kötü işlediğini belgeleyin (gömülü e-postalar, belirsiz sahiplik, iz bırakmayan onaylar), birincil kullanıcıları tanımlayın (istekte bulunanlar, onaylayanlar, çözücüler, yöneticiler) ve ölçülebilir başarı metrikleri belirleyin (ör. “her talebe 1 iş saati içinde bir sahibi atansın”).
Çoğu iç talep tekrar eden kategorilere girer:
Sıklıkla görülen ve acı veren kategorilerle başlayın, sonra iş akışları stabil hale geldikçe genişletin.
Küçük ve açık bir rol seti kullanın, her rolün izinlerini netleştirin:
Kötü bir talep gönderilmesini zorlaştırmaya odaklanın:
Kaliteli bir giriş, takipleri azaltır ve yönlendirme ile onay süreçlerini hızlandırır.
v1 için yönlendirme öngörülebilir ve basit olsun:
Kural editörünü sade tutun; gerçek kullanım desenlerini gördükçe karmaşıklık ekleyebilirsiniz.
Önce tek adımlı onay ile başlayın (yönetici veya bütçe sahibi). Büyüme için:
Çok adımlı zincirleri, ilk günün en sık görülen istek tipleri değilse erteleyin.
Küçük, ortak bir durum yaşam döngüsü kullanın ve her durumun ne anlama geldiğini yazılı hale getirin, örneğin:
Kimin hangi geçişi yapabileceğini yazın ve durum değişiklikleri, atamalar ve onaylar için bir audit trail saklayın.
v1 için üç temel ekran ve güçlü bir detay görünümü düşünün:
Erişilebilirliği baştan planlayın (klavye erişimi, kontrast, ekran okuyucu etiketleri).
Pratik bir şema şunları içerir:
Erken dönemde kurumsal temelleri önceliklendirin:
Spesifikasyonunuzda basit bir RACI ekleyin ki sahiplik ve devralmalar belirsiz olmasın.
users, roles, user_roles, teams, requests, comments, attachmentscategories, form_fields, request_field_valuesapprovals, sla_policiesaudit_eventsOrtak sorguları indeksleyin (ör. requests(status, created_at) ve audit_events(request_id, created_at)) ki kuyruklar ve zaman çizelgeleri hızlı kalsın.
Bu seçimler, İK/finans/güvenlik talepleri gelince yeniden çalışmayı önler.