Gabungkan atau Pisahkan Instans Zendesk® Tanpa Melewatkan Balasan
Migrasi Zendesk® ke Zendesk®

Gabungkan atau Pisahkan Instans Zendesk® Tanpa Melewatkan Balasan

Pindahkan Zendesk® ke Zendesk® tanpa kehilangan data, waktu henti, atau gangguan operasional. Baik Anda melakukan konsolidasi setelah akuisisi atau memisahkan lingkungan berdasarkan merek, wilayah, atau kebutuhan kepatuhan, pendekatan migrasi data ini dirancang untuk menjaga agar agen tetap bekerja dan pelanggan tetap menerima balasan.

Pesan konsultasi →

Tidak diperlukan kartu kredit Pengaturan cepat

Dipercaya oleh lebih dari 40.000 perusahaan

Universitas Teknologi Arkansas Kosmos Layar TRG Thule Megah Megah Webpros Otomatis Braxtech Lenovo
Universitas Teknologi Arkansas Kosmos Layar TRG Thule Megah Megah Webpros Otomatis Braxtech Lenovo

Mengapa menggabungkan atau memisahkan instance Zendesk®

Organisasi menggabungkan akun Zendesk® setelah merger dan akuisisi, konsolidasi internal, atau ketika mengurangi biaya operasional pemeliharaan beberapa sistem.

Tim memilih untuk menggabungkan instance Zendesk® ketika:

Anda mengakuisisi perusahaan lain dan perlu menggabungkan akun Zendesk® agar agen dapat melihat dan membalas dengan konteks riwayat lengkap yang tetap terjaga.

Setelah konsolidasi instance Zendesk® , tim memerlukan visibilitas bersama dan dasbor pelaporan terpadu di seluruh fungsi dukungan.

Penggunaan beberapa instance Zendesk® menyebabkan duplikasi alur kerja, otomatisasi yang berlebihan, dan kesenjangan dalam akurasi pelaporan.

Dengan memilih untuk menggabungkan instance Zendesk® , tim dapat menghilangkan alur kerja duplikat, mengurangi penyebaran otomatisasi, dan memusatkan manajemen SLA sambil mempertahankan data historis dan meminimalkan gangguan.

Memisahkan instance Zendesk® menjadi penting ketika merek, wilayah, atau kewajiban kepatuhan memerlukan kemandirian.

Tim memisahkan instance Zendesk® ketika:

Alur kerja atau SLA saling bertentangan antar departemen atau wilayah geografis.

Tim membutuhkan otonomi operasional untuk memenuhi persyaratan peraturan atau kepatuhan setempat.

Pelaporan atau branding terpisah diperlukan untuk pengalaman dukungan yang berhadapan langsung dengan pelanggan.

Pendekatan migrasi Zendesk® yang terkontrol ini mengurangi konflik alur kerja, tiket yang salah arah, dan kesalahan pelaporan, sekaligus memberikan kebebasan yang dibutuhkan oleh departemen atau merek.

Mengapa Migrasi Zendesk® ke Zendesk® Terasa Berisiko (dan Bagaimana Kami Menghilangkan Risiko Tersebut)

Migrasi Zendesk® ke Zendesk® terasa berisiko jika dilakukan tanpa visibilitas atau validasi.

Risiko: Kehilangan data penting

Bayangkan saja tiket, lampiran, catatan pribadi, rekaman panggilan, atau konteks historis hilang, itu sudah cukup membuat tim ragu-ragu. Satu klik yang salah bisa terasa tidak dapat diubah.

Begini cara Help Desk Migration menanganinya:

Layanan migrasi data kami memastikan setiap tiket, lampiran, dan percakapan dimigrasikan dengan akurat. Migrasi demo memungkinkan Anda melihat data asli Anda dipindahkan dengan aman sebelum melakukan komitmen. Tidak ada yang tertinggal, tidak ada yang rusak.

Risiko: Waktu henti dan gangguan dukungan

Agen Anda tetap bekerja, dan pelanggan Anda tetap membalas. Gangguan dukungan tidak dapat diterima selama konsolidasi instance Zendesk® .

Begini cara Help Desk Migration menanganinya:

