Seorang pelanggan mengirim email tentang pesanan yang rusak, lalu menelpon keesokan harinya, kemudian membuka obrolan karena tidak ada yang tahu apa yang terjadi, dan mereka mengulang cerita yang sama setiap saat sementara tim dukungan Anda mencari-cari di kotak masuk catatan dan alat yang terpisah. Itulah tepatnya yang diperbaiki oleh manajemen kasus Dynamics 365. Anggaplah sebuah kasus seperti satu folder berlabel di dalam gedung kantor yang sibuk, di mana setiap bagian dari masalah pelanggan masuk ke dalam folder itu mulai dari pertanyaan pertama hingga Jumlah akhir. Anda bersama Mirko Peters dari M365FM, dan dalam segmen pengetahuan ini, Anda akan melihat bagaimana kasus, perutean, tengkat waktu respons, artikel dukungan, dan penutupan semuanya saling terkait. Apa sebenarnya kasus itu dalam 20 kata? Jadi apa sebenarnya kasus itu? Kasus adalah satu catatan untuk satu masalah pelanggan yang memerlukan jawaban atau perbaikan, dan masalah tersebut bisa berupa produk yang rusak, pertanyaan tagihan, masalah login, atau permintaan bantuan dan menggunakan layanan.

Inilah intinya, satu pelanggan bisa memiliki beberapa kasus sekaligus. Seorang pelanggan mungkin bertanya tentang faktur pada hari Senin, melaporkan perangkat yang rusak pada hari Selasa, dan memerlukan bantuan untuk mengubah alamat. 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. Saat agen membuat kasus, mereka langsung menautkannya ke pelanggan. Pelanggan tersebut bisa berupa kontak yang berarti orang perseorangan, atau akun yang berarti perusahaan tempat mereka bekerja. Jadi jika Jamie dari Northwind Traders melaporkan masalah, kasus tersebut dapat merujuk pada Jamie dan perusahaannya, dan siapa punya buka catatan tersebut dapat melihat siapa yang memerlukan bantuan dan organisasi mana masalah tersebut beras. Kasus tersebut juga memerlukan deskripsi masalah yang jelas, biasanya dimulai dengan judul seperti Printer kami berhenti setelah pembaruan perangkat lunak atau Pelanggan kami ditagih dua kali untuk paket tahunan, dan judul tersebut membantu orang memindai daftar kasus terbuka tanpa harus membuka setiap catatan.

Di bawah judul tersebut, agen menambahkan detailnya. Apa yang terjadi? Apa yang sudah dicoba oleh pelanggan? Produk mana yang terlibat? Dan apakah itu sebuah pertanyaan, permintaan, atau kesalahan? Detail ini mengubah pesan yang samar menjadi pekerjaan yang dapat dimiliki dan diselesaikan oleh seseorang. Mari kita bedah lebih jauh. Sebuah kasus dapat menguat subjek, produk, prioritas, dan jenis kasus. Subjek mengelompokkan masalah ke dalam bidang seperti penagihan atau dukungan teknis, produk mengidentifikasi apa yang digunakan pelanggan, prioritas memberi tahu tim seberapa cepat harus menanganinya, dan jenis kasus memberi tim cara lain untuk menyaktifkan pekerjaan berdasarkan proses dukungan mereka. Tidak satu pun dari kolom ini menyelesaikan masalah pelanggan dengan sendirinya, tetapi semuanya membantu tim dukungan melihat pekerjaan dengan jelas, terutama ketika ratusan kasus datang dari pelanggan yang berbeda.

