WEBVTT

00:00:00.000 --> 00:00:03.940
Seorang pelanggan mengirim email tentang pesanan yang rusak, lalu menelpon keesokan harinya,

00:00:04.100 --> 00:00:06.500
kemudian membuka obrolan karena tidak ada yang tahu apa yang terjadi,

00:00:06.620 --> 00:00:11.080
dan mereka mengulang cerita yang sama setiap saat sementara tim dukungan Anda mencari-cari di kotak masuk catatan dan alat yang terpisah.

00:00:11.360 --> 00:00:14.100
Itulah tepatnya yang diperbaiki oleh manajemen kasus Dynamics 365.

00:00:14.980 --> 00:00:18.480
Anggaplah sebuah kasus seperti satu folder berlabel di dalam gedung kantor yang sibuk,

00:00:18.560 --> 00:00:22.180
di mana setiap bagian dari masalah pelanggan masuk ke dalam folder itu mulai dari pertanyaan pertama hingga Jumlah akhir.

00:00:22.360 --> 00:00:26.060
Anda bersama Mirko Peters dari M365FM, dan dalam segmen pengetahuan ini,

00:00:26.060 --> 00:00:31.220
Anda akan melihat bagaimana kasus, perutean, tengkat waktu respons, artikel dukungan, dan penutupan semuanya saling terkait.

00:00:31.980 --> 00:00:33.600
Apa sebenarnya kasus itu dalam 20 kata?

00:00:34.380 --> 00:00:35.600
Jadi apa sebenarnya kasus itu?

00:00:36.080 --> 00:00:39.680
Kasus adalah satu catatan untuk satu masalah pelanggan yang memerlukan jawaban atau perbaikan,

00:00:39.820 --> 00:00:44.980
dan masalah tersebut bisa berupa produk yang rusak, pertanyaan tagihan, masalah login, atau permintaan bantuan dan menggunakan layanan.

00:00:45.340 --> 00:00:48.420
Inilah intinya, satu pelanggan bisa memiliki beberapa kasus sekaligus.

00:00:49.020 --> 00:00:52.940
Seorang pelanggan mungkin bertanya tentang faktur pada hari Senin, melaporkan perangkat yang rusak pada hari Selasa,

00:00:53.100 --> 00:00:54.500
dan memerlukan bantuan untuk mengubah alamat.

00:00:54.500 --> 00:01:01.520
Itu adalah masalah yang terpisah, jadi Dynamics 365 menyimpannya dalam catatan kasus yang terpisah alih-alih menempuk setiap percakapan ke dalam satu utas yang membingungkan.

00:01:02.220 --> 00:01:04.580
Saat agen membuat kasus, mereka langsung menautkannya ke pelanggan.

00:01:05.220 --> 00:01:09.940
Pelanggan tersebut bisa berupa kontak yang berarti orang perseorangan, atau akun yang berarti perusahaan tempat mereka bekerja.

00:01:10.580 --> 00:01:15.580
Jadi jika Jamie dari Northwind Traders melaporkan masalah, kasus tersebut dapat merujuk pada Jamie dan perusahaannya,

00:01:15.720 --> 00:01:19.960
dan siapa punya buka catatan tersebut dapat melihat siapa yang memerlukan bantuan dan organisasi mana masalah tersebut beras.

00:01:19.960 --> 00:01:24.860
Kasus tersebut juga memerlukan deskripsi masalah yang jelas, biasanya dimulai dengan judul seperti

00:01:24.860 --> 00:01:27.220
Printer kami berhenti setelah pembaruan perangkat lunak atau

00:01:27.220 --> 00:01:29.780
Pelanggan kami ditagih dua kali untuk paket tahunan,

00:01:30.180 --> 00:01:34.560
dan judul tersebut membantu orang memindai daftar kasus terbuka tanpa harus membuka setiap catatan.

00:01:35.620 --> 00:01:37.480
Di bawah judul tersebut, agen menambahkan detailnya.

00:01:37.740 --> 00:01:38.200
Apa yang terjadi?

00:01:38.540 --> 00:01:40.420
Apa yang sudah dicoba oleh pelanggan?

00:01:40.960 --> 00:01:41.700
Produk mana yang terlibat?

00:01:41.700 --> 00:01:44.400
Dan apakah itu sebuah pertanyaan, permintaan, atau kesalahan?

00:01:44.900 --> 00:01:48.400
Detail ini mengubah pesan yang samar menjadi pekerjaan yang dapat dimiliki dan diselesaikan oleh seseorang.

00:01:48.840 --> 00:01:49.940
Mari kita bedah lebih jauh.

00:01:50.600 --> 00:01:53.280
Sebuah kasus dapat menguat subjek, produk, prioritas, dan jenis kasus.

00:01:53.840 --> 00:01:57.220
Subjek mengelompokkan masalah ke dalam bidang seperti penagihan atau dukungan teknis,

00:01:57.500 --> 00:01:59.440
produk mengidentifikasi apa yang digunakan pelanggan,

00:01:59.940 --> 00:02:02.240
prioritas memberi tahu tim seberapa cepat harus menanganinya,

00:02:02.740 --> 00:02:06.240
dan jenis kasus memberi tim cara lain untuk menyaktifkan pekerjaan berdasarkan proses dukungan mereka.

00:02:07.060 --> 00:02:10.260
Tidak satu pun dari kolom ini menyelesaikan masalah pelanggan dengan sendirinya,

00:02:10.260 --> 00:02:13.000
tetapi semuanya membantu tim dukungan melihat pekerjaan dengan jelas,

00:02:13.360 --> 00:02:15.680
terutama ketika ratusan kasus datang dari pelanggan yang berbeda.

00:02:16.240 --> 00:02:19.440
Sebuah tim yang menangani kegagalan layanan serius seharusnya tidak perlu mencari

00:02:19.440 --> 00:02:21.040
melalui pertanyaan umum untuk menemukannya.

