Pengelolaan kartu nama fisik hasil pameran kerap menyulitkan tim penjualan ketika harus dimasukkan ke dalam sistem CRM secara manual. Untuk memangkas waktu, seorang pengembang di Jepang merancang fitur yang mengunggah berkas PDF atau gambar berisi tumpukan kartu nama, lalu mendaftarkannya secara otomatis ke basis data perusahaan.
Proses yang awalnya dianggap mudah dengan sekadar mengandalkan OCR (Optical Character Recognition) ternyata menyimpan jebakan teknis yang signifikan. Tantangan terbesar muncul ketika sebuah halaman pindaian memuat lebih dari satu kartu nama, sebuah skenario umum saat menggunakan mesin fotokopi atau scanner datar.
Ide dasar di balik fitur ini cukup sederhana: pengguna mengunggah file, server melakukan validasi format serta ukuran, lalu sistem mencatat riwayat "proses penyerapan" dan langsung memberi respons. Pemrosesan berat seperti OCR hingga penyisipan data dilakukan di latar belakang agar tidak memicu batas waktu permintaan (timeout), mengingat tahapan tersebut bisa memakan waktu dari puluhan detik hingga beberapa menit.
Pembagian peran antara penerimaan ("reception") dan tubuh pemrosesan ("processing body") menjadi kunci arsitektur. API penerimaan hanya bertugas menyimpan file ke penyimpanan awan dan memulai tugas latar belakang, sementara antarmuka depan melakukan polling pada ID riwayat untuk menampilkan progres.
Lebih jauh, pengembang menyadari bahwa OCR tidaklah sepenuhnya "pintar" dalam memahami struktur. Pembacaan karakter dibagi menjadi dua tahap: ekstraksi teks mentah beserta koordinatnya menggunakan layanan seperti Google Cloud Vision, dan tahap strukturisasi yang memilah teks tersebut ke dalam kolom perusahaan, nama, atau email melalui model ekstraksi internal. Tanpa pemisahan ini, sistem akan menghasilkan data yang tidak beraturan.
Di Indonesia, adopsi CRM di kalangan perusahaan rintisan (startup) dan korporasi terus meningkat, seiring dengan budaya pertukaran kartu nama yang masih kuat di Asia Tenggara. Beberapa penyedia lokal mulai menyematkan fitur pemindaian otomatis pada ekosistem digital mereka. Namun, banyak pengembang lokal kerap terjebak pada asumsi bahwa layanan OCR komersial sudah menyelesaikan semua masalah pembacaan dokumen.
Kasus satu halaman berisi banyak kartu ini memberikan pelajaran berharga bagi engineer Tanah Air. OCR generik hanya mengembalikan teks dan posisi koordinatnya; ia tidak memiliki fitur bawaan untuk memisahkan beberapa dokumen dalam satu bingkai. Jika kartu nama bersebelahan terlalu dekat, algoritma berbasis kedekatan tata letak milik OCR justru akan menggabungkan atau memecah blok teks secara keliru.
Dampaknya fatal bagi integritas data. Apabila teks dari kartu Perusahaan A dan kontak Personil B bercampur, model strukturisasi yang mengasumsikan input hanya untuk satu kartu akan menciptakan catatan palsu. Hal ini berisiko merusak basis data pelanggan yang seharusnya menjadi aset strategis bisnis di Indonesia.
Sang pengembang menekankan perlunya logika pemisahan mandiri (custom logic) sebelum data masuk ke tahap strukturisasi. "OCR hanya memberikan seluruh karakter dan koordinatnya. Kita harus menyisipkan proses memotong per kartu nama secara manual, baik dengan aturan geometri sederhana maupun model kecerdasan buatan," jelasnya dalam catatan teknisnya.
Ia juga menyoroti pentingnya validasi berbasis konten, bukan sekadar ekstensi file. "Memeriksa magic byte di awal file jauh lebih aman daripada mengandalkan penamaan .pdf, karena pengguna bisa saja mengubah ekstensi gambar menjadi PDF," tambahnya. Untuk berkas besar, ia menyarankan penggunaan aliran data (streaming) langsung ke penyimpanan awan tanpa membebani memori server.
Ke depan, pengembang menyarankan agar tim produk membatasi fleksibilitas input sejak awal, misalnya dengan mewajibkan pengguna memindai kartu nama dalam jarak yang seragam. Pendekatan berbasis aturan geometri, seperti mendeteksi celah koordinat X dan Y untuk membagi baris dan kolom, memang ringan, namun rapuh terhadap kemiringan atau ukuran kartu yang tidak seragam.
Ironisnya, setelah berhari-hari memikirkan cara memecah tata letak acak, tim produk akhirnya mengonfirmasi bahwa spesifikasi dasar mereka hanya mengasumsikan satu kartu per halaman PDF. Insiden ini menjadi pengingat bagi para engineer untuk selalu mempertanyakan kebutuhan (requirements) sebelum menghabiskan energi membangun solusi teknis yang berlebihan.