Sebuah tim yang menangani kegagalan layanan serius seharusnya tidak perlu mencari melalui pertanyaan umum untuk menemukannya. Jadi, sebuah kasus bukan sekadar formulir yang diisi lalu dilupakan begitu saja. Kasus tersebut menjadi catatan kerja untuk keseluruhan pencakapan. Email dapat terhubung ke kasus, panggilan telepon dapat muncul di sana, dan agen dapat menambahkan catatan setelah berolah, menetapkan tugas tindak lanjut, atau mencatat janji temu. Setiap aktivitas tetap bersama masalah pelanggan yang sama, sehingga orang berikutnya tidak perlu menyusun ulang ceritanya dari awal. Bayangkan seorang agen mulai bekerja di pagi hari, lalu menyerahkan kasus tersebut kepada spesialis produk setelah makan siang. Tanpa catatan kasus, spesialis mungkin hanya menerima pesan singkat seperti, oh, bisakah Anda melihat ini? Yang tidak cukup. Dengan catatan kasus, mereka dapat melihat masalah awal, detail pelanggan, apa yang terjadi selama panggilan, dan apa yang sudah diperiksa oleh agen pertama.

Hal itu menawarkan proses ratrimack. Dynamics 365 menjaga status kasus tetap jelas saat bergerak melalui proses dukungan. Kasus dapat tetap aktif sementara tim melakukan investigasi, dan setelah tim memperbaiki masalah atau memberikan jawaban akhir, mereka menyelesaikan. Jika permintaan tidak lagi memerlukan tindakan, mungkin karena kesalahan atau pelanggan batalkannya, tim dapat membatalkan kasus tersebut. Aktif selesai dan dibatalkan. Ketiga status tersebut, memberikan pandangan bersama kepada tim mengenai posisi setiap masalah, sehingga tidak ada yang perlu menebak apakah suatu kasus masih memerlukan perhatian, dan manajer tidak perlu memperlakukan pekerjaan lamai yang sudah selesai sebagai masalah pelanggan baru. Satu catatan memberi Anda kendali, dan riwayat pelanggan yang lengkap memberi agen konteks. Kisah pelanggan dibalik kasus tersebut. Sebuah kasus memberitahu Anda apa yang perlu diperbaik.

Catatan pelanggan memberitahu Anda apa yang mengarah pada kamu. Saat agen membuka kasus di Dynamics 365 Customer Service, mereka dapat melihat lebih dari sekadar pesan terbaru. Mereka melihat gambaran yang lebih besar, seperti kasus sebelumnya, email masa lalu, produk yang terhubung ke pelanggan, dan riwayat dukungan mereka. Nah, konteks mengubah percakapan. Mengapa konteks itu penting? Bayangkan seorang pelanggan melaporkan kegagalan perangkat. Jika agen hanya melihat pesan hari ini, mereka mungkin memulai dengan pertanyaan dasar. Oda, apa ini? Kapan masa ini mulai? Sudah karena menyalahkan orang perangkat? Namun pelanggan tersebut sudah menghubungi dukungan dua kali minggu ini. Agen pertama mengirimkan langkah pemecahan masalah, yang kedua mengatur suku cadang pengganti. Agen ketiga yang melihat riwayat tersebut tidak akan meminta pelanggan untuk mengulang dari awal. Sebaliknya, mereka berkata, saya lihat Anda sudah mencoba langkah-langkah itu,

itu terasa sangat berbeda dari bisakah Anda menjelaskan masalahnya lagi. Ini sering disebut sebagai tampilan pelanggan 360 rukit. Namanya terdengar canggih, padahal sederhana. Artinya, agen melihat pelanggan dari lebih dari satu sudut pandang, bukan hanya satu pesan terisolasi. Agen melihat orangnya, perusahaannya, permintaan dukungan sebelumnya, pecakapan terdahulu, dan produk yang terhubung dengan mereka. Bagi tim dukungan, hal ini menggantikan tebakan dengan titik awal yang jelas. Sekarang, tidak setiap pelanggan menerima jenis dukungan yang sama. Pelanggan mungkin telah membeli garansi perusahaan mereka mungkin membayar sejumlah jam dukungan. Atau mereka memiliki kontrak untuk sejumlah kasus atau dukungan premium dengan bantuan lebih cepat. Dynamics 365 melacak semua ini melalui hak entitlements. Hak adalah perjanjian dukungan pelanggan kami. Di dalam sistem, anggap saja sebagai ketentuan layanan yang melekat pada akun mereka.