00:02:21.440 --> 00:02:24.340
Jadi, sebuah kasus bukan sekadar formulir yang diisi lalu dilupakan begitu saja.

00:02:25.040 --> 00:02:27.320
Kasus tersebut menjadi catatan kerja untuk keseluruhan pencakapan.

00:02:27.720 --> 00:02:28.920
Email dapat terhubung ke kasus,

00:02:29.360 --> 00:02:30.720
panggilan telepon dapat muncul di sana,

00:02:30.900 --> 00:02:32.860
dan agen dapat menambahkan catatan setelah berolah,

00:02:32.980 --> 00:02:34.040
menetapkan tugas tindak lanjut,

00:02:34.200 --> 00:02:35.040
atau mencatat janji temu.

00:02:35.040 --> 00:02:38.540
Setiap aktivitas tetap bersama masalah pelanggan yang sama,

00:02:38.720 --> 00:02:41.560
sehingga orang berikutnya tidak perlu menyusun ulang ceritanya dari awal.

00:02:42.280 --> 00:02:44.140
Bayangkan seorang agen mulai bekerja di pagi hari,

00:02:44.260 --> 00:02:46.780
lalu menyerahkan kasus tersebut kepada spesialis produk setelah makan siang.

00:02:47.440 --> 00:02:48.420
Tanpa catatan kasus,

00:02:48.600 --> 00:02:50.440
spesialis mungkin hanya menerima pesan singkat seperti,

00:02:50.540 --> 00:02:51.500
oh, bisakah Anda melihat ini?

00:02:52.500 --> 00:02:53.040
Yang tidak cukup.

00:02:54.280 --> 00:02:55.260
Dengan catatan kasus,

00:02:55.400 --> 00:02:57.260
mereka dapat melihat masalah awal, detail pelanggan,

00:02:57.380 --> 00:02:58.460
apa yang terjadi selama panggilan,

00:02:58.560 --> 00:03:00.040
dan apa yang sudah diperiksa oleh agen pertama.

00:03:00.640 --> 00:03:01.820
Hal itu menawarkan proses ratrimack.

00:03:01.820 --> 00:03:06.680
Dynamics 365 menjaga status kasus tetap jelas saat bergerak melalui proses dukungan.

00:03:07.340 --> 00:03:09.780
Kasus dapat tetap aktif sementara tim melakukan investigasi,

00:03:09.940 --> 00:03:12.080
dan setelah tim memperbaiki masalah atau memberikan jawaban akhir,

00:03:12.220 --> 00:03:12.820
mereka menyelesaikan.

00:03:13.600 --> 00:03:15.480
Jika permintaan tidak lagi memerlukan tindakan,

00:03:15.760 --> 00:03:17.460
mungkin karena kesalahan atau pelanggan batalkannya,

00:03:17.580 --> 00:03:19.000
tim dapat membatalkan kasus tersebut.

00:03:19.740 --> 00:03:21.200
Aktif selesai dan dibatalkan.

00:03:22.240 --> 00:03:23.220
Ketiga status tersebut,

00:03:23.520 --> 00:03:26.200
memberikan pandangan bersama kepada tim mengenai posisi setiap masalah,

00:03:26.560 --> 00:03:29.860
sehingga tidak ada yang perlu menebak apakah suatu kasus masih memerlukan perhatian,

00:03:29.860 --> 00:03:32.440
dan manajer tidak perlu memperlakukan pekerjaan lamai

00:03:32.440 --> 00:03:34.800
yang sudah selesai sebagai masalah pelanggan baru.

00:03:35.860 --> 00:03:37.420
Satu catatan memberi Anda kendali,

00:03:37.640 --> 00:03:39.660
dan riwayat pelanggan yang lengkap memberi agen konteks.

00:03:40.920 --> 00:03:42.540
Kisah pelanggan dibalik kasus tersebut.

00:03:43.420 --> 00:03:45.040
Sebuah kasus memberitahu Anda apa yang perlu diperbaik.

00:03:45.260 --> 00:03:47.140
Catatan pelanggan memberitahu Anda apa yang mengarah pada kamu.

00:03:48.100 --> 00:03:50.880
Saat agen membuka kasus di Dynamics 365 Customer Service,

00:03:50.960 --> 00:03:52.940
mereka dapat melihat lebih dari sekadar pesan terbaru.

00:03:53.520 --> 00:03:54.960
Mereka melihat gambaran yang lebih besar,

00:03:55.120 --> 00:03:56.600
seperti kasus sebelumnya, email masa lalu,

00:03:56.720 --> 00:03:57.800
produk yang terhubung ke pelanggan,

00:03:57.800 --> 00:03:58.840
dan riwayat dukungan mereka.

00:03:58.840 --> 00:04:00.620
Nah, konteks mengubah percakapan.

00:04:01.640 --> 00:04:02.520
Mengapa konteks itu penting?

00:04:02.980 --> 00:04:04.840
Bayangkan seorang pelanggan melaporkan kegagalan perangkat.

00:04:05.440 --> 00:04:06.920
Jika agen hanya melihat pesan hari ini,

00:04:07.280 --> 00:04:08.840
mereka mungkin memulai dengan pertanyaan dasar.

00:04:09.580 --> 00:04:09.980
Oda, apa ini?

00:04:10.420 --> 00:04:11.080
Kapan masa ini mulai?

00:04:11.300 --> 00:04:12.240
Sudah karena menyalahkan orang perangkat?

00:04:12.680 --> 00:04:15.220
Namun pelanggan tersebut sudah menghubungi dukungan dua kali minggu ini.

00:04:15.660 --> 00:04:17.460
Agen pertama mengirimkan langkah pemecahan masalah,

00:04:17.540 --> 00:04:18.860
yang kedua mengatur suku cadang pengganti.

00:04:19.240 --> 00:04:20.800
Agen ketiga yang melihat riwayat tersebut

00:04:20.800 --> 00:04:22.600
tidak akan meminta pelanggan untuk mengulang dari awal.