Semua migrasi data Zendesk® berjalan di latar belakang sementara Zendesk® tetap aktif. Selama migrasi Delta, Anda dapat memigrasikan aktivitas baru, sehingga dukungan tidak pernah berhenti, dan SLA tetap terjaga.

Risiko: Alur kerja yang terganggu, tiket yang salah arah, dan pemetaan yang tidak tepat

Merek, formulir, penerima tugas, atau status yang salah dapat menghambat tim dan menimbulkan kebingungan, miskomunikasi, dan kesalahan pelaporan selama konsolidasi instance Zendesk® .

Begini cara Help Desk Migration menanganinya:

Migration Wizard membantu Anda memetakan tiket, pengguna, kolom kustom, makro, dan pemicu dengan tepat. Kasus-kasus khusus seperti tiket yang digabungkan, tindak lanjut, atau pengguna yang ditangguhkan ditangani secara otomatis. Anda memvalidasi setiap langkah pemetaan, mengurangi risiko hingga nol.

Risiko: Biaya, kesinambungan pelaporan, dan konteks historis

Memigrasikan terlalu banyak data dapat meningkatkan biaya. Laporan Explore tidak dimigrasikan secara default. Lampiran, tangkapan layar, atau catatan mungkin terlewatkan.

Begini cara Help Desk Migration menanganinya:

Layanan migrasi data kami memungkinkan Anda untuk memfilter tiket dan data, menjaga integritas pelaporan, dan menangkap setiap detail historis yang relevan. Anda tetap memegang kendali atas ruang lingkup dan biaya.

Apa yang dulunya terasa berisiko menjadi dapat diprediksi, aman, dan dapat dibatalkan. Agen tetap bekerja, pelanggan tetap mendapatkan balasan, dan manajemen mendapatkan keyakinan bahwa peralihan Zendesk® ke Zendesk® akan berhasil.

Dengan Demo Help Desk Migration , Anda tidak perlu menebak-nebak, tetapi dapat melihat cara kerjanya sebelum hal itu menjadi masalah.

Tidak diperlukan kartu kredit Pengaturan cepat

Cara Kerja Migrasi Zendesk® ke Zendesk®

Persiapan · Pemetaan · Pengujian · Peluncuran · Validasi

Mempersiapkan

Transfer Zendesk® Zendesk® yang sukses dimulai dengan persiapan yang detail:

  • Pilih instance Zendesk® target (gabungkan atau pisahkan) berdasarkan kebutuhan bisnis.
  • Selaraskan merek, formulir, grup, dan SLA agar sesuai dengan arsitektur yang Anda inginkan.
  • Konfirmasikan akses tingkat admin ke instance Zendesk® sumber dan target.
  • Tentukan cakupan migrasi: seluruh riwayat atau hanya tiket terbaru dan yang masih terbuka.
  • Inventarisasi semua kolom kustom, makro, pemicu, dan otomatisasi, termasuk dependensi.
  • Identifikasi tiket yang diarsipkan, tiket yang digabungkan, pengguna yang ditangguhkan, dan kasus-kasus khusus yang mungkin memerlukan penanganan khusus.

Peta

Pemetaan mendefinisikan secara tepat bagaimana data berperilaku setelah migrasi:

  • Tiket: status, merek, formulir, penerima pengalihan.
  • Pengguna dan organisasi: deduplikasi, asosiasi multi-perusahaan, penanganan pengguna yang ditangguhkan.
  • Kolom kustom: normalisasi dropdown, perilaku tag, dan penanganan kolom multi-formulir.
  • Aturan: makro dimigrasikan sepenuhnya; otomatisasi dinonaktifkan selama migrasi dan diaktifkan kembali secara manual.

Tes

Pengujian memastikan keakuratan dan membangun kepercayaan:

  • Migrasikan 20 tiket nyata termasuk kasus-kasus khusus seperti tiket multi-merek, pengguna yang digabungkan, dan tindak lanjut.
  • Periksa percakapan, lampiran, kolom kustom, dan status untuk memastikan konsistensi.
  • Perbaiki pemetaan berdasarkan hasil dan jalankan kembali migrasi Demo jika diperlukan.
Mulai Demo Gratis

Peluncuran

