Sipariş Girişi Otomasyonu: E-postadan ERP'ye

Müşteri siparişi gönderiyor: e-postanın gövdesine yazılmış üç kalem, ekte bir Excel, bazen taranmış bir sipariş formu. Müşteri temsilcisi bunu okuyor, ürünleri kendi kodlarınıza çeviriyor, ERP ekranına satır satır giriyor. Günde 60 sipariş geliyorsa bu, iki kişinin tam zamanlı işi.

Bu yazı o işin nasıl otomatikleştiğini, hangi kararın insanda kalması gerektiğini, doğruluğun nasıl ölçüleceğini ve hangi durumda otomasyon yerine başka bir şeyin doğru cevap olduğunu anlatıyor.

Elle sipariş girişinin dört maliyeti

Yazım hatası siparişe geçiyor. 120 yerine 1200 girilen adet, sevkiyat çıkana kadar fark edilmiyor. Geri dönüş maliyeti girişin kendisinden kat kat yüksek.

Yanlış ürün kodu eşleşiyor. Müşteri kendi adlandırmasıyla yazıyor, temsilci en yakın gördüğü kodu seçiyor. Yanlış varyant sevk ediliyor.

Gecikme sıraya biniyor. Sipariş sabah geliyor, öğleden sonra giriliyor. Stok tahsisi o aralıkta başka bir siparişe gidiyor.

Kimin ne zaman girdiği izlenemiyor. Bir sipariş kaybolduğunda e-posta kutularında arama başlıyor. Hangi e-postanın hangi siparişe dönüştüğü kayıtlı değil.

Dördünün ortak noktası, hepsinin “dikkatsizlik” başlığı altında geçiştirilmesi. Oysa hiçbiri dikkat sorunu değil; sürecin insan hafızasına ve el hızına bağlı olmasının doğal sonucu.

Otomasyon mekanik olarak ne yapıyor

Beş adım. Her adım ayrı ayrı doğrulanabilir olmalı, yoksa hata nerede oluştu bilinmez.

1. Yakalama. Tanımlı bir e-posta kutusu izleniyor. Gövde metni, PDF ekleri ve Excel ekleri ayrı ayrı alınıyor.

2. Sınıflandırma. Gelen e-posta sipariş mi, sipariş değişikliği mi, teklif talebi mi, başka bir şey mi? Yanlış sınıflandırma en pahalı hata türü olduğu için bu adımda eşik yüksek tutulur; emin olunmayan e-posta insana gider.

3. Çıkarma. Kalem adı, miktar, birim, istenen teslim tarihi, teslim adresi, müşteri referans numarası. Excel eklerinde sütun başlıkları değişse bile alanların anlamı üzerinden okunur.

4. Eşleştirme. Müşterinin yazdığı ürün adı sizin ürün kodunuza bağlanır. Burada üç kaynak birlikte kullanılır: ürün kataloğu, müşterinin geçmiş siparişleri ve varsa müşteriye özel ürün kodu tablosu. Her eşleşme bir güven seviyesiyle işaretlenir.

5. Yazma. Sipariş ERP’ye taslak olarak yazılır. Serbest bırakılmaz.

Kural tabanlı okuma ile yapay zekâ destekli okumanın farkı

Durum	Şablon/kural tabanlı	Yapay zekâ destekli
Sabit düzenli PDF	Yüksek doğruluk, düşük maliyet	Yüksek doğruluk, gereksiz maliyet
Her müşteride farklı düzen	Her düzen için ayrı kurulum	Kurulum gerektirmeden okur
Düzen değişirse	Sessizce bozulur	Genellikle dayanır
E-posta gövdesinde serbest metin	Çalışmaz	Çalışır
Ürün adı yaklaşık yazılmış	Eşleşmez	Aday gösterir, güven seviyesi verir
"Geçen seferkinin aynısı" cümlesi	Çalışmaz	Geçmiş siparişten aday üretir, insana sorar
Maliyet	Kurulumda yüksek, işletmede düşük	Kurulumda düşük, işletmede belge başına ücret
Denetlenebilirlik	Kural okunur	Güven seviyesi ve kaynak alıntısı gerekir

Doğru cevap çoğu zaman karışım: yapılandırılmış gelen kanallar (portal, EDI, e-posta ekindeki standart Excel) kural tabanlı işlenir, düzensiz gelenler yapay zekâya yönlendirilir. Bu ayrım işletme maliyetini belirgin biçimde düşürür.

Somut senaryo: 60 sipariş/gün alan bir distribütör