00:04:22.880 --> 00:04:23.880
Sebaliknya, mereka berkata,

00:04:23.880 --> 00:04:25.520
saya lihat Anda sudah mencoba langkah-langkah itu,

00:04:28.840 --> 00:04:31.520
itu terasa sangat berbeda dari bisakah Anda menjelaskan masalahnya lagi.

00:04:32.240 --> 00:04:34.520
Ini sering disebut sebagai tampilan pelanggan 360 rukit.

00:04:35.260 --> 00:04:36.540
Namanya terdengar canggih, padahal sederhana.

00:04:36.920 --> 00:04:39.340
Artinya, agen melihat pelanggan dari lebih dari satu sudut pandang,

00:04:39.460 --> 00:04:40.780
bukan hanya satu pesan terisolasi.

00:04:41.540 --> 00:04:43.440
Agen melihat orangnya, perusahaannya,

00:04:43.660 --> 00:04:44.780
permintaan dukungan sebelumnya,

00:04:44.940 --> 00:04:47.140
pecakapan terdahulu, dan produk yang terhubung dengan mereka.

00:04:47.680 --> 00:04:50.460
Bagi tim dukungan, hal ini menggantikan tebakan dengan titik awal yang jelas.

00:04:51.000 --> 00:04:53.100
Sekarang, tidak setiap pelanggan menerima jenis dukungan yang sama.

00:04:53.360 --> 00:04:55.280
Pelanggan mungkin telah membeli garansi

00:04:55.280 --> 00:04:57.600
perusahaan mereka mungkin membayar sejumlah jam dukungan.

00:04:58.300 --> 00:05:00.360
Atau mereka memiliki kontrak untuk sejumlah kasus

00:05:00.360 --> 00:05:02.760
atau dukungan premium dengan bantuan lebih cepat.

00:05:03.560 --> 00:05:06.060
Dynamics 365 melacak semua ini melalui hak entitlements.

00:05:06.900 --> 00:05:09.040
Hak adalah perjanjian dukungan pelanggan kami.

00:05:09.260 --> 00:05:09.860
Di dalam sistem,

00:05:10.820 --> 00:05:13.020
anggap saja sebagai ketentuan layanan yang melekat pada akun mereka.

00:05:13.780 --> 00:05:15.320
Sebelum agen menjanjikan waktu teknisi

00:05:15.320 --> 00:05:16.480
atau memulai pekerjaan berbayar,

00:05:16.620 --> 00:05:18.120
mereka memeriksa dukungan apa yang berlaku.

00:05:18.740 --> 00:05:20.600
Itu menghindari kejutan yang tidak menyenangkan.

00:05:20.700 --> 00:05:23.780
Sebagai contoh, pelanggan mungkin masih memiliki jaminan untuk produk yang rusak.

00:05:23.780 --> 00:05:25.460
Kasus tersebut bisa mengikuti alurit.

00:05:25.820 --> 00:05:27.920
Pelanggan lain mungkin telah menggunakan seluruh jam dukungan mereka.

00:05:28.560 --> 00:05:30.640
Agen melihatnya sebelum berkomitmen pada pekerjaan jian.

00:05:31.200 --> 00:05:33.260
Ini juga membantu tim dukungan memperlakukan pelanggan DNA.

00:05:33.760 --> 00:05:36.880
Agen tidak perlu mencari melalui kontrak lama atau bertanya ke departemen.

00:05:37.280 --> 00:05:39.580
Ketentuan dukungan tersimpan bersama informasi pelanggan tepat

00:05:39.580 --> 00:05:40.360
ingin dapat menemukannya.

00:05:40.840 --> 00:05:41.720
Kemudian ada basis pengetahuan.

00:05:42.060 --> 00:05:44.040
Tim dukungan menyelesaikan masalah yang sama berulang kali.

00:05:44.640 --> 00:05:45.460
Riset kata Sandi,

00:05:45.680 --> 00:05:46.420
petunjuk pengaturan,

00:05:46.640 --> 00:05:47.780
kesalahan umum setelah pembaruan,

00:05:48.100 --> 00:05:49.800
pertanyaan tagihan dengan jawaban standar,

00:05:49.800 --> 00:05:51.980
artikel pengetahuan menyimpan jawaban tersebut di satu tempat.

00:05:52.520 --> 00:05:53.600
Di dalam ruang kerja layanan,

00:05:53.760 --> 00:05:55.920
agen dapat mencari artikel saat mengerjakan sebuah kasus.

00:05:56.400 --> 00:05:58.300
Artikel mungkin menyertakan penjelasan sederhana,

00:05:58.540 --> 00:05:59.640
langkah-langkah, tangkapan layar,

00:05:59.760 --> 00:06:01.540
atau pemeriksaan tepat yang harus diselesaikan tim.

00:06:02.020 --> 00:06:04.100
Daripada setiap agen menulis versinya sendiri,

00:06:04.260 --> 00:06:04.820
dari ingatan,

00:06:05.000 --> 00:06:07.060
mereka menggunakan jawaban bersama yang telah ditinjau tim.

00:06:07.420 --> 00:06:08.580
Itu menjaga dukungan tetap konsisten.

00:06:08.880 --> 00:06:09.880
Ini juga mendapatkan yang lebih baru.

00:06:10.520 --> 00:06:12.140
Mereka tidak butuh pengalaman bertahun-tahun

00:06:12.140 --> 00:06:13.360
untuk menangani masalah umum,

00:06:13.660 --> 00:06:16.100
dengan baik karena sorusi dari tim sudah tersedia saat dibutuhkan.

00:06:16.100 --> 00:06:18.900
Ringkasan kasus kopilot membantu mengatasi masalah umum lainnya,

00:06:18.980 --> 00:06:19.840
yaitu riwayat kasus yang panjang.

00:06:20.260 --> 00:06:21.820
Sebuah kasus dapat mengumpulkan banyak email,

