Bayangkan ini: Ini hari Jumat sore. Organisasi Anda sedang mempersiapkan migrasi platform dukungan skala besar selama akhir pekan. Pada Senin pagi, tim Anda membutuhkan akses ke riwayat tiket, data pelanggan, dan alur kerja selama bertahun-tahun — tanpa waktu henti atau kehilangan konteks.
Dalam situasi seperti ini, prioritas migrasi menjadi sangat penting. Tidak semua data perlu dipindahkan dengan urutan yang sama, dan memperlakukan semua data secara sama dapat memperlambat transisi. Tim dukungan seringkali membutuhkan akses langsung ke tiket aktif, percakapan terbaru, pelanggan prioritas, atau grup tertentu terlebih dahulu — sementara data historis dapat terus bermigrasi di latar belakang. Tanpa strategi dan prioritas migrasi yang jelas, tim mungkin akan mendapati diri mereka berurusan dengan data yang tidak lengkap, notifikasi duplikat, atau tekanan operasional yang tidak perlu selama proses peluncuran.
Migrasi help desk ekspres menggunakan pendekatan yang lebih cerdas: logika dua tahap. Kami memastikan tim Anda siap dan beroperasi terlebih dahulu, kemudian memindahkan data historis Anda secara diam-diam di latar belakang. Ini bukan tentang meninggalkan data, tetapi tentang migrasi dengan urutan yang tepat.
1. Apa yang Membuat Migrasi Ekspres Berbeda dari Migrasi Standar?
Migrasi standar mencoba memindahkan semuanya dalam satu proses besar: tiket terbuka, catatan tertutup, lampiran besar, dan log sistem. Untuk kumpulan data yang besar, proses tunggal tersebut dengan mudah memakan waktu lebih dari satu malam.
Hal ini menciptakan periode ketidakpastian selama beberapa hari. Agen terpaksa menangani dua sistem sekaligus; tidak ada yang tahu platform mana yang menyimpan sumber data yang sebenarnya, dan kesalahan data terus bertambah setiap jamnya.
Migrasi help desk ekspres menghilangkan masalah ini. Dengan menarik garis yang jelas antara dua proses yang ditargetkan, migrasi help desk tanpa downtime menjaga antrian dukungan Anda tetap berjalan. Tidak ada pemadaman berhari-hari. Tidak ada agen yang terlantar.
- Langkah 1: Transfer bersih dari kumpulan data minimum yang dibutuhkan tim Anda untuk mendukung pelanggan langsung sejak hari pertama. Ini termasuk tiket terbuka, tiket tertunda, kontak, perusahaan, dan basis pengetahuan aktif Anda. Karena kumpulan data ini hanya sebagian kecil dari total arsip Anda, prosesnya dapat diselesaikan dengan mudah dalam semalam.
- Langkah 2: Arsip historis. Semua hal lainnya, yaitu arsip tiket yang sudah ditutup, akan ditransfer secara bertahap dan terencana setelah tim Anda siap dan beroperasi di platform baru. Tidak perlu terburu-buru, tidak ada kepanikan di akhir pekan, dan tidak ada gangguan pada dukungan harian Anda.
Tim Anda menyelesaikan peralihan platform dengan lancar tepat waktu. Proses historis yang berat berjalan dengan aman di latar belakang.
1.1plainLogika Dua-Jalan
Anggap Langkah 1 sebagai kelas master dalam "lazy loading." Alih-alih membuat pengguna menunggu hingga setiap aset footer yang berat, skrip pelacakan, dan gambar latar belakang dimuat, Anda merender konten penting di bagian atas halaman sehingga mereka dapat mulai berinteraksi dengan halaman tersebut segera.
Pada Senin pagi, agen Anda hanya membutuhkan hal-hal penting yang tercantum di bagian atas halaman: percakapan aktif, profil pelanggan terkini, dan dokumentasi teknis untuk menyelesaikan tiket. Mereka tidak memerlukan tiket yang sudah diselesaikan dari tiga musim panas lalu untuk memenuhi SLA hari pertama mereka.
Langkah 2 adalah pemuatan latar belakang asinkron. Langkah ini mengisi sisa arsip historis sesuai keinginan Anda, jauh setelah proses peralihan yang berisiko tinggi selesai. Kedua langkah ini memiliki tujuan yang sama persis: transfer data yang lengkap. Pendekatan migrasi bertahap ini memastikan tim Anda tetap memegang kendali penuh atas jadwal operasional.
1.2 Apa yang BUKAN Express Migration
Mari kita perjelas: migrasi ekspres bukan tentang memangkas proses atau mengurangi arsip Anda secara permanen. Setiap tiket yang ditutup, resolusi sebelumnya, dan file historis dipindahkan dengan aman selama Langkah 2. Seluruh riwayat Anda tiba dalam keadaan utuh. Kami secara strategis mengubah waktu pengiriman.
Kekhawatiran terbesar bagi para pemimpin TI adalah data historis akan terbengkalai. Padahal tidak. Langkah 2 adalah fase rekayasa inti, bukan sekadar tambahan opsional. Bagi tim yang terikat oleh kerangka kepatuhan yang ketat, audit peraturan, atau model keberhasilan pelanggan di mana agen terus-menerus merujuk pada interaksi lama, menyelesaikan Langkah 2 adalah bagian yang tidak dapat dinegosiasikan dari proses kami. Migrasi ekspres adalah strategi pengurutan, bukan penghapusan selektif.
2. Daftar Periksa Pra-Migrasi: Semua yang Perlu Disiapkan Sebelum Pemindahan Data
Setiap tugas di bagian ini harus diselesaikan sebelum Langkah 1 mulai memindahkan data. Melewatkan langkah-langkah ini adalah cara tercepat untuk mengubah peralihan semalam yang direncanakan dengan baik menjadi masalah internal yang besar. Gunakan ini sebagai daftar periksa utama peralihan migrasi helpdesk Anda.
2.1 Menonaktifkan Otomatisasi, Notifikasi, dan Pemicu Aktif pada Platform Target
Ketika data lama masuk ke platform aktif selama proses impor, mesin otomatisasi sistem akan menganggapnya sebagai peristiwa baru. Jika aturan bisnis Anda aktif, aturan tersebut akan dijalankan secara instan.
Hasilnya adalah mimpi buruk pemberitahuan massal: ribuan email usang dan membingungkan dikirimkan kepada pelanggan tentang tiket yang telah diselesaikan berbulan-bulan yang lalu. Lebih buruk lagi, penghitung waktu SLA diatur ulang secara tidak benar pada data historis, dan aturan perutean aktif secara tidak sengaja menarik catatan yang sudah tidak aktif ke dalam antrian live agent sedang bertugas.
Ini adalah langkah yang paling sering dilewati dalam daftar periksa peralihan migrasi helpdesk , dan menyebabkan kerusakan operasional yang paling parah jika terlewatkan.
Sebelum memulai Langkah 1, buka panel admin platform target Anda dan nonaktifkan semua otomatisasi, pemicu notifikasi, dan aturan bisnis aktif:
- Zendesk: Admin > Aturan Bisnis > Pemicu
- Freshdesk: Admin > Alur Kerja > Otomatisasi
- Intercom: Pengaturan > Kotak Masuk > Otomatisasi
2.2 Verifikasi Pembuatan Agen dan Pemetaan Profil Tim pada Target difront
Kegagalan untuk mengatur pencocokan agen difront menyebabkan tiket menjadi yatim piatu. Catatan masuk ke platform baru tanpa pemilik yang valid, dan secara otomatis dialihkan ke pengguna sistem yang tidak dipantau. Dalam lingkungan dukungan langsung, tiket yatim piatu secara langsung menyebabkan percakapan yang terlewatkan dan tingkat layanan yang menurun.
Sebelum menjalankan Langkah 1, verifikasi bahwa setiap profil agen aktif dan historis ada di platform target. Kemudian, buka pemetaan di Panduan Migrasi untuk menghubungkan identitas sumber dan target Anda. Cara paling mudah untuk memastikan kecocokan otomatis adalah dengan menggunakan alamat email yang identik di kedua platform. Jika konvensi email berbeda, petakan pengguna tersebut secara manual sebelum data mulai mengalir.
3. Langkah 1. Buka Tiket Semalaman
Tujuan: Memastikan tim Anda dapat mulai bekerja di platform target pada pagi hari berikutnya.
Langkah 1 adalah bagian yang paling sensitif terhadap waktu dalam proses ini. Setiap keputusan tentang apa yang harus disertakan dan dikecualikan bermuara pada satu pertanyaan: Apakah tim membutuhkan ini untuk mulai bekerja pada hari Senin?
3.1 Apa yang Harus Disertakan pada Langkah 1
Batasi transfer awal Anda hanya pada apa yang dibutuhkan agen Anda untuk mengelola antrean aktif dan memindahkan tiket terbuka ke lingkungan helpdesk baru dengan lancar:
- Tiket terbuka dan tertunda: Ini mewakili beban kerja operasional Anda saat ini dan tumpukan tiket aktif Anda. Semua hal lainnya menunggu Langkah 2.
- Kontak dan perusahaan terkait: Konteks adalah segalanya. Mengimpor tiket tanpa profil pelanggan yang sesuai akan merusak alur percakapan dan memperlambat agen Anda.
- Artikel basis pengetahuan dalam semua versi bahasa: Basis pengetahuan Anda adalah alat operasional yang vital. Agen memerlukan akses instan ke dokumentasi internal, dan pusat bantuan layanan mandiri harus tetap aktif bagi pelanggan sejak saat peralihan.
3.2 Apa yang Harus Dikecualikan dari Langkah 1
- Riwayat tiket yang ditutup dan diselesaikan: Ini sepenuhnya termasuk dalam Langkah 2. Memindahkan catatan ini ke proses awal Anda akan menambah volume data yang sangat besar, yang secara berbahaya akan memperbesar jendela waktu semalam Anda untuk aset yang tidak akan disentuh siapa pun pada Senin pagi.
- Lampiran arsip: Lampiran menambah ukuran file yang sama sekali tidak sebanding dengan nilai operasionalnya selama proses peralihan. Tunda lampiran ke Langkah 2. (Lampiran yang terkait dengan tiket aktif dan terbuka dapat disertakan jika waktu pemrosesan semalaman memungkinkan.)
- Riwayat aktivitas agen: Jejak audit internal historis, riwayat kinerja dengan arsip tiket yang ditutup, harus tetap ada dan dipindahkan bersama arsip historis.
Menjaga agar Langkah 1 tetap ramping adalah kunci untuk mencapai target waktu peluncuran semalaman. Setiap megabyte yang Anda kurangi dari proses awal adalah jaminan untuk peluncuran Anda pada Senin pagi.
3.3 Menggunakan Migrasi Multithreaded untuk Mencapai Jendela Cutover Anda
Batasan API platform target adalah batas kecepatan absolut dari setiap migrasi digital. Mesin migrasi standar dengan satu thread memproses permintaan secara berurutan. Hal ini menyisakan banyak potensi kecepatan yang tidak dimanfaatkan, karena berjalan jauh lebih lambat daripada kemampuan platform baru sebenarnya.
Menjalankan migrasi helpdesk multithreaded mengubah perhitungannya. Dengan menjalankan beberapa thread permintaan secara bersamaan, proses impor dipaksa hingga batas maksimal kapasitas API platform target Anda.
Sebagai contoh, kumpulan data 50.000 tiket yang membutuhkan waktu 8 jam untuk ditransfer pada satu thread dapat diselesaikan dalam 3 hingga 4 jam melalui transfer multithread. Penghematan waktu tersebut seringkali menjadi perbedaan antara penerapan yang sukses dan membiarkan agen lini frontAnda tanpa sistem yang aktif pada awal shift.
Anda mendapatkan multithreading secara otomatis dengan Paket Layanan Unggulan kami, dan kami sangat merekomendasikannya untuk Langkah 1. Ingatlah bahwa batasan API sangat bervariasi tergantung pada vendor dan paket Anda. Paket Freshdesk Growth memiliki batasan yang jauh lebih ketat daripada akun Enterprise, dan Zendesk meningkatkan kecepatannya secara ketat berdasarkan tingkatan. Tidak yakin apakah pengaturan Anda dapat menangani jendela semalaman? Periksa dengan tim teknik kami sebelum menetapkan tanggal peralihan dalam jadwal Anda.
3.4 Menjalankan Langkah 1: Dari Peluncuran Hari Jumat hingga Mengaktifkan Perangkat
Jalankan wizard migrasi pada Jumat malam. Pantau throughput data melalui dasbor langsung dan jangan tutup tab browser (pembaruan dikirim secara otomatis). Jangan buang waktu untuk menyegarkan halaman secara manual; notifikasi otomatis akan masuk ke kotak masuk Anda begitu proses selesai.
Begitu Langkah 1 selesai, langsung lanjutkan ke langkah-langkah transisi:
- Segera alihkan semua saluran komunikasi ke platform target. Aktifkan penerusan email Anda, ganti widget obrolan langsung di situs web Anda, dan arahkan tautan pusat bantuan Anda ke platform baru. Ini akan menghentikan semua lalu lintas pelanggan baru agar tidak mengakses sistem lama Anda.
- Atur platform sumber menjadi hanya baca. Hapus izin pengeditan tim Anda atau tambahkan banner hanya baca. Help desk lama sekarang hanya menjadi sumber hanya baca, bukan ruang kerja aktif.
Ini mempersiapkan tim Anda dengan sempurna untuk Senin pagi. Agen Anda masuk dan bekerja menggunakan platform baru, tetapi sistem lama tidak dapat menerima atau menghasilkan percakapan baru.
3.5 Apa yang Terjadi Jika Langkah 1 Tidak Selesai pada Pagi Hari
Jika tiket baru masuk atau percakapan yang ada diperbarui selama jendela migrasi, Migrasi Delta bertindak sebagai lapisan sinkronisasi bawaan. Secara otomatis mentransfer catatan yang baru dibuat dan yang baru saja diperbarui setelah proses migrasi awal.
Migrasi Delta memeriksa help desk lama Anda untuk setiap aktivitas baru setelah Langkah 1 dimulai dan menyinkronkannya ke ruang kerja baru Anda. Karena sinkronisasi Delta menangkap tiket yang tersisa ini secara diam-diam di latar belakang, agen Anda dapat mulai bekerja segera pada Senin pagi tanpa kehilangan data apa pun.
Anda perlu menjalankan Migrasi Delta dalam waktu 10 hari setelah menyelesaikan fase migrasi awal, dan ini termasuk dalam paket Signature kami. Banyak tim juga tetap menyediakan platform sebelumnya dalam mode baca saja selama periode transisi, memberikan akses kepada agen ke data referensi historis sementara ruang kerja baru sepenuhnya stabil.
4. Peluncuran Hari Pertama: Langkah-Langkah Pengalihan Akhir
Ini adalah alur kerja resmi hari peluncuran. Ikuti langkah-langkah ini dengan tepat sebelum tim mulai bekerja pada Senin pagi.
4.1 Alihkan Semua Saluran Komunikasi ke Platform Target
Pindahkan lalu lintas pelanggan Anda ke sistem baru. Arahkan penerusan email dukungan Anda ke kotak masuk baru, perbarui kode obrolan langsung situs web Anda, dan teruskan URL pusat bantuan Anda. Pengalihan saluran ini tidak terlihat; pelanggan Anda tidak akan menyadari apa pun karena semua titik kontak mereka yang biasa tetap sama. Lakukan ini sebelum agen masuk untuk shift pertama mereka.
4.2 Atur Platform Sumber menjadi Hanya Baca
Kunci sistem lama dan terapkan status hanya baca, agar agen tidak secara tidak sengaja menggunakannya. Cabut izin pengeditan mereka atau tambahkan spanduk yang jelas yang mengarahkan mereka ke meja kerja baru. Jika seorang agen memperbarui tiket di sumber hanya baca karena kebiasaan, hal itu akan menciptakan kekacauan data besar yang merusak tujuan migrasi semalam.
Tim Anda masih dapat masuk untuk melihat konteks percakapan lama, tetapi sistem lama ditutup untuk pekerjaan baru sejak peralihan sistem.
4.3 Jalankan Migrasi Delta untuk Menangkap Pembaruan Tiket yang Terlewatkan
Meskipun Langkah 1 berjalan lancar, Anda tetap perlu mengambil tiket apa pun yang berpindah tangan saat sinkronisasi sedang berjalan. Mulailah migrasi Delta sebagai bagian dari proses peralihan tepat sebelum tim Anda masuk. Perhatikan bahwa fitur ini tersedia pada paket Signature dan harus dimulai dalam waktu 10 hari setelah penyelesaian untuk memastikan ruang kerja baru Anda selalu mutakhir.
4.4 Adakan Briefing Tim Selama 10 Menit Sebelum Shift Pertama Dimulai
Lewati sesi pelatihan yang bertele-tele di hari peluncuran. Fokuslah pada taktik. Di hari peluncuran, tim Anda perlu mendukung pelanggan, bukan duduk mendengarkan presentasi slide.
Bahaslah tepat empat hal:
- Kredensial login baru.
- Di mana menemukan tiket yang masih tersedia.
- Cara kerja pencarian dan riwayat.
- Siapa yang harus dihubungi jika ada sesuatu yang tampak hilang.
Jika Anda sudah pernah menggunakan sandbox atau menjalankan migrasi Demo, agen Anda akan familiar dengan antarmuka tersebut. Pertemuan singkat ini hanyalah pengecekan keselarasan cepat, bukan tutorial fitur.
5. Langkah 2: Memindahkan Tiket yang Sudah Ditutup dalam Bagian-bagian Latar Belakang
Tujuan: Memindahkan seluruh arsip historis Anda tanpa mengganggu operasional yang sedang berjalan.
Agen Anda sudah menjalankan antrean mereka, jadi pengawasan waktu yang ketat pada Langkah 1 sudah berakhir. Langkah 2 tidak memiliki batasan waktu yang ketat. Satu-satunya fokus sekarang adalah eksekusi latar belakang yang menghindari:
- Mempengaruhi kinerja live agent atau kecepatan ruang kerja.
- Melebihi kuota API Anda selama jam kerja standar.
5.1 Mengapa Riwayat Tiket yang Ditutup Masih Penting
Jangan salah mengira tiket yang sudah ditutup sebagai data yang tidak berguna. Tiket tersebut sangat penting karena tiga alasan utama setelah peluncuran sistem:
- Audit Kepatuhan dan Regulasi: Tergantung pada industri Anda, Anda mungkin diwajibkan secara hukum untuk menyimpan percakapan pelanggan selama bertahun-tahun. Langkah 2 memastikan penyimpanan data Anda sepenuhnya sesuai dengan peraturan.
- Konteks Agen: Pelanggan seringkali mengungkit masalah-masalah sebelumnya. Ketika seorang agen membuka tiket baru dan melihat riwayat yang kosong, mereka seperti bekerja tanpa arah. Menyimpan riwayat tiket yang sudah ditutup akan membantu menyimpan solusi, catatan, dan preferensi sebelumnya.
- Kontinuitas Pelaporan: Untuk melacak tren jangka panjang, volume musiman, atau skor CSAT historis, Anda memerlukan semua data Anda di satu tempat. Data yang terfragmentasi berarti metrik yang berantakan dan tidak akurat.
5.2 Mengatur Tahapan Arsip Anda: Cara Membagi Rentang Tanggal Anda
Gunakan filter tanggal untuk memecah arsip historis Anda yang besar menjadi bagian-bagian yang lebih kecil dan mudah dikelola. Strategi paling cerdas adalah bergerak mundur melalui waktu. Mulailah dengan memigrasikan data terbaru terlebih dahulu, karena inilah yang kemungkinan besar dicari oleh agen aktif Anda.
Peta Jalan Migrasi Bertahap
| Fase | Cakupan | Waktu/Metode | Status |
| Langkah 1. Hari Peluncuran | Tiket terbuka dan yang sedang diproses + Basis Pengetahuan dimigrasikan melalui sinkronisasi semalaman | Sinkronisasi semalaman | Hidup |
| Langkah 2. Arsip Sejarah | Tiket lama yang sudah ditutup dan riwayat jangka panjang | Pemuatan latar belakang | Sedang berlangsung |
Atur setiap batch sebagai pekerjaan migrasi terpisah di dalam Migration Wizard. Membagi data Anda seperti ini akan meminimalkan beban sistem. Jika API vendor mengalami gangguan di tengah transfer, hal itu hanya akan memengaruhi satu bagian data yang terisolasi tersebut, sehingga Anda tidak perlu memuat ulang seluruh databaseAnda.
5.3 Menggunakan Migrasi Interval untuk Menjeda Selama Jam Kerja
Dengan menggunakan logika tiket dukungan migrasi interval, Anda dapat menghentikan sementara transfer data selama jam kerja puncak dan secara otomatis melanjutkannya di malam hari atau selama akhir pekan.
Alih-alih menjalankan sinkronisasi data besar-besaran yang menghabiskan kuota API Anda dan memperlambat ruang kerja aktif Anda, setiap jeda interval membagi pekerjaan menjadi jendela-jendela cerdas.
Ini membuat Langkah 2 tidak terlihat oleh tim Anda:
- Tidak ada perlambatan agen: Tim dukungan Anda tidak akan mengalami lag atau penundaan antarmuka selama jam sibuk.
- Gedung latar belakang yang sunyi: Arsip sejarah terisi penuh sementara semua orang sedang offline.
- Penjadwalan otomatis: Anda tidak perlu menghentikan dan memulai alat secara manual; alat ini akan mengatur waktunya untuk Anda.
Bagi tim perusahaan dengan volume tiket yang tinggi dan SLA yang ketat, migrasi interval mengubah beban data yang berat menjadi proses latar belakang yang tenang.
5.4 Berapa Lama Waktu yang Dibutuhkan untuk Langkah 2?
Berbeda dengan Tahap 1 yang memiliki tenggat waktu tetap, Tahap 2 tidak memiliki batas waktu yang pasti.
Beberapa perusahaan menyelesaikan transfer data historis mereka hanya dalam dua malam. Yang lain memilih pendekatan yang lebih konservatif, menyebarkan pekerjaan selama dua hingga tiga minggu dengan menjalankan batch latar belakang hanya pada akhir pekan.
Pada akhirnya, kecepatan migrasi ideal Anda bergantung pada tiga hal:
- Volume rekaman total Anda.
- Batasan API platform target Anda.
- seberapa besar bandwidth yang sebenarnya Anda miliki untuk memantau pekerjaan tersebut.
Tips ahli: Jika arsip Anda melebihi 200.000 catatan, atau jika tim Anda terikat oleh tenggat waktu kepatuhan yang ketat, Anda tidak perlu melakukannya sendiri. Tim Layanan Profesional kami dapat sepenuhnya merencanakan, membagi, dan mengeksekusi sinkronisasi historis Anda dari awal hingga akhir.
6. Catatan Waktu Spesifik Platform
Meskipun panduan untuk Langkah 2 selalu sama, jadwal sinkronisasi latar belakang Anda yang sebenarnya bergantung pada pasangan platform yang Anda gunakan.
Setiap help desk memiliki batasan laju API, aturan pembatasan, dan struktur data sendiri. Misalnya, migrasi dari Zendesk ke Freshdesk memerlukan strategi pengaturan kecepatan yang berbeda dibandingkan dengan Intercom ke Zendesk migrasi dari Freshdesk ke Intercom atau dari .
Prinsip yang sama berlaku untuk proyek-proyek seperti Zendesk ke Intercom migrasi Intercom ke Freshdesk skala besar Zendesk konsolidasi Zendesk sinkronisasiberbeda, yang dapat memengaruhi waktu dan perencanaan migrasi.
Pada saat yang sama, sebagian besar platform help desk modern menawarkan paket perusahaan atau add-on API dengan kapasitas throughput yang lebih besar, memungkinkan migrasi besar berjalan jauh lebih cepat bila diperlukan. Itulah mengapa migrasi yang sukses bukan hanya tentang keterbatasan teknis yang sulit, tetapi lebih tentang perencanaan yang cerdas, prioritas, dan memilih strategi migrasi yang tepat untuk jangka waktu operasional Anda.
Berikut adalah gambaran singkat tentang apa yang dapat Anda harapkan dari setiap ekosistem sehingga Anda dapat merencanakan proses fermentasi latar belakang tanpa kejutan.
6.1 Migrasi Zendesk Express
Zendesk membatasi kecepatan ekstraksi dan impor berdasarkan batasan laju API yang ketat. Tergantung pada tingkatan kontrak Anda, Anda dapat mengharapkan antara 400 hingga 700 permintaan per menit. helpdesk sepenuhnya memaksimalkan throughput ini.
Namun, Anda harus menyesuaikan konfigurasi terlebih dahulu untuk menghindari pengulangan email otomatis yang berlebihan. Sebelum menjalankan Langkah 1, masuk ke Zendesk, navigasi ke Admin > Aturan Bisnis > Pemicu, dan matikan semua pemicu yang aktif. Anda juga harus memeriksa pengaturan aktif di bawah Aturan Bisnis > Otomatisasi.
Membiarkan satu notifikasi pun tetap aktif memungkinkan platform untuk mengirimkan pembaruan yang tidak disengaja kepada pelanggan lama, yang merusak metadata historis Anda selama proses migrasi.
Pada saat yang sama, migrasi juga merupakan kesempatan untuk membersihkan kolom-kolom yang sudah usang atau tidak perlu. Tidak semua kolom lama perlu dipindahkan, dan banyak tim sengaja meninggalkan kolom kustom yang tidak digunakan untuk menghindari kekacauan di ruang kerja baru.
6.2 Migrasi Freshdesk Express
Freshdesk menyesuaikan kecepatan penyerapan dan impor berdasarkan batasan laju API yang ketat. Tergantung pada tingkatan kontrak Anda, Anda dapat mengharapkan sekitar 40 permintaan per menit pada paket tingkat rendah hingga sekitar 1.000 pada paket Enterprise. Jika tim Anda beroperasi pada paket Growth, throughput yang lebih rendah ini sangat membatasi proses standar yang berjalan semalaman.
Kelola blok data aktif Anda dengan hati-hati untuk menghindari penguncian integrasi di seluruh akun. Menggunakan migrasi interval memungkinkan Anda untuk menghentikan sementara transfer latar belakang selama jam sibuk siang hari dan melanjutkannya secara otomatis saat lalu lintas menurun. Pilihan operasional ini mencegah beban data yang berat memperlambat ruang kerja Anda atau menyebabkan waktu habis sistem bagi agen dukungan langsung.
6.3 Migrasi Intercom Express
Intercom mengatur kecepatan impor menggunakan kerangka kuota harian yang unik, bukan batasan per menit. Tergantung pada tingkatan kontrak Anda, ruang kerja menerima anggaran panggilan API tetap yang diatur ulang pada tengah malam UTC.
Pastikan Anda frontkonten Basis Pengetahuan (KB) langsung di Langkah 1. Memindahkan artikel lebih awal memastikan live agentdan fitur Fin AI memiliki database berkualitas tinggi yang siap untuk penyelesaian masalah pada hari pertama. Untuk bentuk data lama yang mengancam anggaran harian Anda, verifikasi kuota yang tersisa di Intercom Developer Hub Anda sebelum menetapkan tanggal peluncuran.
7. Pertanyaan Umum tentang Migrasi Ekspres: Mengelola Urutan Migrasi Dua Langkah
Berapa lama waktu yang dibutuhkan untuk Express Migration Langkah 1?
Untuk tim dukungan dengan kurang dari 50.000 tiket terbuka dan tertunda, Langkah 1 umumnya selesai dalam semalam dalam jangka waktu 4 hingga 8 jam. Kecepatan pasti Anda bergantung pada volume catatan mentah, batasan laju API platform tertentu, dan multithreading. Menjalankan demo uji cepat adalah cara termudah untuk mengukur jangka waktu pasti pasangan platform Anda.
Apakah pelanggan saya akan tahu bahwa kami telah beralih platform?
Tidak, jika Anda mengarahkan saluran email, widget obrolan, dan URL portal pelanggan Anda ke sistem baru sebelum agen masuk. Jalur komunikasi utama Anda tetap sama; hanya perangkat lunak backend yang mengelolanya yang berubah. Jika dilakukan dengan benar, peralihan platform tidak akan terlihat oleh pengguna akhir.
Apa yang terjadi pada tiket yang dibuat selama Langkah 1?
Migrasi Delta menangkap setiap tiket yang dibuat atau diperbarui di platform lama Anda setelah Langkah 1 dimulai, memindahkannya dengan aman ke target baru. Jaring pengaman ini menutup celah data apa pun selama masa transisi. Ingatlah untuk meluncurkan sinkronisasi Delta dalam waktu 10 hari setelah menyelesaikan Langkah 1. Opsi ini tersedia dalam paket Signature.
Apakah saya perlu menonaktifkan otomatisasi sebelum migrasi?
Ya. Melewatkan langkah ini adalah kesalahan yang sangat mahal dalam migrasi Express. Membiarkan pemicu atau alur kerja otomatis tetap aktif di sistem baru Anda selama impor menyebabkan platform mengirimkan ribuan notifikasi lama ke kontak pelanggan lama. Hal ini juga secara permanen mengubah penghitung waktu pelacakan SLA di seluruh arsip historis Anda.
Kapan saya harus menggunakan layanan profesional daripada layanan mandiri?
Kami merekomendasikan layanan profesional untuk migrasi kompleks yang melibatkan lebih dari 200.000 data, tenggat waktu peralihan SLA yang ketat, atau pemetaan bidang kustom yang rumit. Jika Anda mengkonsolidasikan beberapa platform sumber menjadi satu, tim teknik kami dapat merencanakan, memetakan, dan menjalankan seluruh rangkaian proses dengan aman atas nama Anda.
8. Pengaturan yang Direkomendasikan untuk Migrasi Ekspres
Jika tim dukungan Anda bekerja dengan databaseyang bersih (artinya kurang dari 50.000 tiket aktif yang terbuka), dan Anda memiliki akhir pekan yang sibuk, wizard layanan mandiri kami dapat dengan mudah menangani beban tersebut. Anda hanya perlu mengatur Langkah 1 di dasbor Anda, centang daftar pra-migrasi Anda, dan tekan luncurkan.
Namun, ketika databasesangat besar atau penuh dengan data lama yang berantakan, segalanya menjadi rumit. Jika Anda ingin tim Anda dapat masuk tanpa hambatan pada Senin pagi, keberhasilan Anda sepenuhnya bergantung pada bagaimana Anda memanfaatkan dua fitur rekayasa inti:
- Migrasi Multithreaded: Protokol ini memaksa API platform target hingga batas performanya untuk memperpendek jangka waktu Langkah 1 Anda. Tersedia dalam Paket Layanan Unggulan kami, ini adalah alat utama Anda untuk memproses kumpulan data besar di hari pertama melalui pipeline.
- Migrasi Interval: Fitur ini menangani transfer arsip historis Langkah 2 Anda yang besar sepenuhnya di luar jam kerja bisnis Anda. Karena secara otomatis menghentikan sementara pemuatan data di siang hari dan melanjutkannya di malam hari, sinkronisasi latar belakang tidak pernah memperlambat frontagen dukungan lini
Jika Anda menghadapi tenggat waktu penghentian kontrak perangkat lunak yang ketat, volume arsip yang sangat besar, atau kombinasi platform yang sangat terbatas, pendekatan swakelola mungkin tidak cukup. Grup layanan profesional kami siap untuk memetakan arsitektur spesifik Anda dan mengelola seluruh proyek migrasi Anda dari awal hingga akhir.
Migrasi Ekspres: Aktif pada Hari Senin, Arsip Sesuai Jadwal Anda
Migrasi ekspres menjembatani kesenjangan antara kecepatan dan keamanan data. Agen dukungan Anda cukup masuk ke platform baru pada Senin pagi dan mulai bekerja, sementara arsip historis Anda diperbarui secara diam-diam di latar belakang dengan kecepatan yang sesuai dengan alur kerja Anda.
Logika intinya tidak berubah berdasarkan vendor help desk Anda. Mendorong data penting hari pertama terlebih dahulu dan kemudian mengalirkan arsip jangka panjang adalah kerangka kerja yang cocok untuk setiap pengaturan perusahaan. Satu-satunya komponen yang benar-benar berubah adalah metrik waktu spesifik Anda:
- Kecepatan Langkah 1 sepenuhnya bergantung pada volume tiket aktif Anda dan batasan API platform.
- waktu Langkah 2 disesuaikan berdasarkan kedalaman arsip total Anda dan jendela sinkronisasi harian.
Hasilnya dapat diprediksi. Anda tidak akan mengalami waktu henti operasional, tidak ada agen yang terjebak menangani dua sistem terpisah, dan tidak ada risiko pengiriman email massal yang tidak disengaja yang mengganggu pelanggan Anda.
Mengelola tumpukan perusahaan yang kompleks berarti melihat lebih dari sekadar peralihan awal di akhir pekan. Lihat Panduan Migrasi Data Lengkap kami untuk mengaudit seluruh arsitektur pipeline data Anda, atau baca Panduan Migrasi Berbasis AI untuk menyiapkan platform baru Anda untuk alat pendukung otomatis.