Migrasi penuh berjalan sementara Zendesk® sumber Anda tetap aktif:

  • Migrasi delta membantu memindahkan balasan baru dan pembaruan agen selama proses peralihan.
  • Para agen melanjutkan alur kerja mereka, dan pelanggan terus menerima dukungan.
  • Proses migrasi berjalan di latar belakang untuk menjaga kesinambungan operasional sepenuhnya.

Mengesahkan

Ini adalah proses migrasi data layanan pelanggan yang terkontrol, bukan pertaruhan swalayan:

  • Lakukan rekonsiliasi antara jumlah tiket dan pengguna untuk memastikan semua data telah dimigrasikan dengan benar.
  • Buat ulang laporan Explore, karena data pelaporan tidak dimigrasikan secara default.
  • Aktifkan kembali otomatisasi secara sengaja untuk mencegah pemicu yang tidak terduga.
  • Arsipkan instance sumber untuk keperluan kepatuhan atau pencatatan.
  • Ini adalah proses migrasi data layanan pelanggan yang terkontrol, bukan pertaruhan swalayan.
Platform yang Didukung
Pemetaan Data
Migrasi Demo Gratis
Migrasi Penuh
Tinjau hasilnya

Masalah Umum Migrasi Zendesk® ke Zendesk® yang Kami Tangani

Masalah 1: Merek yang tidak aktif atau merek default menyebabkan kesalahan perutean

Masalah:

Merek yang tidak aktif pada instance sumber mungkin akan beralih ke merek yang dipilih pada instance target, yang berpotensi mencampur tiket antar merek.

Larutan:

Layanan Help Desk Migration menyaring dan memetakan merek yang tidak aktif sesuai dengan kebutuhan Anda, memastikan tiket masuk ke merek yang tepat tanpa kebingungan.

Masalah 2: Kolom dropdown menghasilkan tag yang tidak perlu

Masalah:

Kolom dropdown di berbagai formulir tiket dapat membuat tag yang tidak diinginkan setelah migrasi.

Larutan:

Sesuaikan pemetaan untuk menghapus kolom yang tidak relevan dan secara opsional menonaktifkan penandaan otomatis konten, mengurangi kebisingan tag sambil mempertahankan data penting.

Masalah 3: Tiket yang diarsipkan tidak muncul di tampilan

Masalah:

Tiket yang diarsipkan masih ada dalam sistem tetapi tidak muncul di tampilan default, sehingga menimbulkan kekhawatiran bahwa "tiket telah hilang."

Larutan:

Semua tiket yang diarsipkan disertakan dalam migrasi data, dan kami akan memandu Anda dalam memverifikasinya melalui pencarian ID atau wildcard.

Masalah 4: Perbedaan antara tiket yang sudah diselesaikan dan yang sudah ditutup

Masalah:

Tiket yang sudah terselesaikan mungkin akan ditutup secara otomatis setelah 28 hari, yang akan memengaruhi pelacakan status.

Larutan:

Kami memperhitungkan perilaku otomatisasi Zendesk® dan Anda dapat memetakan status tiket sehingga catatan historis tetap akurat, sementara Anda mengontrol otomatisasi di masa mendatang.

Masalah 5: Perbedaan zona waktu / konversi UTC

Masalah:

API menggunakan UTC; stempel waktu tiket mungkin tampak bergeser satu jam setelah migrasi.

Larutan:

Layanan kami menangani normalisasi zona waktu dan menyediakan verifikasi pasca-migrasi untuk memastikan stempel waktu sesuai dengan pengaturan lokal tim Anda.

Edisi 6: Keterbatasan agen cahaya

Masalah:

Agen Light tidak dapat memiliki tiket yang sudah ditutup atau memposting komentar publik, sehingga membatasi bagaimana tiket muncul dalam penugasan.

Larutan:

Kami memetakan terlebih dahulu tiket dan komentar agen yang ringan ke agen yang sesuai, sehingga menghindari kesenjangan dalam akuntabilitas.

Masalah 7: Pembatasan IP atau kesalahan koneksi

Masalah:

Alat migrasi dapat gagal jika instance Zendesk® sumber atau target membatasi IP tertentu.

Larutan:

Kami memandu pembuatan daftar putih IP dan konfigurasi yang aman untuk mencegah kegagalan.

Masalah 8: Ketidaksesuaian indeks pencarian Zendesk®

Masalah:

Jumlah tiket yang ditampilkan berdasarkan pencarian mungkin tidak sesuai dengan jumlah tiket sebenarnya.

Larutan:

Help Desk Migration Wizard memvalidasi jumlah melalui data API, dan kami dapat membantu dengan pengindeksan ulang jika diperlukan.

Edisi 9: Status tiket khusus

Masalah:

Hanya status kustom atau default yang dapat dipetakan sekaligus.

Larutan:

Kami memandu klien dalam menonaktifkan status khusus dan menghubungkan kembali akun, memastikan pemetaan status tiket yang benar

Kisah Sukses Migrasi Zendesk® ke Zendesk®

UrbanYou berhasil menyelamatkan lebih dari 200.000 tiket setelah konsolidasi akun

Industri:

Layanan Rumah Tangga

Masalah:

UrbanYou perlu mentransfer lebih dari 200.000 tiket, kontak, lampiran, catatan, dan konten basis pengetahuan (KB) historis dari akun Zendesk® lama ke akun baru setelah diakuisisi, tetapi alat bawaan Zendesk®tidak menyimpan detail yang cukup.

Bagaimana kami menyelesaikannya:

UrbanYou melakukan migrasi Demo gratis untuk memverifikasi integritas tiket, kemudian menjalankan migrasi otomatis penuh dengan dukungan ahli yang memandu setiap langkahnya.

Hasil:

Seluruh konteks dukungan historis, termasuk tiket, lampiran, dan catatan, dimigrasikan dengan lancar, memberikan agen akses langsung ke riwayat pelanggan tanpa gangguan.

“Memindahkan data Zendesk® kami dengan Help Desk Migration merupakan pengalaman yang benar-benar lancar.”

Noga Edelstein
Salah satu pendiri UrbanYou

Noga Edelstein

Roland Corporation telah melakukan konsolidasi instance yang kompleks untuk platform dukungan global

Industri:

Elektronik & Alat Musik

Masalah:

Roland perlu mengkonsolidasikan data layanan pelanggan dari instance Zendesk® regional ke instance global pusat untuk menyatukan operasi dukungan, sebuah tugas yang melibatkan tiket, kontak, perusahaan, agen, dan grup.

Bagaimana kami menyelesaikannya:

Help Desk Migration menerapkan kombinasi proses migrasi otomatis dan yang disesuaikan, dengan cermat memetakan entitas utama dan mempertahankan struktur alur kerja di seluruh akun.

Hasil:

Konsolidasi Zendesk® ke Zendesk® yang canggih telah berhasil diselesaikan, dengan semua data penting tetap terjaga dan dukungan berkelanjutan.

"Jujur saja, saya sangat terkejut dengan betapa responsifnya perusahaan ini. Saya sampai bertanya-tanya, apakah kalian bahkan tidur? Saya bisa mendapatkan jawaban untuk hampir setiap pertanyaan yang saya ajukan dalam beberapa jam, bahkan dengan mempertimbangkan perbedaan zona waktu."

Paul McCabe,
Wakil Presiden Pengalaman Pelanggan Global di perusahaan Roland.

Paul McCabe

Ozonics LLC melakukan migrasi semalaman ke Zendesk® yang berfungsi

Industri:

Produk Luar Ruangan / Konsumen

Masalah:

Ozonics LLC membutuhkan cara yang cepat dan andal untuk memigrasikan pengaturan dukungan pelanggan mereka yang sudah ada ke Zendesk® dan membuatnya beroperasi penuh pada hari kerja berikutnya.

Bagaimana kami menyelesaikannya:

Tim Help Desk Migration memandu mereka melalui demo dan migrasi penuh, memungkinkan Ozonics untuk melakukan pra-konfigurasi Zendesk® dan menjalankan transfer dalam semalam.

Hasil:

Pada pagi harinya, Zendesk® berfungsi penuh dengan semua data historis, menghilangkan waktu henti dan entri ulang manual.

"Proses migrasi berjalan sesuai rencana, kami tidak menemukan masalah apa pun pada data yang ditransfer."

Stacey Hippen,
Direktur Operasi di Ozonics LLC

Stacey Hippen
Diskusi Tim tentang Migrasi

Migrasi Pusat Bantuan (Basis Pengetahuan)