00:06:21.940 --> 00:06:23.160
catatan, dan pembadanan seiring berjalan.

00:06:23.420 --> 00:06:24.500
Membaca semuanya merupakan waktu,

00:06:24.620 --> 00:06:25.580
terutama setelah adanya pengalaman.

00:06:25.940 --> 00:06:27.560
Kopilot membuat ringkasan kasus singkat

00:06:27.560 --> 00:06:29.180
yang menyatukan judul kasus, pelanggan,

00:06:29.560 --> 00:06:31.300
subjek, produk, prioritas, jenis kasus,

00:06:31.400 --> 00:06:32.920
deskripsi, dan aktivitas terkini.

00:06:33.720 --> 00:06:35.300
Ini adalah ringkasan cepat sebelum agen mulai bekerja.

00:06:35.900 --> 00:06:38.220
Agen tetap meriksa catatan dan menggunakan penjelasan mereka,

00:06:38.540 --> 00:06:40.180
tetapi mereka memahami situasi dengan lebih cepat.

00:06:40.180 --> 00:06:42.300
Hal itu sangat membantu saat pelanggan menunggu

00:06:42.300 --> 00:06:44.000
dan kasus telah berpindah tangan beberapa kali.

00:06:44.800 --> 00:06:46.520
Setelah agen memahami pelanggan dan masalahnya,

00:06:46.620 --> 00:06:48.480
kasus tersebut harus sampai ke orang yang tepat.

00:06:50.840 --> 00:06:52.180
Dari penerimaan hingga kantor yang tepat,

00:06:52.620 --> 00:06:54.640
pelanggan dapat meminta bantuan melalui banyak cara

00:06:54.640 --> 00:06:56.700
seperti email, telepon, oprola, media sosial,

00:06:56.800 --> 00:06:57.700
atau portal layan mendidik.

00:06:58.120 --> 00:07:00.120
Salurannya berubah, tetapi tim dukungan tetap membutuhkan

00:07:00.120 --> 00:07:01.520
satu tempat yang jelas untuk mengeluarkan tersebut.

00:07:02.240 --> 00:07:05.320
Dynamics 365 dapat membuat kasus dari percakapan tersebut

00:07:05.320 --> 00:07:07.460
jika pengaturannya mencakup aturan pembuatan catatan.

00:07:08.140 --> 00:07:10.460
Bayangkan sebuah email yang tiba di alamat dukungan bersama,

00:07:11.220 --> 00:07:12.620
alih-alih membiarkannya di kotak surat

00:07:12.620 --> 00:07:14.160
sampai seseorang melihatnya, sebuah aturan

00:07:14.160 --> 00:07:15.520
mengubah email tersebut menjadi kasus.

00:07:15.920 --> 00:07:17.540
Pesan tersebut menjadi awal pekerjaan

00:07:17.540 --> 00:07:18.440
di dalam layanan pelanggan.

00:07:18.740 --> 00:07:19.920
Hal itu mengurangi penyalian secara manual.

00:07:20.520 --> 00:07:22.760
Gagasan yang sama berlaku untuk saluran terhubung lainnya.

00:07:23.160 --> 00:07:24.860
Tim memilih pesan mana yang membuat kasus baru

00:07:24.860 --> 00:07:26.680
dan mana yang termasuk dalam kasus yang sudah ada.

00:07:27.480 --> 00:07:29.480
Balasan untuk masalah yang terbuka akan tetap bersama-sama.

00:07:29.780 --> 00:07:31.180
Pertanyaan baru akan mendapatkan kasusnya sendiri.

00:07:31.440 --> 00:07:32.760
Kemudian kasus tersebut membutuhkan tempat

00:07:32.760 --> 00:07:33.780
sementara semula mengambil tangan.

00:07:33.940 --> 00:07:34.980
Tempat itu biasanya berupa antrean.

00:07:35.320 --> 00:07:36.960
Antrean adalah bagi kerja bersama untuk sebuah.

00:07:37.300 --> 00:07:38.720
Ini bukan kotak masuk satu agen

00:07:38.720 --> 00:07:40.920
dan bukan milik orang yang melihat permintaan tersebut.

00:07:41.500 --> 00:07:42.780
Sebaliknya, ini memberikan tempat

00:07:42.780 --> 00:07:44.440
bagi seluruh tim untuk melihat pekerjaan yang menunggu.

00:07:44.820 --> 00:07:46.500
Bayangkan sebuah perusahaan dengan tim penagihan,

00:07:46.840 --> 00:07:48.440
tim dukungan teknis, dan tim pengembalian.

00:07:49.040 --> 00:07:50.040
Tiap tim memiliki antrean jendis.

00:07:50.540 --> 00:07:51.960
Pertanyaan penagihan masuk ke penagihan,

00:07:52.080 --> 00:07:53.380
kesalahan produk kedukungan teknis,

00:07:53.680 --> 00:07:54.940
permintaan pengembalian ke pihak

00:07:54.940 --> 00:07:56.340
yang memahami proses pengembalian.

00:07:56.780 --> 00:07:58.120
Itu terdengar sederhana karena mengendemikian.

00:07:58.580 --> 00:07:59.920
Penyortiran yang jelas mencegah orang

00:07:59.920 --> 00:08:01.460
mengalihkan pekerjaan secara membabi buta.

00:08:01.700 --> 00:08:03.040
Aturan perutian membantu dalam penyortiran.

00:08:03.040 --> 00:08:05.500
Aturan perutian memeriksa detail pada kasus

00:08:05.500 --> 00:08:07.360
dan mengirimkannya ke antrean atau orang yang tepat.

00:08:07.940 --> 00:08:09.980
Kasus tentang produk tertentu masuk ke tim produk.

00:08:10.680 --> 00:08:12.740
Kasus dari wilayah tertentu masuk ke dukungan lokal.

00:08:13.320 --> 00:08:14.900
Masalah serius masuk ke antrean mendesak.