Sebelum agen menjanjikan waktu teknisi atau memulai pekerjaan berbayar, mereka memeriksa dukungan apa yang berlaku. Itu menghindari kejutan yang tidak menyenangkan. Sebagai contoh, pelanggan mungkin masih memiliki jaminan untuk produk yang rusak. Kasus tersebut bisa mengikuti alurit. Pelanggan lain mungkin telah menggunakan seluruh jam dukungan mereka. Agen melihatnya sebelum berkomitmen pada pekerjaan jian. Ini juga membantu tim dukungan memperlakukan pelanggan DNA. Agen tidak perlu mencari melalui kontrak lama atau bertanya ke departemen. Ketentuan dukungan tersimpan bersama informasi pelanggan tepat ingin dapat menemukannya. Kemudian ada basis pengetahuan. Tim dukungan menyelesaikan masalah yang sama berulang kali. Riset kata Sandi, petunjuk pengaturan, kesalahan umum setelah pembaruan, pertanyaan tagihan dengan jawaban standar, artikel pengetahuan menyimpan jawaban tersebut di satu tempat.

Di dalam ruang kerja layanan, agen dapat mencari artikel saat mengerjakan sebuah kasus. Artikel mungkin menyertakan penjelasan sederhana, langkah-langkah, tangkapan layar, atau pemeriksaan tepat yang harus diselesaikan tim. Daripada setiap agen menulis versinya sendiri, dari ingatan, mereka menggunakan jawaban bersama yang telah ditinjau tim. Itu menjaga dukungan tetap konsisten. Ini juga mendapatkan yang lebih baru. Mereka tidak butuh pengalaman bertahun-tahun untuk menangani masalah umum, dengan baik karena sorusi dari tim sudah tersedia saat dibutuhkan. Ringkasan kasus kopilot membantu mengatasi masalah umum lainnya, yaitu riwayat kasus yang panjang. Sebuah kasus dapat mengumpulkan banyak email, catatan, dan pembadanan seiring berjalan. Membaca semuanya merupakan waktu, terutama setelah adanya pengalaman. Kopilot membuat ringkasan kasus singkat yang menyatukan judul kasus, pelanggan, subjek, produk, prioritas, jenis kasus, deskripsi, dan aktivitas terkini.

Ini adalah ringkasan cepat sebelum agen mulai bekerja. Agen tetap meriksa catatan dan menggunakan penjelasan mereka, tetapi mereka memahami situasi dengan lebih cepat. Hal itu sangat membantu saat pelanggan menunggu dan kasus telah berpindah tangan beberapa kali. Setelah agen memahami pelanggan dan masalahnya, kasus tersebut harus sampai ke orang yang tepat.

Dari penerimaan hingga kantor yang tepat, pelanggan dapat meminta bantuan melalui banyak cara seperti email, telepon, oprola, media sosial, atau portal layan mendidik. Salurannya berubah, tetapi tim dukungan tetap membutuhkan satu tempat yang jelas untuk mengeluarkan tersebut. Dynamics 365 dapat membuat kasus dari percakapan tersebut jika pengaturannya mencakup aturan pembuatan catatan. Bayangkan sebuah email yang tiba di alamat dukungan bersama, alih-alih membiarkannya di kotak surat sampai seseorang melihatnya, sebuah aturan mengubah email tersebut menjadi kasus. Pesan tersebut menjadi awal pekerjaan di dalam layanan pelanggan. Hal itu mengurangi penyalian secara manual. Gagasan yang sama berlaku untuk saluran terhubung lainnya. Tim memilih pesan mana yang membuat kasus baru dan mana yang termasuk dalam kasus yang sudah ada. Balasan untuk masalah yang terbuka akan tetap bersama-sama. Pertanyaan baru akan mendapatkan kasusnya sendiri.