Girdi. Günde ortalama 60 sipariş. %25’i bayi portalından yapılandırılmış geliyor, %45’i e-posta ekinde Excel, %20’si PDF, %10’u e-posta gövdesinde serbest metin.

Bugünkü akış. İki müşteri temsilcisi siparişleri okuyup ERP’ye giriyor. Yoğun günlerde giriş ertesi güne sarkıyor.

Otomasyonlu akış.

1. Portal siparişleri doğrudan ERP’ye yazılıyor; otomasyona hiç uğramıyor.
2. Excel ekleri sütun anlamı üzerinden okunuyor.
3. PDF ve serbest metin siparişler çıkarımdan geçiyor.
4. Her satır ürün koduyla eşleştiriliyor ve güven seviyesi atanıyor. Yüksek güvenli satırlar hazır geliyor, düşük güvenli satırlar sarı işaretleniyor.
5. Sipariş ERP’de taslak olarak açılıyor ve temsilcinin kuyruğuna düşüyor.
6. Müşteriye “siparişiniz alındı, teyit ediyoruz” bildirimi gidiyor.

İnsan onayı nerede. Temsilci ekranda solda orijinal belgeyi, sağda çıkarılan satırları görüyor. Sarı işaretli satırları düzeltiyor, stok ve teslim tarihini kontrol ediyor, siparişi serbest bırakıyor. Teyit bildirimi ancak bu andan sonra gidiyor.

Çıktı. Temsilcinin işi “veri girmek”ten “kontrol etmek”e dönüşüyor. Sipariş başına süre düşüyor, akşama sarkan kuyruk kayboluyor ve hangi e-postanın hangi siparişe dönüştüğü kayıt altına giriyor.

Neden serbest bırakmayı otomasyon yapmıyor? Çünkü serbest bırakılan sipariş stok tahsis eder, üretim planına girer ve müşteriye taahhüt doğurur. Bu geri alınabilir bir işlem değil. Doğruluk %98 bile olsa, kalan %2 taahhüt hatasıdır.

Doğruluğu nasıl ölçmeli

Otomasyon tekliflerinde en çok kullanılan ve en az anlamlı sayı “%99 doğruluk”. Sorulacak üç soru:

Hangi seviyede? Alan seviyesi mi, satır seviyesi mi, belge seviyesi mi? Alan seviyesinde %99, 20 alanlı bir belgede belge başına ortalama bir hata demek.

Hangi belge kümesinde? Tedarikçinin kendi temiz örnek setinde mi, sizin gerçek siparişlerinizde mi?

Dokunulmadan geçen oran ne? Sektör kaynakları standart sipariş tiplerinde insan eli değmeden ERP’ye yazılan sipariş oranının %80 üstünü hedeflediğini belirtiyor. Asıl mesele geri kalanın ne kadar hızlı çözüldüğü.

Kabul testi için pratik yöntem: son altı ayın gerçek siparişlerinden rastgele 100 tane seçin, doğru sonuçlarını elle yazın, pilotu bu set üzerinde çalıştırın. Çirkin örnekleri ayıklamayın; test edilmesi gerekenler tam olarak onlar.

Ürün eşleştirme nasıl doğrulaşır

Sipariş girişi otomasyonunda okuma tarafı genellikle beklenenden kolay, eşleştirme tarafı beklenenden zor çıkıyor. Sebebi basit: müşteri ürünü sizin kodunuzla değil, kendi diliyle yazıyor. “10’luk siyah kablo kanalı”, “kanal 10x20 siyah” ve “KK-1020-S” aynı ürün olabilir.

Eşleştirmeyi güvenilir hâle getiren dört kaynak var ve dördü birlikte kullanılmalı:

1. Ürün kataloğu ve eş anlamlılar. Kod, ad, ölçü, renk, birim. Katalogda tek bir ürünün üç kaydı varsa eşleştirme her koşulda hatalı olur; bu yüzden katalog temizliği projenin ön koşuludur.

2. Müşterinin geçmiş siparişleri. En güçlü sinyal bu. Aynı müşteri aynı ifadeyi daha önce kullandıysa ve o sipariş onaylandıysa, eşleşme neredeyse kesin.

3. Müşteriye özel kod tablosu. Kurumsal müşteriler kendi malzeme kodlarıyla sipariş verir. Bu tablo bir kez kurulduğunda o müşterinin siparişlerinin tamamı otomatik geçer.

4. Düzeltme geçmişi. Temsilcinin yaptığı her düzeltme kaydedilir ve sonraki eşleştirmelerde kullanılır. Bu döngü olmadan sistem ilk günkü doğrulukta kalır.