00:08:15.300 --> 00:08:16.940
Pertanyaan umum menunggu bersama tim standar.

00:08:17.560 --> 00:08:19.720
Beberapa organisasi mengarahkan pekerjaan berdasarkan kean.

00:08:20.020 --> 00:08:21.800
Contohnya pelanggan yang menulis dalam bahasa Perancis

00:08:21.800 --> 00:08:23.040
butuh agen yang bisa berbahasa Perancis.

00:08:23.320 --> 00:08:25.540
Masalah teknis memerlukan seseorang yang terladi pada produk tertentu.

00:08:26.200 --> 00:08:27.560
Perutian mendekatkan kasus kepada orang

00:08:27.560 --> 00:08:28.460
yang bisa menyelesaikannya

00:08:28.460 --> 00:08:30.120
daripada memperlakukan setiap permintaan sama.

00:08:30.640 --> 00:08:31.480
Otomatisasi membantu,

00:08:31.480 --> 00:08:32.500
tetapi orang tetap mengeputus.

00:08:33.080 --> 00:08:34.660
Ketua tim mungkin melihat kasus sulit

00:08:34.660 --> 00:08:36.160
dan memberikannya langsung ke agen senior.

00:08:36.760 --> 00:08:38.220
Mungkin seseorang sudah mengenal pelanggan tersub.

00:08:38.780 --> 00:08:40.360
Mungkin masalahnya mencakup beberapa produk

00:08:40.360 --> 00:08:42.040
dan butuh pengalaman yang tidak bisa dinilai aturan.

00:08:42.600 --> 00:08:44.100
Penugasan manual memberikan tim ruang

00:08:44.100 --> 00:08:45.200
untuk pilihan manusia tersebut.

00:08:45.520 --> 00:08:46.880
Kepemilikan bisa berubah selama penanganan.

00:08:47.400 --> 00:08:48.520
Agen mungkin butuh informasi lebih

00:08:48.520 --> 00:08:49.860
dan mengembalikan kasus keantrean.

00:08:50.580 --> 00:08:52.680
Tim mungkin menemukan masalahnya milik departemen lain

00:08:52.680 --> 00:08:54.620
atau permintaan mendesak mungkin perlu eskalasi

00:08:54.620 --> 00:08:56.260
saat tim biasa tidak bisa mengatasinya.

00:08:57.460 --> 00:08:59.120
Dynamik tiga nantang lemak menjaga pekerjaan

00:08:59.120 --> 00:09:01.080
tetap bergerak daripada membiarkannya terhenti pada seseorang.

00:09:01.720 --> 00:09:03.900
Terkadang, satu masalah bisa menciptakan banyak kasus.

00:09:04.660 --> 00:09:05.960
Bayangkan pemadaman perangkat lunak

00:09:05.960 --> 00:09:06.960
yang memengaruhi puluhan pelanggan.

00:09:07.480 --> 00:09:09.240
Setiap pelanggan menghubungi dukungan secara terbisa,

00:09:09.400 --> 00:09:10.700
jadi setiap laporan butuh kasusnya sendiri.

00:09:11.240 --> 00:09:13.320
Namun, semua laporan terhubung ke satu masalah yang lebih besar.

00:09:13.820 --> 00:09:15.400
Kasus induk melacak masalah yang lebih luas,

00:09:15.500 --> 00:09:18.260
sementara kasus anak melacak laporan pelanggan individu di bawahnya.

00:09:18.900 --> 00:09:20.400
Kita memberi tim dukungan dua sudut pandang sekaligus.

00:09:20.840 --> 00:09:23.260
Mereka mengerjakan pemadaman yang mendasar melalui kasus induk,

00:09:23.260 --> 00:09:25.920
sementara setiap kasus anak terus memberi informasi kepada pelanggan yang tepat.

00:09:26.180 --> 00:09:27.240
Saat mereka menemukan perbaikan,

00:09:27.360 --> 00:09:29.760
mereka tidak perlu menyelidiki pemadaman yang sama dari awal untuk zipnop.

00:09:30.100 --> 00:09:32.480
Kasus duplikat menciptakan masalah serupa dalam skala yang lebih kecil.

00:09:32.880 --> 00:09:35.380
Pelanggan mungkin mengirim surel dan menelpon untuk masalah yang sama,

00:09:35.500 --> 00:09:37.940
atau dua agen mungkin membuka kasus sebelum menyadari keberadaan kasus lain.

00:09:38.540 --> 00:09:39.560
Daripada membagi upaya,

00:09:39.800 --> 00:09:41.240
tim bisa menggabungkan kasus serupa,

00:09:42.140 --> 00:09:43.480
satu kasus menjadi catatan utama,

00:09:43.580 --> 00:09:44.540
dan pekerjaannya tetap bersatu.

00:09:45.080 --> 00:09:46.780
Jangan ada yang harus menyelesaikan masalah yang sama dua.

00:09:47.260 --> 00:09:48.460
Mengarahkan kasus keantrean,

00:09:48.560 --> 00:09:49.940
dan orang yang tepat memulai pekerjaannya,

00:09:49.940 --> 00:09:52.580
dan pelanggan mengharapkan respons dalam waktu yang dijanjikan.

00:09:53.940 --> 00:09:56.180
Menepati janji dengan SLA dan pekerjaan terpandu.

00:09:57.140 --> 00:09:59.380
Mengarahkan kasus ke orang yang tepat hanyalah setengah dari pekerjaan,

00:09:59.480 --> 00:10:01.680
karena pelanggan juga mengharapkan bantuan dalam waktu yang Anda janjikan.

00:10:02.060 --> 00:10:03.440
Dan disitulah perjanjian tingkat layanan,

00:10:03.920 --> 00:10:05.340
saya menyebutnya SLA, berperan.

00:10:06.160 --> 00:10:07.780
SLA memasang jam pada kasus,

00:10:08.000 --> 00:10:10.720
sehingga tim tahu persis berapa lama mereka harus memenuhi janji pelanggan,