Kemudian kasus tersebut membutuhkan tempat sementara semula mengambil tangan. Tempat itu biasanya berupa antrean. Antrean adalah bagi kerja bersama untuk sebuah. Ini bukan kotak masuk satu agen dan bukan milik orang yang melihat permintaan tersebut. Sebaliknya, ini memberikan tempat bagi seluruh tim untuk melihat pekerjaan yang menunggu. Bayangkan sebuah perusahaan dengan tim penagihan, tim dukungan teknis, dan tim pengembalian. Tiap tim memiliki antrean jendis. Pertanyaan penagihan masuk ke penagihan, kesalahan produk kedukungan teknis, permintaan pengembalian ke pihak yang memahami proses pengembalian. Itu terdengar sederhana karena mengendemikian. Penyortiran yang jelas mencegah orang mengalihkan pekerjaan secara membabi buta. Aturan perutian membantu dalam penyortiran. Aturan perutian memeriksa detail pada kasus dan mengirimkannya ke antrean atau orang yang tepat. Kasus tentang produk tertentu masuk ke tim produk.

Kasus dari wilayah tertentu masuk ke dukungan lokal. Masalah serius masuk ke antrean mendesak. Pertanyaan umum menunggu bersama tim standar. Beberapa organisasi mengarahkan pekerjaan berdasarkan kean. Contohnya pelanggan yang menulis dalam bahasa Perancis butuh agen yang bisa berbahasa Perancis. Masalah teknis memerlukan seseorang yang terladi pada produk tertentu. Perutian mendekatkan kasus kepada orang yang bisa menyelesaikannya daripada memperlakukan setiap permintaan sama. Otomatisasi membantu, tetapi orang tetap mengeputus. Ketua tim mungkin melihat kasus sulit dan memberikannya langsung ke agen senior. Mungkin seseorang sudah mengenal pelanggan tersub. Mungkin masalahnya mencakup beberapa produk dan butuh pengalaman yang tidak bisa dinilai aturan. Penugasan manual memberikan tim ruang untuk pilihan manusia tersebut. Kepemilikan bisa berubah selama penanganan. Agen mungkin butuh informasi lebih dan mengembalikan kasus keantrean.

Tim mungkin menemukan masalahnya milik departemen lain atau permintaan mendesak mungkin perlu eskalasi saat tim biasa tidak bisa mengatasinya. Dynamik tiga nantang lemak menjaga pekerjaan tetap bergerak daripada membiarkannya terhenti pada seseorang. Terkadang, satu masalah bisa menciptakan banyak kasus. Bayangkan pemadaman perangkat lunak yang memengaruhi puluhan pelanggan. Setiap pelanggan menghubungi dukungan secara terbisa, jadi setiap laporan butuh kasusnya sendiri. Namun, semua laporan terhubung ke satu masalah yang lebih besar. Kasus induk melacak masalah yang lebih luas, sementara kasus anak melacak laporan pelanggan individu di bawahnya. Kita memberi tim dukungan dua sudut pandang sekaligus. Mereka mengerjakan pemadaman yang mendasar melalui kasus induk, sementara setiap kasus anak terus memberi informasi kepada pelanggan yang tepat. Saat mereka menemukan perbaikan, mereka tidak perlu menyelidiki pemadaman yang sama dari awal untuk zipnop.

Kasus duplikat menciptakan masalah serupa dalam skala yang lebih kecil. Pelanggan mungkin mengirim surel dan menelpon untuk masalah yang sama, atau dua agen mungkin membuka kasus sebelum menyadari keberadaan kasus lain. Daripada membagi upaya, tim bisa menggabungkan kasus serupa, satu kasus menjadi catatan utama, dan pekerjaannya tetap bersatu. Jangan ada yang harus menyelesaikan masalah yang sama dua. Mengarahkan kasus keantrean, dan orang yang tepat memulai pekerjaannya, dan pelanggan mengharapkan respons dalam waktu yang dijanjikan. Menepati janji dengan SLA dan pekerjaan terpandu. Mengarahkan kasus ke orang yang tepat hanyalah setengah dari pekerjaan, karena pelanggan juga mengharapkan bantuan dalam waktu yang Anda janjikan. Dan disitulah perjanjian tingkat layanan, saya menyebutnya SLA, berperan. SLA memasang jam pada kasus, sehingga tim tahu persis berapa lama mereka harus memenuhi janji pelanggan, baik itu untuk membalas pertama kali atau menyelesaikan masalah sepenuhnya.

