Sakin Talebinden İş Emrine: Site Arıza Yönetimi Akışı

Site arıza talep yönetimi, bir sakinin bildirimini yalnızca mesaj olarak saklamak değil; talebi sınıflandırılmış, sorumlusu belirlenmiş, sahada uygulanabilir ve sonucu doğrulanabilir bir iş akışına dönüştürmektir. Sağlıklı süreçte talep ile iş emri ayrı kayıtlardır: Talep ihtiyacı ve bağlamı anlatır; iş emri ise kimin, nerede, hangi kapsamda ve hangi kapanış ölçütüyle çalışacağını belirler.

Bu rehber, ortak alan arızaları ve operasyon talepleri için uygulanabilir bir yönetim modeli sunar. Teknik teşhis, iş güvenliği talimatı veya acil durum prosedürü yerine geçmez. Can ve mal güvenliğini etkileyen durumlar standart talep kuyruğunda bekletilmemeli; sitenin acil durum planı ve yetkili servis kanalı kullanılmalıdır.

Site arıza talep yönetimi nedir?

Arıza talep yönetimi; bildirimin alındığı andan çözüme ilişkin kaydın kapatılmasına kadar geçen sürecin tek bir iz üzerinde yönetilmesidir. Bu iz üzerinde en az talebin kaynağı, konumu, kategorisi, önceliği, sorumlusu, durum geçmişi, yapılan işlem, kontrol sonucu ve kapanış zamanı görünmelidir.

Liyova Talep Yönetimi, sakinlerden gelen talepleri kategori, öncelik, durum, konuşma geçmişi ve görsel kayıtlarla ortak bir çalışma alanında izlemeye yardımcı olur. Saha çalışması gereken kayıtlar iş emrine dönüştürülebilir; yalnızca bilgi veya yönetim yanıtı gerektiren talepler ise gereksiz teknik görev üretmeden kendi akışında sonuçlandırılabilir.

Talep ile iş emri arasındaki farkı baştan belirleyin

Talep ile iş emrini aynı kayıt gibi kullanmak iki soruna yol açar. Birincisi, her sakin mesajı teknik görev olarak algılanır ve ekip kuyruğu gereksiz kayıtlarla dolar. İkincisi, sahaya aktarılması gereken gerçek işlerde görev kapsamı, sorumlu ve kapanış ölçütü belirsiz kalır. Sahip, girdi, çıktı, durum ve kapanış ölçütlerini yan yana değerlendirmek için talep ile iş emri arasındaki fark rehberini kullanabilirsiniz.

Alan	Talep kaydı	İş emri
Amaç	İhtiyacı, sorunu veya bildirimi kaydetmek	Yapılacak saha işini tanımlamak ve yürütmek
Sahibi	Talebi karşılayan yönetim veya destek sorumlusu	Atanan personel, ekip ya da dış servis
Temel bilgi	Konum, açıklama, kategori, etki ve görsel	Kapsam, sorumlu, hedef zaman, uygulama ve kontrol
Kapanış	Talep sahibine sonuç bildirildiğinde ve kayıt doğrulandığında	Tanımlanan iş tamamlanıp kanıt ve kontrol sonucu işlendiğinde

Örneğin “havuz kullanım saatleri nedir?” sorusu bir bilgi talebidir ve iş emri gerektirmez. “B blok girişindeki sensörlü aydınlatma çalışmıyor” bildirimi ise konum, etki ve teknik müdahale ihtiyacı doğrulandıktan sonra iş emrine dönüşebilir.

1. Arıza bildirimini standart alanlarla alın

Sözlü bildirim, telefon notu ve mesajlaşma grubu ilk temas için kullanılabilir; ancak nihai kayıt tek bir ana sisteme aktarılmadığında hangi sürümün güncel olduğu belirsizleşir. Her talepte şu bilgiler bulunmalıdır:

• Blok, kat, ortak alan veya ekipman gibi açık konum bilgisi,
• Gözlenen sorun ve ne zamandır sürdüğüne ilişkin kısa açıklama,
• Teknik arıza, temizlik, güvenlik, peyzaj veya idari talep gibi kategori,
• Kaç kişi veya alanın etkilendiği,
• Durumu açıklayan, gereksiz kişisel veri içermeyen görsel veya belge,
• Geri dönüş yapılacak kanal ve erişim için gerekli operasyon notu.