00:10:11.060 --> 00:10:13.720
baik itu untuk membalas pertama kali atau menyelesaikan masalah sepenuhnya.

00:10:14.400 --> 00:10:15.360
Namun disini adalah penting yang mengatur.

00:10:16.020 --> 00:10:17.280
Tenggat waktunya tidak selalu sama.

00:10:17.280 --> 00:10:20.340
Ambil contoh pelanggan yang mengharapkan konfirmasi dalam satu jam,

00:10:20.540 --> 00:10:23.840
meskipun tim teknis butuh dua hari kerja untuk menemukan dan menguji perbaikannya.

00:10:24.640 --> 00:10:29.000
Dynamics 365 melacak target respons pertama dan target resolusi secara terpisah,

00:10:29.360 --> 00:10:32.940
sehingga tim dapat bertindak cepat tanpa harus berpura-pura bahwa setiap masalah dapat langsung diperbaiki.

00:10:33.300 --> 00:10:35.180
Sekarang bayangkan seorang pelanggan yang berhenti berfungsi.

00:10:35.720 --> 00:10:37.820
Mereka tidak berharap perbaikan selesai dalam 10 menit,

00:10:37.960 --> 00:10:40.900
tetapi mereka berharap seseorang memanfirmasi bahwa masalah tersebut diketahui,

00:10:41.040 --> 00:10:43.020
menjelaskan langkah selanjutnya, dan terus memberi mereka informasi.

00:10:43.020 --> 00:10:45.140
Target respons pertama melacak kontak awal tersebut,

00:10:45.140 --> 00:10:48.340
sementara target resolusi melacak seluruh tahapan hingga mendapatkan jawaban atau perbaikan.

00:10:48.840 --> 00:10:50.700
Dan pelanggan yang berbeda bisa mendapatkan janji layar yang berbeda-beda.

00:10:51.100 --> 00:10:55.040
Perusahaan dengan dukungan premium mendapatkan target respons yang lebih cepat daripada pelanggan dengan paket standar.

00:10:55.660 --> 00:11:00.120
Gangguan prioritas tinggi memiliki tenggat waktu yang lebih singkat daripada pertanyaan rutin tentang cara penggunaan.

00:11:00.800 --> 00:11:03.760
Perjanjian dukungan, prioritas, dan jenis kasus semuanya membentuk aturan berlaku.

00:11:04.240 --> 00:11:05.820
Hal tersebut menjaga janji tetap adil yang ceha.

00:11:06.080 --> 00:11:09.040
Tanpa SLA, seorang agen mungkin bekerja dari item terlama dalam daftar,

00:11:09.040 --> 00:11:11.680
sementara kasus yang sensitif terhadap waktu diam-diam melewati tenggat waktu.

00:11:11.680 --> 00:11:16.700
Dengan SLA, layar kasus menampilkan indikator waktu yang memberitahu agen janji mana yang perlu didahulukan.

00:11:17.480 --> 00:11:18.480
Anda akan melihat tekanan meningkat.

00:11:18.880 --> 00:11:23.640
Kasus dengan banyak sisa waktu perlu dikerjakan, tetapi kasus yang mendekati tenggat respons perlu segera ditangani.

00:11:24.560 --> 00:11:28.480
Tim juga dapat mengatur peringatan atau langkah eskala sisa target sudah dekat atau sudah terlewati,

00:11:28.800 --> 00:11:31.340
sehingga supervisor dapat turun tangan sebelum pelanggan harus mengejar tim.

00:11:32.060 --> 00:11:35.920
Target waktu memandu urgensi dan alur proses bisnis memandu pengerjaannya itu sendiri.

00:11:36.180 --> 00:11:39.340
Alur proses bisnis adalah serangkaian tahapan yang ditampilkan di dalam kasus.

00:11:39.340 --> 00:11:43.900
Ini memberikan jalur yang jelas bagi agen untuk diikuti berdasarkan cara organisasi menangani kasus.

00:11:44.520 --> 00:11:49.300
Tahapan dapat bergerak dari penerimaan keinvestigasi hingga resolusi dengan pertanyaan dan pemeriksaan yang tepat di setiap titik.

00:11:49.740 --> 00:11:52.220
Anggaplah ini sebagai daftar periksaan dengan penempatan yang tepat dalam proses.

00:11:52.440 --> 00:11:56.280
Agen baru tidak perlu menebak detail mana yang penting sebelum mengirimkan kasus ke spesialis.

00:11:56.680 --> 00:12:01.080
Alur ini dapat meminta informasi produk, jenis masalah, dampak, dan informasi lain yang dibutuhkan tim berikutnya.

00:12:01.280 --> 00:12:06.120
Agen yang lebih berpengalaman bisa bergerak lebih cepat, tetapi jalur bersama tetap membuat tim bekerja ke arah yang sama.

00:12:06.500 --> 00:12:07.160
Berikut skenario-nya.

00:12:07.160 --> 00:12:09.280
Sebuah gangguan layanan prioritas tinggi terjadi.

00:12:09.880 --> 00:12:12.660
Kasus masuk ke antrean mendesak dan SLA-nya mulai menghitung mundur.

00:12:13.300 --> 00:12:19.100
Agen mengonfirmasi detail pelanggan mencatat dampaknya dan mengirimkan respons pertama sebelum target respons tersebut berakhir.

00:12:19.860 --> 00:12:25.640
Selanjutnya, alur proses memindahkan kasus ke diagnosis, di mana tim mengumpulkan detail kesalahan dan meriksa laporan terkait.

00:12:26.120 --> 00:12:30.400
Kasus kemudian berpindah ke resolusi saat tim mengidentifikasi penyebabnya dan menyiapkan pembaruan untuk pelanggan.

00:12:30.920 --> 00:12:33.320
Perutuan tersebut juga memberikan gambaran yang lebih jelas bagi manajer.