Namun disini adalah penting yang mengatur. Tenggat waktunya tidak selalu sama. Ambil contoh pelanggan yang mengharapkan konfirmasi dalam satu jam, meskipun tim teknis butuh dua hari kerja untuk menemukan dan menguji perbaikannya. Dynamics 365 melacak target respons pertama dan target resolusi secara terpisah, sehingga tim dapat bertindak cepat tanpa harus berpura-pura bahwa setiap masalah dapat langsung diperbaiki. Sekarang bayangkan seorang pelanggan yang berhenti berfungsi. Mereka tidak berharap perbaikan selesai dalam 10 menit, tetapi mereka berharap seseorang memanfirmasi bahwa masalah tersebut diketahui, menjelaskan langkah selanjutnya, dan terus memberi mereka informasi. Target respons pertama melacak kontak awal tersebut, sementara target resolusi melacak seluruh tahapan hingga mendapatkan jawaban atau perbaikan. Dan pelanggan yang berbeda bisa mendapatkan janji layar yang berbeda-beda.

Perusahaan dengan dukungan premium mendapatkan target respons yang lebih cepat daripada pelanggan dengan paket standar. Gangguan prioritas tinggi memiliki tenggat waktu yang lebih singkat daripada pertanyaan rutin tentang cara penggunaan. Perjanjian dukungan, prioritas, dan jenis kasus semuanya membentuk aturan berlaku. Hal tersebut menjaga janji tetap adil yang ceha. Tanpa SLA, seorang agen mungkin bekerja dari item terlama dalam daftar, sementara kasus yang sensitif terhadap waktu diam-diam melewati tenggat waktu. Dengan SLA, layar kasus menampilkan indikator waktu yang memberitahu agen janji mana yang perlu didahulukan. Anda akan melihat tekanan meningkat. Kasus dengan banyak sisa waktu perlu dikerjakan, tetapi kasus yang mendekati tenggat respons perlu segera ditangani. Tim juga dapat mengatur peringatan atau langkah eskala sisa target sudah dekat atau sudah terlewati, sehingga supervisor dapat turun tangan sebelum pelanggan harus mengejar tim.

Target waktu memandu urgensi dan alur proses bisnis memandu pengerjaannya itu sendiri. Alur proses bisnis adalah serangkaian tahapan yang ditampilkan di dalam kasus. Ini memberikan jalur yang jelas bagi agen untuk diikuti berdasarkan cara organisasi menangani kasus. Tahapan dapat bergerak dari penerimaan keinvestigasi hingga resolusi dengan pertanyaan dan pemeriksaan yang tepat di setiap titik. Anggaplah ini sebagai daftar periksaan dengan penempatan yang tepat dalam proses. Agen baru tidak perlu menebak detail mana yang penting sebelum mengirimkan kasus ke spesialis. Alur ini dapat meminta informasi produk, jenis masalah, dampak, dan informasi lain yang dibutuhkan tim berikutnya. Agen yang lebih berpengalaman bisa bergerak lebih cepat, tetapi jalur bersama tetap membuat tim bekerja ke arah yang sama. Berikut skenario-nya. Sebuah gangguan layanan prioritas tinggi terjadi. Kasus masuk ke antrean mendesak dan SLA-nya mulai menghitung mundur.