Dördüncü maddenin pratik anlamı şu: ilk ay doğruluk ortalamanın altında olur ve bu normaldir. Kabul kararını ilk haftaya göre değil, düzeltme oranının seyrine göre verin.

Dört haftada devreye alma

1. hafta. Son altı ayın gerçek siparişlerinden 100 örnek seçilir, doğru sonuçları elle yazılır. Kanal dağılımı ölçülür. ERP’ye yazma yöntemi doğrulanır.

2. hafta. Okuma ve çıkarma katmanı kurulur, test seti üzerinde ilk doğruluk ölçümü alınır. Eşleştirme kaynakları bağlanır.

3. hafta. Kontrol ekranı, istisna kuyruğu ve ERP’ye taslak yazma kurulur. Alındı bildirimi akışı tanımlanır.

4. hafta. Paralel çalışma. Sistem gerçek siparişleri işler, temsilci hem sistemin çıktısını hem kendi girişini yapar, ikisi karşılaştırılır. Fark oranı kabul edilebilir seviyeye indiğinde elle giriş bırakılır.

Dördüncü haftayı atlamak kısa vadede bir hafta kazandırıyor, ilk hatada ise sistemin tamamen terk edilmesine yol açıyor. Paralel dönem, teknik bir adım değil güven inşa etme adımı.

Kurulum ne kadar tutar

Tek süreçlik kurulum 80.000-150.000 ₺ bandında, 2-4 haftada devreye giriyor. Bandın neresine düştüğünü belirleyen üç şey:

• Kanal karışımı. Yapılandırılmış gelen oran ne kadar yüksekse iş o kadar az.
• ERP erişimi. Belgelenmiş API mı, içe aktarma dosyası mı, doğrudan veritabanı mı?
• Ürün eşleştirmenin zorluğu. Müşteriye özel kod tablosu var mı, varyant sayısı ne?

Bayi portalı, müşteriye özel fiyat kuralları veya sevkiyat planlama gibi ekler 8.000-45.000 ₺ bandında ek modül olarak fiyatlanıyor. Bant tablosunun tamamı fiyat sayfasında.

Ne zaman yapmayın

Günlük sipariş sayısı 15’in altındaysa yapmayın. Bu hacimde iyi hazırlanmış bir giriş ekranı ve kısayollar aynı kazancı üretir.

Siparişlerin çoğu zaten portaldan geliyorsa yapmayın. Kalan e-posta kanalı küçükse kapsam kurulum bedelini karşılamaz. Bunun yerine portal kullanımını artırmak daha ucuz; bayi sipariş sistemi kurulumu yazısı bu yolu anlatıyor.

Ürün kataloğunuz düzensizse önce onu düzeltin. Aynı ürünün üç kodu varsa eşleştirme her koşulda hatalı olur. Katalog temizliği otomasyondan ucuz ve her hâlükârda gerekli.

Fiyat ve stok kararı otomatik verilecekse yapmayın. Sipariş girişi ile fiyatlandırma farklı işler. Otomasyon miktarı ve ürünü okur; fiyat ve tahsis kararı sistemin kural motorunda veya insanda kalır.

Müşteriye teyit bildirimini otomasyon gönderecekse yapmayın. Teyit taahhüttür. Alındı bildirimi otomatik gidebilir, teyit gidemez.

Süreç önümüzdeki aylarda değişecekse bekleyin. ERP değişimi planlıyorsanız sipariş girişi otomasyonunu yeni sistemin üzerine kurun; iki kez ödemeyin.

Kendi durumunuzu ölçün

Beş rakam, bir hafta.

1. Günlük sipariş adedi ve kanal dağılımı. Portal / Excel / PDF / serbest metin yüzdeleri.
2. Sipariş başına ortalama giriş süresi. Bir hafta ölçün. Adet × dakika × 250 iş günü = yıllık dakika.
3. Son altı ayda kaç sipariş yanlış girildi ve düzeltmesi ne kadar tuttu? Sevkiyat dönüşü, iptal, müşteri kaybı dahil.
4. Sipariş geldikten sonra ERP’ye girilene kadar geçen ortalama süre. Bu rakam çoğu şirkette hiç ölçülmemiştir ve otomasyondan en hızlı etkilenen değerdir.
5. Kaç farklı müşteri, kaç farklı sipariş düzeni? 10 müşteri 10 düzen ile 200 müşteri 10 düzen çok farklı iki iştir.