00:12:33.320 --> 00:12:37.840
Mereka dapat melihat di mana kasus melambat selama penerimaan, diagnosis, atau respons pelanggan terakhir.

00:12:38.640 --> 00:12:43.020
Alur ini tidak menyelesaikan masalah bagi tim, tetapi mencegah langkah dasar terlewat saat hari yang sibuk.

00:12:43.560 --> 00:12:47.820
Dynamics 365 juga dapat mengontrol perubahan status mana yang bisa dipilih agen di titik yang berbeda.

00:12:48.340 --> 00:12:52.140
Ini disebut transisi alasan status yang terdengar teknis, namun idenya sederhana.

00:12:52.980 --> 00:12:54.820
Sebuah kasus harus bergerak melalui tahapan yang masuk akad.

00:12:54.820 --> 00:13:02.100
Anda tidak ingin seseorang menandai kasus selesai saat masih menunggu pemeriksaan internal atau langsung membatalkan kasus baru tanpa mencatat alasannya.

00:13:02.840 --> 00:13:05.160
Pilihan yang tersedia dapat berubah seiring perubahan status ke-1.

00:13:05.480 --> 00:13:09.920
Misalnya, kasus yang sedang diselidiki mungkin mengizinkan agen untuk menahannya sementara menunggu detail dari pelanggan.

00:13:10.560 --> 00:13:13.420
Setelah pelanggan membalas, agen dapat mengembalikannya ke pengerjaan aktif.

00:13:13.820 --> 00:13:16.120
Saat masalah teratasi, kasus dapat dipindahkan ke status selesai.

00:13:16.340 --> 00:13:17.520
Beritu menciptakan rewet kasus yang lalu.

00:13:17.860 --> 00:13:19.480
Balasan saja tidak menyelesaikan pekerjaan.

00:13:19.680 --> 00:13:22.800
Tim perlu mencatat bagaimana masalah berakhir, lalu menutup kasus dengan benar.

00:13:22.800 --> 00:13:25.660
Penyelesaian Pembelajaran Dana Yang Lebih Baik

00:13:25.660 --> 00:13:28.880
Mengirim balasan tidak secara otomatis menutup sebuah kasus.

00:13:29.160 --> 00:13:33.980
Tim perlu mencatat penyelesaiannya, yang berarti menuliskan apa yang memperbaiki masalah atau jawaban akhir yang diterima pelanggan.

00:13:34.560 --> 00:13:40.080
Itu bisa berupa penggantian perangkat, pengembalian dana pembayaran ganda, atau pelanggan memperbarui pengaturan yang memblokir akses.

00:13:40.860 --> 00:13:45.080
Catatan itu menjadi bagian dari rekam jejak pelanggan dan memberi agen berikutnya titik awal yang berguna

00:13:45.080 --> 00:13:48.120
jika pelanggan yang sama menghubungi dukungan lagi berbulan-bulan kemudian.

00:13:48.660 --> 00:13:50.020
Terkadang perbaikan pertama tidak berhasil.

00:13:50.020 --> 00:13:52.960
Mungkin pelanggan mengikuti petunjuknya, namun kesalahan muncul kembali.

00:13:53.400 --> 00:13:55.440
Mungkin suku cadang pengganti tiba namun tidak menyelesaikan kerusak.

00:13:56.000 --> 00:14:02.220
Dalam situasi itu, tim dapat membuka kembali kasus atau mengembalikannya ke antrean untuk pengerjaan lebih lanjut daripada memulai catatan baru tanpa riwayat.

00:14:03.020 --> 00:14:04.680
Kasus berlanjut dari tempat tim terakhir kali, betul.

00:14:05.260 --> 00:14:06.700
Hal itu penting ketika kepemimpinan kasus berpeng.

00:14:06.900 --> 00:14:11.720
Akin baru dapat melihat apa yang dicoba agen sebelumnya, apa yang dikonfirmasi pelanggan, dan apa yang masih perlu diberikan.

00:14:11.960 --> 00:14:16.220
Pelanggan tidak perlu menjelaskan seluruh cerita dari awal hanya karena orang yang berbeda menangani pekerjaan tersebut.

00:14:16.220 --> 00:14:21.280
Seiring waktu, semua kasus tersebut juga memberitahu tim dukungan tentang apa yang terjadi di luar masalah satu pelanggan.

00:14:21.700 --> 00:14:26.360
Manager dapat melihat waktu penyelesaian yang melacak berapa lama kasus berlangsung dari pembukaan hingga penutupan.

00:14:27.000 --> 00:14:29.620
Mereka dapat melihat durasi tahap yang menunjukkan di mana kasus menghabiskan waktu.

00:14:30.060 --> 00:14:32.160
Mereka juga dapat memantau penyelesaian kontak pertama.

00:14:32.160 --> 00:14:36.240
Artinya seberapa sering orang pertama yang berbicara dengan pelanggan dapat menyelesaikan masalah tanpa pengalihan.

00:14:36.760 --> 00:14:37.540
Pepan kerja juga penting.

00:14:38.080 --> 00:14:40.540
Jika satu antrean penuh setiap Senin pagi, tim dapat melihatnya.

00:14:41.140 --> 00:14:45.580
Jika kasus teknis harus menunggu berhari-hari untuk pemeriksaan internal, penundaan itu terlihat dalam data kasus.

00:14:45.580 --> 00:14:52.400
Jika satu tim menutup kasus dengan cepat, tetapi pelanggan terus membukanya kembali, tim punya alasan untuk mengeriksa kualitas perbaikan pertama tersebut.

00:14:52.940 --> 00:14:54.600
Angka-angka itu sendiri tidak menjelaskan segaranya.

00:14:55.020 --> 00:14:56.980
Angka tersebut mengarahkan tim pada pertanyaan yang lain diajukan.

00:14:57.640 --> 00:14:59.180
Mengapa kasus tentang satu produk meningkat?