Agen mengonfirmasi detail pelanggan mencatat dampaknya dan mengirimkan respons pertama sebelum target respons tersebut berakhir. Selanjutnya, alur proses memindahkan kasus ke diagnosis, di mana tim mengumpulkan detail kesalahan dan meriksa laporan terkait. Kasus kemudian berpindah ke resolusi saat tim mengidentifikasi penyebabnya dan menyiapkan pembaruan untuk pelanggan. Perutuan tersebut juga memberikan gambaran yang lebih jelas bagi manajer. Mereka dapat melihat di mana kasus melambat selama penerimaan, diagnosis, atau respons pelanggan terakhir. Alur ini tidak menyelesaikan masalah bagi tim, tetapi mencegah langkah dasar terlewat saat hari yang sibuk. Dynamics 365 juga dapat mengontrol perubahan status mana yang bisa dipilih agen di titik yang berbeda. Ini disebut transisi alasan status yang terdengar teknis, namun idenya sederhana. Sebuah kasus harus bergerak melalui tahapan yang masuk akad.

Anda tidak ingin seseorang menandai kasus selesai saat masih menunggu pemeriksaan internal atau langsung membatalkan kasus baru tanpa mencatat alasannya. Pilihan yang tersedia dapat berubah seiring perubahan status ke-1. Misalnya, kasus yang sedang diselidiki mungkin mengizinkan agen untuk menahannya sementara menunggu detail dari pelanggan. Setelah pelanggan membalas, agen dapat mengembalikannya ke pengerjaan aktif. Saat masalah teratasi, kasus dapat dipindahkan ke status selesai. Beritu menciptakan rewet kasus yang lalu. Balasan saja tidak menyelesaikan pekerjaan. Tim perlu mencatat bagaimana masalah berakhir, lalu menutup kasus dengan benar. Penyelesaian Pembelajaran Dana Yang Lebih Baik Mengirim balasan tidak secara otomatis menutup sebuah kasus. Tim perlu mencatat penyelesaiannya, yang berarti menuliskan apa yang memperbaiki masalah atau jawaban akhir yang diterima pelanggan. Itu bisa berupa penggantian perangkat, pengembalian dana pembayaran ganda, atau pelanggan memperbarui pengaturan yang memblokir akses.

Catatan itu menjadi bagian dari rekam jejak pelanggan dan memberi agen berikutnya titik awal yang berguna jika pelanggan yang sama menghubungi dukungan lagi berbulan-bulan kemudian. Terkadang perbaikan pertama tidak berhasil. Mungkin pelanggan mengikuti petunjuknya, namun kesalahan muncul kembali. Mungkin suku cadang pengganti tiba namun tidak menyelesaikan kerusak. Dalam situasi itu, tim dapat membuka kembali kasus atau mengembalikannya ke antrean untuk pengerjaan lebih lanjut daripada memulai catatan baru tanpa riwayat. Kasus berlanjut dari tempat tim terakhir kali, betul. Hal itu penting ketika kepemimpinan kasus berpeng. Akin baru dapat melihat apa yang dicoba agen sebelumnya, apa yang dikonfirmasi pelanggan, dan apa yang masih perlu diberikan. Pelanggan tidak perlu menjelaskan seluruh cerita dari awal hanya karena orang yang berbeda menangani pekerjaan tersebut. Seiring waktu, semua kasus tersebut juga memberitahu tim dukungan tentang apa yang terjadi di luar masalah satu pelanggan.

Manager dapat melihat waktu penyelesaian yang melacak berapa lama kasus berlangsung dari pembukaan hingga penutupan. Mereka dapat melihat durasi tahap yang menunjukkan di mana kasus menghabiskan waktu. Mereka juga dapat memantau penyelesaian kontak pertama. Artinya seberapa sering orang pertama yang berbicara dengan pelanggan dapat menyelesaikan masalah tanpa pengalihan. Pepan kerja juga penting. Jika satu antrean penuh setiap Senin pagi, tim dapat melihatnya. Jika kasus teknis harus menunggu berhari-hari untuk pemeriksaan internal, penundaan itu terlihat dalam data kasus. Jika satu tim menutup kasus dengan cepat, tetapi pelanggan terus membukanya kembali, tim punya alasan untuk mengeriksa kualitas perbaikan pertama tersebut. Angka-angka itu sendiri tidak menjelaskan segaranya. Angka tersebut mengarahkan tim pada pertanyaan yang lain diajukan. Mengapa kasus tentang satu produk meningkat?