Help Desk Migration mentransfer artikel, terjemahan, hierarki, lampiran, dan metadata antar Pusat Bantuan Zendesk® dengan tetap memperhatikan keterbatasan platform. Ikuti panduan di bawah ini untuk memastikan migrasi yang lengkap dan tanpa kesalahan.

Migrasi akan gagal jika pengguna API tidak memiliki izin yang diperlukan:
  • Peran Admin Panduan diperlukan untuk semua konten Pusat Bantuan.
  • Akses ke semua merek yang sedang dimigrasikan.
  • Izin untuk mengelola bahasa dan lokal.
  • Akses untuk melihat artikel yang diarsipkan atau draf jika perlu dimigrasikan.

  • Setiap merek harus dimigrasikan secara terpisah menggunakan URL mereknya masing-masing.
  • Migrasi multi-merek didukung tetapi dilacak secara individual.
  • Jika artikel di merek yang berbeda memiliki slug atau ID yang sama, maka namanya akan diubah selama migrasi untuk mencegah konflik.

Aturan untuk mencegah kesalahan migrasi:
  • Bahasa default harus sama antara sumber dan target.
  • Hanya pemetaan lokal satu-ke-satu. Beberapa lokal sumber tidak dapat dipetakan ke satu lokal target.
  • Locale yang dihapus di sumber mungkin masih ada di API; migrasi locale ini akan gagal.
  • Nama lokal UI Zendesk® mungkin berbeda dari kode API (misalnya, fr-fr → Prancis, fr → Prancis (Prancis)). Verifikasi di Knowledge Admin → Pengaturan → Pengaturan Bahasa.
  • Artikel tanpa bahasa default akan dilewati kecuali jika ditetapkan secara manual atau melalui pengaturan migrasi.
  • Lokasi tertentu dapat dilewati jika tidak diperlukan.

  • Draf dan artikel yang diterbitkan: Migrasi melestarikan negara. Draf tetap berupa draf; artikel yang diterbitkan tetap diterbitkan.
  • Artikel yang diarsipkan: Tidak dapat dimigrasikan. Pulihkan sebagai draf atau yang diterbitkan terlebih dahulu.
  • Folder & bagian: Artikel tanpa folder dipindahkan ke folder default. Batasan bagian/kategori dan kedalaman penestingan maksimum dipertahankan tetapi harus diperiksa untuk menghindari kegagalan tanpa pemberitahuan.
  • Pengurutan dan artikel yang disematkan: Urutan dipertahankan jika memungkinkan; posisi khusus mungkin memerlukan penyesuaian setelah migrasi.

  • Gambar, file, tag, dan format dimigrasikan apa adanya.
  • Video yang disematkan memerlukan pengaktifan konten tidak aman di Zendesk®.
  • Tautan di dalam artikel akan diperbarui jika Pembaruan Tautan Silang diaktifkan; jika tidak, pengalihan harus dikonfigurasi secara manual.

  • Label dan tag tetap dipertahankan.
  • Kolom artikel kustom mungkin perlu dipetakan; kolom yang tidak didukung akan dilewati.
  • Pencantuman penulis: Penulis asli akan dipertahankan jika pengguna tersebut ada di target; jika tidak, migrasi akan menetapkan pengguna API.
  • Tanggal pembuatan dan pembaruan artikel dipertahankan sebisa mungkin.

  • Pembaruan Tautan Silang mempertahankan tautan internal.
  • Pengalihan diperlukan jika tautan silang dinonaktifkan.
  • Nama slug akan diubah secara otomatis jika terdapat duplikat di Pusat Bantuan target.

  • Migrasi bersifat idempoten jika artikel yang sama dimigrasikan lagi: artikel yang diperbarui akan menimpa versi sebelumnya.
  • Artikel yang dihapus atau terjemahan yang dihilangkan di sumber tidak secara otomatis dihapus dari target.
  • Berikan daftar artikel untuk migrasi selektif. Jika kurang dari 20, ini dapat dilakukan dalam demo menggunakan Demo dengan Data Kustom.

  • Artikel yang diarsipkan (kembalikan ke draf atau yang sudah diterbitkan).
  • Data medan saluran.
  • Tiket spam (tab Ditangguhkan).
  • Beberapa kolom kustom tidak didukung.

  • Konten yang baru dimigrasikan mungkin membutuhkan waktu untuk muncul di hasil pencarian.
  • Penundaan pengindeksan adalah hal normal dan harus diantisipasi setelah migrasi.