00:14:59.180 --> 00:15:02.020
Mengapa jenis kasus tertentu memakan waktu lebih lama dari yang diperkirakan?

00:15:02.540 --> 00:15:06.580
Mengapa agen berulang kali mencari jawaban yang sama namun tidak menemukan artikel panduan yang berguna?

00:15:07.300 --> 00:15:09.660
Pola mengubah pekerjaan dukungan harian menjadi pembelajaran praktik.

00:15:10.080 --> 00:15:12.360
Peningkatan kasus serupa mungkin menunjukkan adanya kerusakan produk.

00:15:12.360 --> 00:15:14.940
Hal itu mungkin menunjukkan bahwa pembaruan terkini membingungkan.

00:15:15.300 --> 00:15:17.760
Hal itu mungkin mengungkap bahwa panduan instruksi memerlukan langkah yang lebih jelas.

00:15:18.240 --> 00:15:22.320
Hal itu memperlakukan setiap permintaan sebagai sesuatu yang tidak terkait, tim dapat menemukan penyebab yang sama dan menangan.

00:15:22.620 --> 00:15:24.220
Hal itu dapat mengurangi volume kasus di masa ini.

00:15:24.220 --> 00:15:25.960
Umpan balik pelanggan juga termasuk dalam kelemperan.

00:15:26.380 --> 00:15:29.060
Kasus yang ditutup mungkin menunjukkan tim telah memiliki target respons,

00:15:29.180 --> 00:15:32.740
namun pelanggan mungkin tetap merasa frustrasi jika harus menghubungi dukungan sebanyak tiga kali.

00:15:33.560 --> 00:15:37.140
Melihat kasus sekaligus umpan balik kemencer pandangan yang lebih lengkap mengenai pengalaman pelanggan.

00:15:37.560 --> 00:15:39.860
Beberapa pelanggan lebih memilih untuk tidak perlu membuat kasus sama sekali.

00:15:40.120 --> 00:15:41.740
Disinilah portal layanan mendiri dapat membuat.

00:15:42.080 --> 00:15:44.140
Melalui portal, pelanggan dapat membuat permintaan,

00:15:44.140 --> 00:15:46.220
memperiksa statusnya, menambahkan informasi baru,

00:15:46.360 --> 00:15:49.420
atau membaca artikel dukungan resmi, tanpa harus menghubungi tim dukungan.

00:15:49.980 --> 00:15:52.660
Untuk pertanyaan sederhana, ini dapat menghemat waktu bagi semua orang.

00:15:53.120 --> 00:15:56.620
Pelanggan dapat memperiksa status pengiriman atau mengikuti panduan pengaturan saat mereka sempat.

00:15:56.620 --> 00:16:00.940
Sementara itu, agen dapat menghabiskan lebih banyak waktu untuk masalah yang memerlukan penyelidikan,

00:16:01.040 --> 00:16:02.720
penjelasan, atau pengambilan keputusan oleh manusia.

00:16:02.960 --> 00:16:07.740
Dynamics 3.0 Service juga dapat terhubung dengan alat Microsoft yang familiar di sekitar proses penanganan kasus.

00:16:08.200 --> 00:16:10.120
Seorang agen dapat bekerja dengan email melalui optimal.

00:16:10.500 --> 00:16:12.260
Sebuah tim mungkin mendiskusikan masalah sulit di Teams.

00:16:13.020 --> 00:16:14.960
Dokumen dan informasi bersama dapat disimpan di SharePoint.

00:16:15.440 --> 00:16:18.100
Power BI dapat mengubah data kasus menjadi laporan dan dashboard,

00:16:18.100 --> 00:16:20.860
sementara alat Power Platform dapat mendukung formulir, pemberitahuan,

00:16:21.000 --> 00:16:23.000
atau langkah otomatis tambahan untuk proses tim tersebut.

00:16:23.820 --> 00:16:24.880
Setiap alat memiliki fungsi masing.

00:16:24.880 --> 00:16:28.180
Kasus tetap menjadi tempat di mana masalah dukungan dan riwayatnya saling terhubung,

00:16:28.340 --> 00:16:30.520
bahkan ketika orang menggunakan alat lain untuk berkomunikasi,

00:16:30.620 --> 00:16:32.020
berbagi file, atau meninjau pekerjaan.

00:16:32.760 --> 00:16:34.960
Manajemen kasus bukan hanya sekadar mengisi layar tiket.

00:16:35.520 --> 00:16:37.640
Ini tentang memberikan setiap masalah pelanggan jalur yang jelas,

00:16:37.760 --> 00:16:39.900
jawaban yang tercatat, dan tim yang dapat belajar dari apa yang terjadi.

00:16:42.040 --> 00:16:43.460
Simpanlah sederhana cerita pelanggan secara malam.

00:16:44.120 --> 00:16:44.960
Di inilah poin utamanya.

00:16:46.060 --> 00:16:50.140
Manajemen kasus Dynamics 365 menyimpan masalah, pekerjaan, janji,

00:16:50.340 --> 00:16:51.580
dan hasilnya dalam satu catatan.

00:16:52.180 --> 00:16:54.020
Tidak ada lagi konteks yang hilang atau perbaikan yang berulang.

00:16:54.020 --> 00:16:55.520
Lihatlah proses dukungan Anda sendiri.

00:16:56.020 --> 00:16:57.580
Oh, ke mana perginya informasi pelanggan?

00:16:58.300 --> 00:17:00.300
Disitulah menyatukan semuanya mengubah segalanya.

00:17:00.960 --> 00:17:02.800
Berlanggananlah di platform podcast favorit Anda

00:17:02.800 --> 00:17:05.040
untuk mendapatkan lebih banyak wawasan Microsoft dari saya,

00:17:05.160 --> 00:17:06.820
Mirko Peters, di M36B.M.

00:17:06.820 --> 00:17:10.260
Tempat kami menjelaskan alat Microsoft di balik pekerjaan sehari-hari dalam bahasa yang sederhana.