Talep formu kullanıcıdan teknik teşhis istememelidir. “Motor kondansatörü arızalı” demek yerine “otopark kapısı açılırken duruyor ve ses çıkarıyor” gibi gözlenebilir durumu kaydetmek, teknik ekibin ön yargısız inceleme yapmasını kolaylaştırır. Fotoğrafta yüz, daire içi veya özel belge gibi gereksiz kişisel verilerin görünmemesine dikkat edilmelidir.

Aynı sorun için gelen tekrar bildirimleri birleştirin

Bir su kesintisi için on farklı talep açıldığında on ayrı iş emri üretmek yerine, ana kaydı belirleyip diğer bildirimleri bu kayda bağlayın. Böylece etkilenen kişi sayısı görünür kalır; ekip aynı işi tekrar tekrar incelemez. İletişim güncellemeleri de ana kayıt üzerinden tutarlı biçimde paylaşılabilir. Ortak duyuru ile kişisel talep yanıtını doğru hedef kitle, kanal ve kayıtla ayırmak için site sakin iletişimi rehberine bakabilirsiniz.

2. Önceliği yalnızca “acil” etiketine bırakmayın

Öncelik, talebi yazan kişinin seçtiği bir sıfat değil; etki ve aciliyetin birlikte değerlendirildiği yönetim kararıdır. Her site kendi yapısına uygun bir matris tanımlamalıdır. Aşağıdaki örnek evrensel süre taahhüdü değil, sınıflandırma başlangıcıdır:

• Kritik: Can veya mal güvenliği riski ya da temel hizmette ciddi kesinti şüphesi vardır. Standart kuyruk yerine acil prosedür çalıştırılır.
• Yüksek: Birden fazla bağımsız bölüm veya ortak alanın kullanımı belirgin biçimde etkilenir.
• Normal: Sorun sınırlı bir alanı etkiler; geçici kullanım veya alternatif mümkündür.
• Düşük: Kozmetik iyileştirme, öneri veya planlı değerlendirme niteliğindedir.

Önceliğin yanında hedeflenen ilk değerlendirme zamanı ve gecikme halinde kime aktarılacağı da tanımlanmalıdır. Sabit bir süreyi bütün talep türlerine uygulamak yerine kategori, risk, erişim ve dış servis bağımlılığı birlikte değerlendirilmelidir.

3. Talebi inceleyin ve doğru sonraki aksiyona yönlendirin

Her yeni kayıt kısa bir ön incelemeden geçmelidir. Bu aşamada talebin kapsamı netleştirilir ve aşağıdaki yollardan biri seçilir:

1. Bilgi veya idari yanıt: Saha işi gerektirmeyen talep yönetim tarafından yanıtlanır.
2. Mükerrer kayıt: Mevcut ana taleple ilişkilendirilir.
3. Kapsam dışı veya başka sorumlu: Gerekçesi ve doğru başvuru kanalı kayda eklenir.
4. Teknik inceleme gerekli: Saha kontrolü için iş emri oluşturulur.
5. Planlı iş: Acil olmayan ancak bakım takvimine alınması gereken kayıt uygun döneme planlanır.

Bu ayrım “reddedildi” gibi açıklamasız bir durumdan daha değerlidir. Talep sahibinin ne olacağını anlayabilmesi için seçilen yol, gerekçe ve bir sonraki kontrol tarihi görünür olmalıdır.

4. İş emrini sahada uygulanabilir hale getirin

İş emri, talep metninin kopyası değildir. Atanan kişinin ek görüşme yapmadan nerede başlayacağını ve işin ne zaman tamamlanmış sayılacağını anlayabileceği kadar açık olmalıdır. İyi bir iş emrinde şu alanlar bulunur:

• Sorumlu personel, ekip veya dış servis,
• İşin konumu ve kapsam sınırı,
• Öncelik ile hedef ilk işlem zamanı,
• Erişim, güvenlik veya eşlik gereksinimi,
• Beklenen uygulama notu ve kontrol yöntemi,
• Dış servis, malzeme veya onay gibi bağımlılıklar,
• İşin kapanması için gerekli kanıt.

Liyova İş Emirleri, talep veya planlı bakım kaynaklı işleri personele atama, durumla takip etme ve operasyon raporuna taşıma akışı sunar. Talep kaydının iş emriyle bağlantısı korunursa yönetim, sakinin bildirdiği ihtiyaç ile sahada yapılan işi aynı bağlamda inceleyebilir.

5. Beklemeyi görünür bir durum olarak yönetin