Apa yang tidak dapat dimigrasikan?
  • Artikel yang diarsipkan: Bahkan artikel kustom pun tidak dapat dimigrasikan. Untuk menyertakannya, Anda harus terlebih dahulu memulihkannya sebagai draf atau artikel yang telah diterbitkan.
  • Data kolom saluran: Zendesk® tidak mengizinkan migrasi ke kolom saluran, sehingga informasi ini tidak dapat dipindahkan ke kolom default.
  • Tiket spam: Tiket di tab Ditangguhkan tidak dimigrasikan.
Basis pengetahuan Anda terstruktur sepenuhnya, dapat dicari, dan mempertahankan integritas historis tanpa tim Anda harus menangani ribuan artikel secara manual.
Alternatif Banner Help Desk Migration

Jangan menebak-nebak. Validasi migrasi Zendesk® ke Zendesk® Anda tanpa waktu henti

Zendesk® ke Zendesk® :
Detail Teknis yang Penting

Ya. Semua tiket akan dimigrasikan, termasuk tiket dari merek yang tidak aktif. Anda dapat mengontrol merek dan formulir tiket mana yang disertakan, sehingga tiket akan sampai di merek atau departemen yang tepat.

Tiket yang digabungkan dimigrasikan sebagai catatan individual, dengan tetap mempertahankan konteks historis yang lengkap. Tindak lanjut dapat dikonsolidasikan ke dalam tiket utama atau dicatat dalam bidang khusus, berdasarkan persyaratan alur kerja Anda.

Tiket yang belum ditugaskan secara otomatis ditugaskan kepada agen default. Hal ini memastikan tidak ada tiket yang terlantar dan alur kerja berlanjut tanpa gangguan.

Kolom pilihan (dropdown) dari beberapa formulir tiket diubah menjadi tag. Kami meminimalkan pembuatan tag yang tidak perlu sambil tetap mempertahankan semua data penting. Penandaan otomatis dapat dinonaktifkan jika diinginkan.

Ya. Rekaman panggilan disimpan sebagai lampiran MP3, sementara semua gambar, video, dan file yang disisipkan di dalamnya bermigrasi secara utuh dan dapat digunakan di instance tujuan.

Semua makro, pemicu, dan kondisinya dimigrasikan. Karena melewatkan tindakan dapat menyebabkan pemicu gagal, kami memverifikasi semuanya sebelum peralihan. Anda dapat memfilter berdasarkan status aktif atau tidak aktif, kategori, atau grup sesuai kebutuhan.

Catatan pribadi yang dibuat oleh non-agen, pemohon, atau penerima CC akan dialihkan ke agen default. Konteks aslinya tetap terjaga, sehingga tidak ada yang hilang.

Hindari kejutan, kehilangan data, dan waktu henti. Setiap tiket, pengguna, makro, dan artikel basis pengetahuan bermigrasi dengan andal. Migrasi demo memungkinkan Anda melihat pratinjau hasilnya, kasus-kasus khusus ditangani secara otomatis, dan alur kerja tetap berjalan tanpa gangguan.

Ya. Setiap tag yang diterapkan pada pengguna atau organisasi akan secara otomatis ditambahkan ke tiket baru yang dibuat untuk mereka.

Peran default meliputi Pengguna Akhir, Agen, dan Administrator. Dengan paket Enterprise, Anda dapat membuat peran khusus yang sesuai dengan kebutuhan tim Anda.

Ini biasanya berarti pengguna yang menjalankan migrasi tidak memiliki izin untuk mengakses help_center/user_segments. Untuk memperbaikinya, berikan peran Help Center Manager kepada pengguna tersebut.

Artikel Basis Pengetahuan hanya dapat disimpan dalam folder, bukan kategori. Jika sebuah artikel tidak termasuk dalam folder pada sistem sumber, artikel tersebut akan dimigrasikan ke folder default yang dibuat oleh alat migrasi.

Otomatisasi berjalan berdasarkan peristiwa berbasis waktu, sementara pemicu berjalan sebagai respons terhadap pembuatan atau pembaruan tiket.