İkinci maddedeki yıllık dakikayı saate çevirip saatlik maliyetle çarpın, üçüncü maddedeki düzeltme maliyetini ekleyin. Çıkan yıllık rakamı kurulum bandına bölün. İki yılın altında dönüyorsa iş konuşmaya değer; üstündeyse kanal karışımınız muhtemelen otomasyona uygun değil.

Sonraki adım

Süreç otomasyonuna yaklaşımımız iş süreci otomasyonu sayfasında, ERP bağlantı yöntemleri entegrasyon sayfasında, bantlar fiyat sayfasında. Fatura tarafındaki eşleştirmeyi fatura eşleştirme otomasyonu yazısında, gelen e-postanın sınıflandırılmasını e-posta triyajı yazısında anlattık. Yukarıdaki beş rakamı çıkarıp teklif formuyla gönderin; hangi kanalla başlanması gerektiğini o tablo üzerinden konuşalım.

---

İlgili Depo Rehberleri ve Hesaplayıcılar

• Sevkiyat Hatası ve İade Maliyeti Hesaplayıcı — Deponuzdaki yanlış ürün gönderimlerinin yıllık çift kargo maliyetini hesaplayın.
• En İyi WMS ve Barkodlu Depo Yönetim Programları — Logo, Mikro, Nebim, DİA ve özel WMS sistemleri karşılaştırması.
• Depo Sevkiyat ve Barkod Kontrol Fiyatları — Paketleme masası ve doğrulama istasyonu bütçe rehberi.
• WMS Depo Yazılımı Fiyatları 2026 — Depo otomasyonu ve adresli raf yönetimi maliyetleri.

Sıkça sorulan sorular

Müşterilerimiz standart bir form kullanmıyor, yine de çalışır mı?

Çalışır ama doğruluğu ölçmeden devreye almayın. Şablon tanımına dayanan eski nesil okuma araçları her müşteri düzeni için ayrı kurulum ister; anlamsal çıkarım kullanan tasarım düzen farkına dayanır. Yine de ilk aylarda düzeltme yaparak doğruluğu yükseltmeniz gerekir ve bu emek planlanmalıdır.

Yanlış sipariş girerse ne olur?

Otomasyon siparişi taslak olarak açar, serbest bırakmaz. Müşteri temsilcisi ekranda faturayı, çıkarılan satırları ve eşleşme güven seviyesini yan yana görür, onaylar veya düzeltir. Serbest bırakma tuşuna insan basar; bu yüzden yanlış okuma bir hataya değil, bir düzeltmeye dönüşür.

Doğruluğu nasıl ölçeriz?

Tek doğru ölçüt satır seviyesinde doğruluktur, belge seviyesinde değil. 20 satırlık bir siparişte 19 satır doğruysa belge 'başarısız' sayılır çünkü insan yine de tüm satırı kontrol eder. Kabul testinde en az 100 gerçek sipariş kullanın ve dokunulmadan geçen sipariş oranını ayrıca ölçün.

ERP'mize nasıl yazıyor?

Tercih sırası şu: belgelenmiş API, ardından ERP'nin kendi içe aktarma dosyası, en son çare veritabanına doğrudan yazma. Logo, Netsis, Mikro ve SAP tarafında bu üç yoldan biri her zaman var. Hangi yolun seçildiği kurulum süresini ve kırılganlığı belirler; teklifte açıkça yazılmalıdır.

Müşteri sipariş verdiğini nasıl bilecek?

Sistem, siparişi taslak olarak açtığında otomatik bir alındı bildirimi gönderebilir; bunu tavsiye ediyoruz çünkü müşterinin en sık sorduğu soru budur. Teyit bildirimi ise ancak temsilci siparişi serbest bıraktıktan sonra gitmelidir. Bu ikisini karıştırmak, teslim edilemeyecek bir siparişi teyit etmek anlamına gelir.

Bayi portalı kurmak daha iyi olmaz mı?

Genelde olur ama ikisi rakip değil. Portal, siparişi baştan yapılandırılmış hâle getirdiği için en temiz çözümdür. Sorun şu: müşterilerin bir kısmı portalı hiçbir zaman kullanmaz ve e-posta göndermeye devam eder. Portalı kurun, e-posta kanalını da otomatikleştirin; ikisi birlikte kapsamı tamamlar.

İlgili rehberler

• Mobil uygulama seçimi: PWA mı, native mi? Kurumsal saha ve maliyet rehberi
• En iyi yazılım şirketleri 2026: Türkiye'deki kurumsal yazılım firmaları sıralaması
• ERP şartnamesi ve ihtiyaç analizi şablonu 2026: Başarısızlığı önleyen 16 maddelik RFP rehberi

Hizmet sayfası: Kurumsal yazılım hizmeti