Bir işin aktif olarak yürütülmesi ile parça, dış servis, erişim veya onay beklemesi aynı durum değildir. “İşlemde” etiketi haftalarca değişmeden kalırsa kuyruk gerçeği yansıtmaz. Bekleyen kayıtta en az bekleme nedeni, sorumlu taraf, beklenen tarih ve yeniden kontrol zamanı bulunmalıdır.

Örnek bir durum modeli şöyle kurulabilir:

Durum	Anlamı	Zorunlu sonraki bilgi
Yeni	Kayıt alındı, henüz incelenmedi	İnceleme sorumlusu
İncelemede	Kategori, kapsam ve öncelik değerlendiriliyor	Karar veya ek bilgi isteği
Atandı	Sorumlu belirlendi	Hedef başlangıç zamanı
Çalışılıyor	Sahada aktif işlem var	Son işlem notu
Beklemede	Bir bağımlılık nedeniyle ilerleyemiyor	Neden ve yeniden kontrol tarihi
Doğrulamada	Uygulama bitti, sonuç kontrol ediliyor	Kontrol sonucu
Kapalı	Kapanış ölçütleri karşılandı	Sonuç kodu ve bildirim kaydı

6. Müdahale notunu ve kapanış kanıtını kaydedin

“Yapıldı” veya “çözüldü” tek başına yeterli bir kapanış kaydı değildir. Müdahale notunda gözlenen durum, uygulanan işlem, kullanılan malzeme veya dış servis bilgisi, başlangıç ve bitiş zamanı ile varsa sonraki bakım önerisi bulunmalıdır. Kanıt, işin niteliğine göre fotoğraf, test sonucu, kontrol listesi veya yönetici doğrulaması olabilir.

Kapanıştan önce şu dört soruyu yanıtlayın:

1. İş emrinde tanımlanan kapsam tamamlandı mı?
2. Sonuç güvenli ve uygun yöntemle kontrol edildi mi?
3. Talep kaydı ile iş emri aynı sonuç bilgisini gösteriyor mu?
4. Talep sahibine veya ilgili gruba anlaşılır bir durum güncellemesi yapıldı mı?

Kontrol başarısızsa kaydı kapatıp yeni bir talep açmak yerine iş emrini yeniden çalışmaya almak, sorunun geçmişini korur. Farklı bir kök neden ortaya çıktıysa bağlantılı yeni iş emri oluşturulabilir.

Arıza yönetiminde rol ve sorumlulukları ayırın

Küçük bir apartmanda aynı kişi birkaç rolü üstlenebilir; büyük bir sitede görevler farklı ekiplerde olabilir. Ölçek ne olursa olsun her adımın sahibi görünür olmalıdır.

• Sakin veya bildirimi yapan kişi: Gözlenebilir sorunu, konumu ve gerekli bağlamı iletir.
• Talep sorumlusu: Kaydı temizler, mükerrerleri birleştirir ve eksik bilgiyi tamamlar.
• Yönetici veya operasyon sorumlusu: Öncelik verir, kapsamı belirler ve iş emrini atar.
• Personel veya dış servis: Uygulamayı, süreyi ve sonucu kaydeder.
• Kontrol sorumlusu: Kapanış ölçütünü doğrular ve gerekli bildirimi tamamlar.

Aynı kişinin hem uygulayıcı hem kontrol eden olması küçük yapılarda kaçınılmaz olabilir. Bu durumda kapanış notu, zaman ve kanıt alanlarının eksiksiz tutulması sonradan inceleme yapılabilmesini sağlar.

Raporlarda yalnızca kapanan iş sayısına bakmayın

Yüksek kapanış sayısı tek başına iyi operasyon anlamına gelmez. Yeniden açılan işler, uzun süre bekleyen kayıtlar veya aynı kategori ve konumda tekrarlayan arızalar görünmüyorsa sorun yalnızca raporun dışına taşınmış olabilir. Yönetim görünümünde şu sorulara yanıt arayın:

• Önceliğe göre kaç açık talep ve iş emri var?
• Hangi kayıtlar dış servis, malzeme, erişim veya onay bekliyor?
• En uzun süredir açık kayıtların sonraki aksiyonu belli mi?
• Kaç iş doğrulama sonrası yeniden açıldı?
• Aynı konum veya kategoride tekrar eden arıza var mı?
• Talep ile iş emri arasında sahipsiz kalan kayıt bulunuyor mu?