Ya. Tiket bermigrasi dari semua merek, termasuk yang dinonaktifkan. Kolom Merek muncul pada pemetaan. Jika suatu merek tidak aktif, merek tersebut tidak muncul pada pemetaan. Tiket dari merek tersebut akan bermigrasi ke merek default yang dipilih oleh klien. Jika klien ingin memigrasi hanya merek tertentu dan bukan semuanya, diperlukan pemfilteran. Pada Zendesk®target, tiket dapat dimigrasi ke merek tertentu dengan memilihnya di pemetaan tiket (kolom Merek ditampilkan pada pemetaan).

Formulir tiket adalah templat yang menentukan kolom mana yang muncul pada tiket, membedakan tiket berdasarkan departemen atau jenis permintaan.
  • Pemetaan formulir: Formulir tiket dapat dipetakan antara sumber dan target.
  • Kolom dropdown: Nilai dari dropdown pada formulir lain secara otomatis ditambahkan sebagai tag oleh Zendesk®. Perilaku ini tidak dapat dicegah.
  • Pemetaan khusus: Kolom yang tidak diperlukan dapat dikecualikan untuk mengurangi tag.
  • Menonaktifkan tag: Zendesk® dapat menonaktifkan penandaan otomatis; tag otomatis berbasis konten (Panduan) juga dapat dinonaktifkan, tetapi tag bidang dropdown tetap ada kecuali dihapus dari pemetaan.

Tiket yang digabungkan: Migrasi sebagai tiket terpisah. Pesan pribadi yang menunjukkan penggabungan akan dimigrasikan sebagai pesan pribadi. Tindak lanjut: Migrasi sebagai satu tiket. Tindak lanjut dengan ID secara opsional dapat dimigrasikan ke catatan pribadi atau bidang khusus.

Ya, tiket yang diarsipkan akan dipindahkan secara otomatis. Di Zendesk®, tiket yang diarsipkan adalah tiket dengan status Tertutup selama 90 hari.

Tiket yang belum ditugaskan di Zendesk® target akan ditugaskan ke agen default.
  • Tiket hanya dapat tetap berstatus Baru jika belum ditugaskan.
  • Saat tiket baru ditugaskan ke agen default, Zendesk® secara otomatis mengubah statusnya menjadi Terbuka.
  • Oleh karena itu, status Baru dikecualikan dari pemetaan migrasi ke Zendesk®.

Zendesk® memungkinkan Anda membuat status tiket khusus di luar status default (Baru, Terbuka, Tertunda, Ditangguhkan, Terselesaikan, Ditutup).
  • Pemetaan: Hanya status default atau status kustom yang akan ditampilkan untuk pemetaan, tidak pernah keduanya secara bersamaan.
  • Beralih ke status default: Untuk memetakan status default, nonaktifkan status khusus di akun Anda dan sambungkan kembali.
  • Perilaku tiket: Tiket dengan status khusus diperlakukan sebagai tiket tertutup—tiket tersebut mempertahankan semua karakteristik tiket tertutup (tidak dapat diedit, tetap berada dalam kategori Tertutup) meskipun ada otomatisasi, tetapi nama statusnya tidak berubah.

Ya. Organisasi dapat dikecualikan jika diinginkan, sebaiknya tanpa memberi tahu pengguna terlebih dahulu.

Ya. Tag kontak (pengguna dan organisasi) dimigrasikan secara default. Semua tag yang terkait dengan pengguna atau organisasi di Zendesk® sumber ditransfer ke instance target dan tetap tersedia untuk alur kerja, pemicu, dan pelaporan.

Di Zendesk®, sebuah tiket tidak dapat dimiliki oleh perusahaan yang berbeda dari perusahaan pemohon. Jika tiket sumber memiliki perusahaan yang berbeda dari kontak (atau tidak memiliki perusahaan kontak), dimungkinkan untuk melakukan migrasi kustom beberapa perusahaan dari tiket ke kontak dan mencerminkan perusahaan yang benar di tiket tersebut.

Pengguna yang ditangguhkan diekstraksi dan dimigrasikan sebagai pengguna yang tidak ditangguhkan, karena tiket tidak dapat dibuat oleh pengguna yang ditangguhkan. Jika pengguna ada di target sebagai pengguna yang ditangguhkan, kami akan mencabut penangguhan dan memetakannya.