Mengapa jenis kasus tertentu memakan waktu lebih lama dari yang diperkirakan? Mengapa agen berulang kali mencari jawaban yang sama namun tidak menemukan artikel panduan yang berguna? Pola mengubah pekerjaan dukungan harian menjadi pembelajaran praktik. Peningkatan kasus serupa mungkin menunjukkan adanya kerusakan produk. Hal itu mungkin menunjukkan bahwa pembaruan terkini membingungkan. Hal itu mungkin mengungkap bahwa panduan instruksi memerlukan langkah yang lebih jelas. Hal itu memperlakukan setiap permintaan sebagai sesuatu yang tidak terkait, tim dapat menemukan penyebab yang sama dan menangan. Hal itu dapat mengurangi volume kasus di masa ini. Umpan balik pelanggan juga termasuk dalam kelemperan. Kasus yang ditutup mungkin menunjukkan tim telah memiliki target respons, namun pelanggan mungkin tetap merasa frustrasi jika harus menghubungi dukungan sebanyak tiga kali. Melihat kasus sekaligus umpan balik kemencer pandangan yang lebih lengkap mengenai pengalaman pelanggan.

Beberapa pelanggan lebih memilih untuk tidak perlu membuat kasus sama sekali. Disinilah portal layanan mendiri dapat membuat. Melalui portal, pelanggan dapat membuat permintaan, memperiksa statusnya, menambahkan informasi baru, atau membaca artikel dukungan resmi, tanpa harus menghubungi tim dukungan. Untuk pertanyaan sederhana, ini dapat menghemat waktu bagi semua orang. Pelanggan dapat memperiksa status pengiriman atau mengikuti panduan pengaturan saat mereka sempat. Sementara itu, agen dapat menghabiskan lebih banyak waktu untuk masalah yang memerlukan penyelidikan, penjelasan, atau pengambilan keputusan oleh manusia. Dynamics 3.0 Service juga dapat terhubung dengan alat Microsoft yang familiar di sekitar proses penanganan kasus. Seorang agen dapat bekerja dengan email melalui optimal. Sebuah tim mungkin mendiskusikan masalah sulit di Teams. Dokumen dan informasi bersama dapat disimpan di SharePoint.

Power BI dapat mengubah data kasus menjadi laporan dan dashboard, sementara alat Power Platform dapat mendukung formulir, pemberitahuan, atau langkah otomatis tambahan untuk proses tim tersebut. Setiap alat memiliki fungsi masing. Kasus tetap menjadi tempat di mana masalah dukungan dan riwayatnya saling terhubung, bahkan ketika orang menggunakan alat lain untuk berkomunikasi, berbagi file, atau meninjau pekerjaan. Manajemen kasus bukan hanya sekadar mengisi layar tiket. Ini tentang memberikan setiap masalah pelanggan jalur yang jelas, jawaban yang tercatat, dan tim yang dapat belajar dari apa yang terjadi.

Simpanlah sederhana cerita pelanggan secara malam. Di inilah poin utamanya. Manajemen kasus Dynamics 365 menyimpan masalah, pekerjaan, janji, dan hasilnya dalam satu catatan. Tidak ada lagi konteks yang hilang atau perbaikan yang berulang. Lihatlah proses dukungan Anda sendiri. Oh, ke mana perginya informasi pelanggan? Disitulah menyatukan semuanya mengubah segalanya. Berlanggananlah di platform podcast favorit Anda untuk mendapatkan lebih banyak wawasan Microsoft dari saya, Mirko Peters, di M36B.M. Tempat kami menjelaskan alat Microsoft di balik pekerjaan sehari-hari dalam bahasa yang sederhana.