Liyova Raporlar, talep ve iş emri verisini finans ve diğer yönetim verileriyle ortak bir raporlama standardına yaklaştırır. Raporlamanın amacı yalnızca ay sonu sayısı üretmek değil, bekleyen işin nedenini ve alınacak sonraki kararı görünür kılmaktır.

Sorumlu, kontrol noktası, kanıt ve sonraki adım yaklaşımı farklı yönetim süreçlerinde de kullanılabilir. Finans operasyonu için aynı çerçevenin uygulamasını site aidat takibi rehberinde inceleyebilirsiniz.

Sık yapılan arıza ve talep yönetimi hataları

• Her bildirimi iş emrine çevirmek: Bilgi talepleri teknik kuyruğu gereksiz yere büyütür.
• Önceliği açıklamasız vermek: Benzer talepler arasında tutarsızlık oluşur.
• Sorumluyu ekip adıyla bırakmak: Kaydın gerçek sahibi belirsiz kalır.
• Bekleme nedenini kaydetmemek: Gecikme ile aktif çalışma birbirine karışır.
• Kanıtsız kapatmak: Yapılan iş ve kontrol sonucu sonradan açıklanamaz.
• Mükerrer talepleri ayrı ayrı yürütmek: Ekip aynı soruna birden fazla kez atanabilir.
• Talep sahibine sonuç bildirmemek: Teknik iş bitse bile kullanıcı açısından süreç açık kalır.

Arıza yönetimi yazılımını gerçek senaryoyla değerlendirin

Bir ürünü değerlendirirken yalnızca “talep modülü var mı?” sorusu yeterli değildir. Demoda aynı sorun için mükerrer iki bildirim açın, önceliği değiştirin, birini iş emrine dönüştürün, sorumlu atayın, bekleme nedeni ekleyin, uygulama kanıtı girin ve sonucu doğrulayarak kapatın. Ardından talep ile iş emri geçmişinin ve raporun aynı sonucu gösterip göstermediğini kontrol edin.

Finans, operasyon, sakin deneyimi, raporlama ve yetkilendirmeyi birlikte değerlendirmenize yardımcı olacak daha geniş kontrol listesi için site yönetim programı seçme rehberini kullanabilirsiniz.

Site arıza talep yönetimi hakkında sık sorulan sorular

Her sakin talebi iş emrine dönüşmeli mi?

Hayır. Bilgi isteği, öneri, mükerrer bildirim veya başka bir sorumluluk alanına ait kayıt doğrudan teknik iş emri olmamalıdır. Saha uygulaması gereken ve kapsamı doğrulanan talepler iş emrine dönüştürülmelidir.

İş emrini kim kapatmalı?

Uygulamayı yapan kişi işi tamamlandı olarak işaretleyebilir; nihai kapanış yetkisi ise sitenin kontrol modeline göre belirlenmelidir. Önemli olan uygulama notu, kontrol sonucu, kanıt ve bildirim kaydının kapanıştan önce tamamlanmasıdır.

Dış servis veya malzeme bekleyen iş nasıl izlenir?

Kayıt “beklemede” durumuna alınmalı; bekleme nedeni, sorumlu taraf, beklenen tarih ve yeniden kontrol zamanı yazılmalıdır. Böylece aktif çalışma süresi ile dış bağımlılık nedeniyle geçen süre birbirinden ayrılır.

Tekrarlayan arızalar nasıl fark edilir?

Kategori, konum, ekipman ve sonuç kodları tutarlı kullanılırsa aynı alan veya ekipmandaki tekrarlar raporda gruplanabilir. Sadece serbest metinle kayıt tutulması, benzer sorunların farklı adlarla dağılmasına yol açar.

Arıza kaydında fotoğraf zorunlu mu?

Her talep için zorunlu değildir. Görsel, konumu veya sorunu açıklamaya gerçekten yardımcı olduğunda istenmelidir. Gereksiz kişisel veri, özel alan veya güvenlik bilgisi içeren görüntüler kayda eklenmemelidir.

Talebi kapanışa kadar tek bağlamda yönetin

Liyova ile sakin talebini kategori ve öncelikle kaydedebilir, saha işi gerektiğinde iş emrine dönüştürebilir, atama ve durum adımlarını izleyebilir ve operasyon sonucunu raporlayabilirsiniz. Kendi sitenizdeki arıza akışını birlikte değerlendirmek için demo talebi oluşturun.