Zendesk® Segmen pengguna hanya dapat dimigrasikan melalui pemetaan tag khusus untuk pengguna dan organisasi. Klien harus membuat segmen pengguna pada target untuk kontak yang dimigrasikan sebelum atau setelah migrasi. Saat memigrasikan artikel, segmen pengguna sumber dan target ditampilkan untuk pemetaan, tetapi hanya berfungsi jika dikonfigurasi dengan benar pada target.

Jika seorang agen termasuk dalam Grup A di sumber dan Grup B di Zendesk®, agen tersebut akan ditugaskan ke grup yang terhubung dengan tiket, sesuai dengan pemetaan.

Ya, tiket dapat difilter berdasarkan penerima (email dukungan) hanya jika domainnya adalah Zendesk®.

Pemicu akan berjalan secara otomatis ketika kondisinya terpenuhi. Selama migrasi:
  • Pemetaan otomatis: Semua pemicu dimigrasikan.
  • Detail yang dapat ditinjau: Setiap kondisi dan tindakan ditampilkan untuk verifikasi.
  • Penting: Jika ada tindakan yang dilewati, pemicu akan gagal setelah migrasi.

Selama migrasi, makro ditransfer beserta semua komponen intinya dan harus dipetakan sepenuhnya agar berfungsi dengan benar di Zendesk®target:
  • Tersedia untuk — menentukan peran mana yang dapat menggunakan makro tersebut.
  • Judul — nama makro tersebut.
  • Isi — konten atau instruksi yang diterapkan oleh makro.
  • Aksi — semua aksi makro dipetakan secara eksplisit. Jika ada aksi yang dilewati atau tidak dipetakan, makro akan gagal setelah migrasi.
Semua aksi makro, kondisi, dan ketergantungan sepenuhnya terlihat selama tahap pemetaan, memungkinkan Anda untuk memvalidasi dan menyesuaikannya sebelum ditayangkan.

Ya. Anda dapat memfilter berdasarkan:
  • Makro: status aktif/tidak aktif, kategori, atau grup. Secara default, semua makro akan dimigrasikan.
  • Pemicu: status aktif/tidak aktif atau kategori. Secara default, semua pemicu dimigrasikan.
Elvira Azymova
PENGARANG

Elvira Azymova

Kepala Penjualan

Elvira adalah pakar migrasi help desk yang terkemuka dan pemimpin yang dihormati untuk tim Penjualan dan Dukungan kami. Dengan pengalaman lebih dari 4 tahun dan rekam jejak lebih dari 2000 migrasi yang sukses, ia ahli dalam merancang migrasi data perusahaan berisiko tinggi sambil berfokus pada integritas data total dan kesinambungan operasional.

Migrasi Zendesk ke Jira Service Management Menjadi Mudah

Migrasikan catatan pelanggan Anda dari Zendesk ke Jira Service Management hanya dalam beberapa klik. Solusi kami menangani migrasi sehingga Anda dapat fokus pada hal yang penting—menyelesaikan permintaan pelanggan Anda.

Jelajahi panduan migrasi data yang lebih bermanfaat

Mencari informasi lebih lanjut? Sumber daya terbaru kami menawarkan panduan berharga tentang peningkatan layanan pelanggan dan penanganan migrasi data help desk. Lihat sekarang juga!

Perangkat Lunak Live Chat Terbaik yang Dapat Dibeli dengan Uang

Tak peduli berapa usia Anda, atau jenis konten apa yang Anda konsumsi, ...

6 Sistem Help Desk Terbaik untuk Shopify

Bisakah Anda mengingat kapan terakhir kali Anda menerima layanan pelanggan yang luar biasa? Bisakah Anda...

Spiceworks Desktop vs Spiceworks Cloud: Apa Perbedaannya?

Salah satu versi help desk Spiceworks akan ditutup pada tanggal 31 Desember. ...

Zendesk adalah merek dagang terdaftar dari Zendesk, Inc. Help Desk Migration tidak berafiliasi dengan, disponsori oleh, atau didukung oleh Zendesk, Inc. Kami menyediakan layanan migrasi data yang kompatibel dengan platform Zendesk.