WEBVTT

00:00:00.340 --> 00:00:07.120
Siap untuk 10 hari pembahasan Microsoft 365, Copilot AI, Azure, dan para tokoh yang membentuk masa depan dunia kerja.

00:00:07.860 --> 00:00:11.980
Januari ini, M365-chan kembali hadir dan kami akan tampil lebih besar.

00:00:12.760 --> 00:00:18.340
Bergabunglah bersama kami untuk sesi langsung demo dunia nyata dan pengetahuan praktis dari para MVP serta paka industri di seluruh dunia.

00:00:18.880 --> 00:00:21.160
Tanpa slide yang umum, tanpa istilah teknis yang berteler.

00:00:21.640 --> 00:00:28.660
Kami akan membahas tantangan nyata, Copilot Studio, agen AI Fabrik, keamanan, tata kelola, dan otomatisasi.

00:00:28.660 --> 00:00:34.380
Baik Anda seorang profesional TI, pengembang, atau pemimpin bisnis, ada sesi yang dirancang khusus untuk Anda.

00:00:35.380 --> 00:00:39.920
Dengan 10 hari penuh, Anda bisa menjelajahi berbagai teknologi dan terhubung dengan komunitas global.

00:00:40.900 --> 00:00:44.280
Tonton secara langsung dan bawa wasan praktis kembali ke organisasi Anda.

00:00:45.180 --> 00:00:48.900
Januari 2027, 10 hari, satu komunitas Microsoft.

00:00:49.420 --> 00:00:50.520
Pendaftaran sudah dibuka sekarang.

00:00:52.580 --> 00:00:54.620
Amankan tempat Anda hari ini.

00:00:56.120 --> 00:00:58.240
Kunjungi M365-chan.net.

00:00:59.900 --> 00:01:04.640
Bergabunglah sekarang di M365-chan.net dan sampai jumpa secara langsung di bulan Januari.

00:01:05.280 --> 00:01:08.620
Bayangkan seorang pelanggan membeli jaket di situs web Anda, memilih pengambilan di toko,

00:01:08.720 --> 00:01:11.420
lalu memutuskan ukurannya tidak pas dan mengembalikannya di lokasi yang berbeda.

00:01:11.740 --> 00:01:12.840
Terdengar cukup sederhana bukan?

00:01:13.280 --> 00:01:16.360
Namun bagi banyak bisnis, satu pembelian itu menyentuh sistem yang terpisah.

00:01:17.140 --> 00:01:18.540
Situs web mengetahui pesanan tersebut.

00:01:18.720 --> 00:01:20.220
Kasir toko mengetahui pengembaliannya.

00:01:20.420 --> 00:01:22.480
Sistem stok melacak di mana jaket itu berada.

00:01:22.480 --> 00:01:24.780
Dan rincian pelanggan ada di tempat lain.

00:01:25.740 --> 00:01:28.280
Hal itu menciptakan celah keterlambatan dan percakapan yang cenggung di kol.

00:01:28.280 --> 00:01:30.660
Saya Mirko Peters dari M365-FM

00:01:30.660 --> 00:01:34.360
dan potongan informasi ini akan mengupas Dynamics 365 Commerce dalam bahasa yang sederhana.

00:01:35.120 --> 00:01:36.780
Bayangkan bisnis Ritus sebagai sebuah gedung perkantong.

00:01:37.200 --> 00:01:39.340
Situs web dan toko fisik adalah pintu masuk yang berbeda.

00:01:39.600 --> 00:01:42.220
Tetapi di balik layar, semuanya harus mengarah ke ruang yang sama dan terhubung.

00:01:42.760 --> 00:01:44.740
Jadi apa sebenarnya Dynamics 365 Commerce itu?

00:01:46.850 --> 00:01:47.410
Apa sebenarnya?

00:01:48.670 --> 00:01:51.630
Dynamics 365 Commerce itu...

00:01:51.630 --> 00:01:53.090
Ini lah masalah yang dihadapi oleh retail.

00:01:53.810 --> 00:01:55.310
Anda memerlukan satu tampilan bersama.

00:01:55.310 --> 00:01:57.730
Mengenai dasar-dasarnya, produk apa yang Anda jual,

00:01:57.930 --> 00:01:59.370
berapa biayanya, di mana stok berada,

00:01:59.590 --> 00:02:00.810
pesan mana yang perlu ditindaklanjuti,

00:02:00.890 --> 00:02:02.190
dan apa yang telah dibeli pelanggan sebelumnya.

00:02:02.350 --> 00:02:03.270
Tanpa tampilan bersama itu,

00:02:03.390 --> 00:02:05.550
karyawan menghabiskan waktu seharian untuk memeriksa situs status.

00:02:05.770 --> 00:02:08.450
Oh, staf toko melihat satu harga situs web menampilkan harga lain,

00:02:08.630 --> 00:02:10.850
dan seseorang menjanjikan barang yang sebenarnya tidak tersedia.

00:02:11.330 --> 00:02:12.230
Tidak ada yang menyukai hal itu.

00:02:12.690 --> 00:02:16.130
Dynamics 365 Commerce menghubungkan pekerjaan di balik penjualan produk

00:02:16.130 --> 00:02:18.470
di seluruh toko, situs web, dan thinkback office.

00:02:18.930 --> 00:02:22.290
Ini memberi bisnis satu platform terhubung yang menangani semua yang dilihat pelanggan

00:02:22.290 --> 00:02:23.690
dan semua yang tidak mereka lihat.

00:02:24.170 --> 00:02:25.750
Sekarang bahwa saya tidak menyebutnya sebagai pembuat situs web.

00:02:26.130 --> 00:02:29.330
Pembuat situs web membantu Anda membuat halaman yang dijelajahi orang secara daring,

00:02:29.530 --> 00:02:31.990
dan sistem kasir membantu seseorang menerima pembayaran di kontor.

00:02:32.750 --> 00:02:35.030
Dynamics 365 Commerce dapat mendukung keduanya,

00:02:35.270 --> 00:02:37.810
tetapi juga menghubungkannya ke detail produk, stok, harga,

00:02:38.130 --> 00:02:41.690
data pelanggan pesanan, dan pekerjaan bisnis yang lebih luas di belakangnya.

00:02:42.350 --> 00:02:44.090
Koneksi bersama itu mengubah percakapan.

00:02:44.830 --> 00:02:47.190
Alih-alih bertanya sistem mana yang memiliki jawaban yang tepat.

00:02:47.190 --> 00:02:49.250
Tim Anda bekerja dari informasi bisnis yang sama

00:02:49.250 --> 00:02:51.390
meskipun pelanggan masuk melalui pintu yang berbeda.

00:02:52.290 --> 00:02:54.510
Commerce berkembang dari Dynamics 365 Retail

00:02:54.510 --> 00:02:56.570
yang berfokus pada toko fisik dan titik penjualan,

00:02:56.730 --> 00:02:59.690
tetapi Microsoft memperluasnya karena belanja tidak lagi terpaku di satu tempat.

00:03:00.450 --> 00:03:02.890
Seseorang mungkin melihat produk secara daring saat makan siang,

00:03:03.130 --> 00:03:04.330
mengunjungi toko setelah pulang kerja,

00:03:04.570 --> 00:03:06.050
dan meminta bantuan layanan pelanggantinya.

00:03:06.630 --> 00:03:07.910
Pembelian dapat berpindah antar saluran,

00:03:08.010 --> 00:03:09.810
sementara bisnis tetap menyimpan catatan yang sama.

00:03:10.390 --> 00:03:11.450
Bayangkan kembali gedung kantor itu.

00:03:12.010 --> 00:03:13.570
Oh, toko fisik adalah satu pintu masuk,

00:03:13.730 --> 00:03:14.890
toko daring ada pintu lainnya,

00:03:14.890 --> 00:03:16.790
dan pusat panggilan bisa menjadi pintu lainnya.

00:03:17.590 --> 00:03:18.490
Di balik setiap pintu,

00:03:18.690 --> 00:03:20.370
Commerce menghubungkan orang ke ruang bersama

00:03:20.370 --> 00:03:22.910
untuk produk, harga, stok, pesanan, dan pelanggan.

00:03:23.370 --> 00:03:25.430
Itu tidak berarti setiap bisnis berjalan dengan cara yang bersisak.

00:03:25.910 --> 00:03:27.510
Pengecar dapat mengatur rangkaian produk,

00:03:27.670 --> 00:03:29.610
harga, dan promosi untuk saluran yang dijalankannya,

00:03:29.810 --> 00:03:31.650
sementara tim kantor belakang mengelola aturan bisnis.

00:03:32.370 --> 00:03:34.710
Pekerja toko dan pembeli daring kemudian menggunakan aturan tersebut

00:03:34.710 --> 00:03:36.190
melalui layar yang dirancang untuk pekerja merek.

00:03:36.790 --> 00:03:39.550
Commerce juga terhubung dengan aplikasi Dynamics 365 Microsoft

00:03:39.550 --> 00:03:40.530
dan layanan Microsoft.

00:03:40.530 --> 00:03:43.910
Oh, manajemen rantai pasokan menangani produk,

00:03:44.050 --> 00:03:46.230
inventaris, gudang transportasi, dan distribusi.

00:03:47.170 --> 00:03:48.590
Keluangan mengelola sisi finansial

00:03:48.590 --> 00:03:49.890
dari aktivitas toko dan daring.

00:03:50.250 --> 00:03:52.630
Dan Dataverse membantu aplikasi bisnis berbagi informasi.

00:03:53.650 --> 00:03:54.930
Setiap aplikasi memiliki tugasnya sendiri,

00:03:55.070 --> 00:03:56.750
tetapi Commerce menghubungkan aktivitas penjualan

00:03:56.750 --> 00:03:57.570
ke sisa bisnis lainnya.

00:03:57.830 --> 00:03:59.870
Sekarang, mari ikuti satu pembelian melalui gedung itu,

00:03:59.990 --> 00:04:01.930
karena disitulah hal ini menjadi jauh lebih mudah untuk dilihat.

00:04:03.630 --> 00:04:05.290
Satu perjalanan pelanggan di seluruh saluran.

00:04:06.890 --> 00:04:07.890
Selamat datang di episode lainnya.

00:04:07.990 --> 00:04:10.690
Hari ini, kita akan membahas perjalanan pelanggan di seluruh saluran.

00:04:11.030 --> 00:04:11.350
Beritahu.

00:04:11.650 --> 00:04:13.010
Bayangkan Maya sedang mencari jaket.

00:04:13.410 --> 00:04:15.070
Dia membuka situs web pengajar di ponselnya,

00:04:15.370 --> 00:04:17.010
menemukan warna dan ukuran yang diinginkannya,

00:04:17.010 --> 00:04:18.710
serta memiksa apakah toko terdekat memiliki stok

00:04:18.710 --> 00:04:19.950
sebelum diinginkan warna.

00:04:20.530 --> 00:04:21.710
Jawaban mengenai stok itu harus tepat.

00:04:22.730 --> 00:04:23.890
Jika situs mengatakan tersedia,

00:04:24.050 --> 00:04:24.810
rak toko harus memiliki.

00:04:25.710 --> 00:04:28.190
Dynamics 365 Commerce menghubungkan toko daring

00:04:28.190 --> 00:04:30.090
ke stok waktu nyata dari toko dan gudang.

00:04:30.690 --> 00:04:33.230
Jadi, pelanggan melihat apa yang sebenarnya dapat dijanjikan oleh bisnis

00:04:33.230 --> 00:04:34.730
daripada setiap produk dalam katalog.

00:04:35.170 --> 00:04:36.870
Sebuah jaket mungkin muncul dalam daftar produk,

00:04:37.010 --> 00:04:38.910
tetapi itu tidak berarti jaket tersebut ada di rak terdekat.

00:04:39.350 --> 00:04:41.370
Ketika Maya melihat ukurannya tersedia untuk diambil,

00:04:41.490 --> 00:04:43.650
dia melakukan pemesanan secara daring dan mengambilnya di toko.

00:04:44.030 --> 00:04:45.350
Jika cabang lokal tidak menyediakannya,

00:04:47.010 --> 00:04:49.250
bisnis tersebut bahkan bisa mengirim jaketnya

00:04:49.250 --> 00:04:50.490
dari toko lain yang memiliki stoknya.

00:04:50.910 --> 00:04:52.910
Bagi Maya, pilihan itu muncul saat proses check-out.

00:04:53.390 --> 00:04:54.850
Di balik layar, bisnis perlu tahu persis

00:04:54.850 --> 00:04:56.950
di mana barang itu berada, lokasi mana yang bisa menyiapkannya,

00:04:57.090 --> 00:04:58.750
dan seberapa cepat barang sampai ke tangannya.

00:04:59.330 --> 00:05:01.770
Toko bukan lagi sekadar tempat orang datang dan membeli barang.

00:05:02.210 --> 00:05:03.530
Toko bisa menyiapkan pesanan online,

00:05:03.650 --> 00:05:05.750
menyimpan pesanan untuk diambil, dan mengirimkan barang ke pelang.

00:05:06.170 --> 00:05:08.250
Itu memberikan pembeli lebih banyak cara untuk membeli

00:05:08.250 --> 00:05:10.510
tanpa harus memahami cara peritel mengelola stoknya.

00:05:11.190 --> 00:05:12.090
Nah, di sini ada bagian yang menat.

00:05:12.790 --> 00:05:14.270
Katakanlah Maya mengambil jaket itu,

00:05:14.270 --> 00:05:15.750
membawanya pulang lalu berubah pikiran.

00:05:16.550 --> 00:05:18.210
Beberapa hari kemudian, dia mengunjungi cabang lain

00:05:18.210 --> 00:05:19.230
dan ingin mengembalikannya di sana.

00:05:19.950 --> 00:05:22.170
Staff seharusnya bisa menemukan pesanan online asli,

00:05:22.470 --> 00:05:23.450
melihat apa yang dibeli Maya,

00:05:23.630 --> 00:05:25.210
dan memproses pengembalian tanpa memintanya

00:05:25.210 --> 00:05:26.470
menghubungi situs web terlebih dahulu.

00:05:27.010 --> 00:05:28.990
Catatan pesanan dan pelanggan menyertai pembelian tersebut,

00:05:29.090 --> 00:05:30.490
meskipun penjualan dimulai secara online

00:05:30.490 --> 00:05:32.190
dan pengembalian dilakukan di toko yang berbeda.

00:05:32.690 --> 00:05:34.390
Hal itu menghilangkan salah satu rasa frustrasi

00:05:34.390 --> 00:05:35.210
paling umum dalam retail,

00:05:35.430 --> 00:05:37.470
yaitu saat diberitahu bahwa barang tersebut berasal dari sistem inder.

00:05:37.470 --> 00:05:39.450
Ada momen berguna lainnya di kontor toko juga.

00:05:40.170 --> 00:05:41.910
Maya mengunjungi cabang untuk mencoba sepatu,

00:05:42.190 --> 00:05:43.170
menemukan pasang yang tepat,

00:05:43.250 --> 00:05:45.070
namun ukurannya ternyata habis di lokasi tersebut.

00:05:45.330 --> 00:05:46.910
Toko yang tidak terhubung hanya bisa mengangkat bahu

00:05:46.910 --> 00:05:47.830
dan menyuruhnya pergi ke tempat.

00:05:48.170 --> 00:05:49.610
Dengan pendekatan lorong tanpa batas,

00:05:49.810 --> 00:05:51.690
kerja toko bisa melihat melampaui rak toko tersebut.

00:05:52.370 --> 00:05:54.370
Mereka bisa memeriksa stok di toko atau gudang lain,

00:05:54.510 --> 00:05:55.490
membuat pesanan untuk Maya,

00:05:55.610 --> 00:05:56.850
dan mengatur pengiriman ke rumahnya

00:05:56.850 --> 00:05:58.390
atau pengambilan di lokasi yang nyaman baginya.

00:05:59.550 --> 00:06:00.850
Rak fisik bukan lagi batasan penuh

00:06:00.850 --> 00:06:02.170
dari apa yang bisa dijual oleh toko.

00:06:02.750 --> 00:06:03.410
Tentu saja,

00:06:03.410 --> 00:06:04.670
seseorang tetap harus memutuskan

00:06:04.670 --> 00:06:05.930
dari mana setiap pesanan serus berhasil.

00:06:06.350 --> 00:06:08.650
Jika beberapa toko dan gudang memiliki sepatu yang sama,

00:06:08.850 --> 00:06:09.950
mengirimnya dari tempat yang salah

00:06:09.950 --> 00:06:10.810
bisa menambah biaya,

00:06:10.970 --> 00:06:11.750
memperlambat pengiriman,

00:06:11.850 --> 00:06:13.150
atau membuat stok toko lokal nipis.

00:06:13.810 --> 00:06:15.030
Dynamics 365 Commerce

00:06:15.030 --> 00:06:16.310
menyertakan manajemen pesanan

00:06:16.310 --> 00:06:17.530
terdistribusi untuk tugas ini.

00:06:18.130 --> 00:06:18.810
Secara sederhana,

00:06:18.930 --> 00:06:20.150
sistem ini menggunakan aturan bisnis

00:06:20.150 --> 00:06:21.190
untuk memilih tempat yang tepat

00:06:21.190 --> 00:06:21.970
guna memenuhi pesanan

00:06:21.970 --> 00:06:23.450
berdasarkan pilihan yang ditetapkan berita.

00:06:23.890 --> 00:06:25.150
Aturan tersebut memperhitungkan

00:06:25.150 --> 00:06:25.870
stok yang tersedia,

00:06:25.870 --> 00:06:28.430
dan tempat yang dapat memenuhi pesanan tersebut.

00:06:28.430 --> 00:06:29.830
Jadi, pesanan tidak hanya masuk

00:06:29.830 --> 00:06:30.550
ke satu antrean besar

00:06:30.550 --> 00:06:31.210
yang menunggu seseorang

00:06:31.210 --> 00:06:32.210
untuk melihat apa yang harus dilakukan.

00:06:32.570 --> 00:06:34.190
Sistem mengarahkannya ke toko atau gudang

00:06:34.190 --> 00:06:35.210
yang sesuai dengan aturan peritel

00:06:35.210 --> 00:06:36.410
sementara staf melangani pekerjaan

00:06:36.410 --> 00:06:37.550
pengambilan, pengemasan, penjemputan,

00:06:37.630 --> 00:06:38.470
atau pengiriman yang sebenarnya.

00:06:38.710 --> 00:06:39.470
Tentu pengiriman yang sebenarnya.

00:06:39.710 --> 00:06:40.910
Maya hanya melihat pilihan sederhana,

00:06:41.190 --> 00:06:42.070
pengambilan atau pengiriman.

00:06:42.750 --> 00:06:43.890
Pengecar melihat serangkaian

00:06:43.890 --> 00:06:45.530
keputusan terhubung yang harus terjaga

00:06:45.530 --> 00:06:46.870
sejak pencarian produk pertama

00:06:46.870 --> 00:06:48.050
hingga pengembalian terakhir.

00:06:48.650 --> 00:06:50.170
Perjalanan pelanggan itu hanya berhasil

00:06:50.170 --> 00:06:51.170
jika orang-orang di toko

00:06:51.170 --> 00:06:53.010
bisa bertindak berdasarkan informasi yang sama

00:06:53.010 --> 00:06:54.370
dan mereka membutuhkan alat

00:06:54.370 --> 00:06:56.550
untuk kasir, lantai toko, dan ruang stok.

00:06:58.790 --> 00:07:00.270
Toko fisik, perdagangan toko,

00:07:00.390 --> 00:07:01.250
dan titik penjualan.

00:07:02.090 --> 00:07:03.650
Di kasir, staf membutuhkan jawaban cepat.

00:07:04.230 --> 00:07:05.450
Mereka tidak bisa menghentikan pelanggan

00:07:05.450 --> 00:07:07.110
saat berbelanja untuk membuka beberapa sistem

00:07:07.110 --> 00:07:07.710
dan mencari pesanan

00:07:07.710 --> 00:07:09.210
sementara antrean memanjang di belakang mereka.

00:07:09.590 --> 00:07:10.610
Mereka butuh satu layar

00:07:10.610 --> 00:07:11.750
yang memungkinkan mereka menjual,

00:07:11.870 --> 00:07:13.010
mengembalikan, memeriksa stok,

00:07:13.210 --> 00:07:14.570
dan membantu orang yang berdiri di sana.

00:07:15.070 --> 00:07:16.430
Alat itu adalah aplikasi Store Commerce.

00:07:17.090 --> 00:07:18.890
Store Commerce adalah aplikasi titik penjualan,

00:07:19.010 --> 00:07:20.250
sering disingkat aplikasi POS

00:07:22.610 --> 00:07:24.530
Kasir menggunakannya di meja tetap,

00:07:24.630 --> 00:07:26.410
dan staf penjualan membawanya di perangkat seluler

00:07:26.410 --> 00:07:28.330
untuk membantu pelanggan dimanapun mereka berada.

00:07:29.090 --> 00:07:30.130
Aplikasi yang sama dapat berjalan

00:07:30.130 --> 00:07:31.290
di komputer desktop, tablet, ataupun.

00:07:31.790 --> 00:07:34.090
Aplikasi ini berfungsi di Windows, iOS, Android, dan macOS.

00:07:34.390 --> 00:07:35.810
Hal itu memberikan fleksibilitas bagi pengajar.

00:07:36.130 --> 00:07:38.170
Toko besar mungkin menggunakan meja kasir tradisional.

00:07:38.810 --> 00:07:40.150
Toko yang lebih kecil mungkin menggunakan tablet.

00:07:41.030 --> 00:07:41.830
Namun bagaimanapun,

00:07:41.910 --> 00:07:43.410
penjualan tetaplah jenis transaksi yang sama.

00:07:44.090 --> 00:07:45.190
Bayangkan ini seorang staf penjualan

00:07:45.190 --> 00:07:46.150
berada di dekat MyLensport.

00:07:46.790 --> 00:07:48.150
My bertanya apakah ukurannya tersedia.

00:07:48.150 --> 00:07:49.250
Staf mencari,

00:07:49.530 --> 00:07:50.090
memeriksa stok,

00:07:50.410 --> 00:07:51.010
menemukan barang,

00:07:51.330 --> 00:07:52.490
dan menyelesaikan pembelian di sana.

00:07:53.130 --> 00:07:54.670
Jika Maya ingin mengembalikan sesuatu,

00:07:54.850 --> 00:07:56.890
staf dapat menemukan catatan pelanggan atau pesanannya

00:07:56.890 --> 00:07:58.730
dan memulai pengembalian dari alat yang sama.

00:07:59.430 --> 00:08:00.110
Hal yang wajar bukan,

00:08:00.110 --> 00:08:01.950
namun semuanya bergantung pada informasi yang baik.

00:08:02.470 --> 00:08:04.350
Storcomers mendukung penjualan langsung pencari pelanggan,

00:08:04.630 --> 00:08:06.050
pemeriksaan inventaris pengerjaan pesanan,

00:08:06.150 --> 00:08:07.410
pengembalian, dan pelaporan.

00:08:08.030 --> 00:08:09.970
Staf toko juga bisa mengolah hal-hal seputar penjualan

00:08:09.970 --> 00:08:11.770
seperti giliran kerja dan manajemen kas

00:08:11.770 --> 00:08:14.330
daripada hanya menganggap kasir sebagai mesin pembayaran saja.

00:08:14.330 --> 00:08:17.150
Titik penjualan menjadi alat kerja untuk seluruh toko.

00:08:17.810 --> 00:08:18.810
Kualitas koneksi juga penting.

00:08:19.430 --> 00:08:20.930
Internet tidak selalu sempurna di toko,

00:08:21.070 --> 00:08:22.090
terutama di bangunan besar,

00:08:22.250 --> 00:08:22.990
lokasi terpencil,

00:08:23.130 --> 00:08:24.970
atau tempat dengan jaringan yang sering terputus.

00:08:25.510 --> 00:08:26.410
Commerce berjalan di cloud,

00:08:26.410 --> 00:08:29.010
tetapi juga dapat menggunakan pengaturan ads yang lebih dekat ke toko

00:08:29.010 --> 00:08:30.970
sehingga pengecer bisa merencanakan sesuai kondisi lokal.

00:08:31.210 --> 00:08:32.850
Pelanggan tetap mengharapkan kasir berfungsi dengan baik.

00:08:33.370 --> 00:08:36.230
Itu tidak berarti staf toko harus memahami sistem cloud atau desain jaringan.

00:08:36.610 --> 00:08:38.490
Mereka membuka aplikasi mengikuti langkah-langkah

00:08:38.490 --> 00:08:39.870
sesuai peran mereka dan membantepan.

00:08:40.210 --> 00:08:40.830
Di balik layar,

00:08:40.830 --> 00:08:44.330
pengacir memilih pengaturan yang membuat toko tetap beroperasi saat konektivitas berubah.

00:08:44.650 --> 00:08:46.170
Layar berbasis peran membuat hal itu berat.

00:08:46.550 --> 00:08:48.990
Seorang kasir membutuhkan cara sederhana untuk memproses penjualan.

00:08:49.070 --> 00:08:50.530
Manager toko membutuhkan opsi yang berbeda.

00:08:50.790 --> 00:08:52.150
Bekerja stok membutuhkan informasi produk.

00:08:52.330 --> 00:08:54.890
Commerce dapat menyesuaikan pengalaman untuk setiap peran alih-alih

00:08:54.890 --> 00:08:56.290
menampilkan semua tombol kepada semua orang.

00:08:56.710 --> 00:08:57.490
Ini poin kuncinya.

00:08:57.890 --> 00:09:00.790
Penjualan di toko mengikuti aturan bisnis yang sama dengan penjualan online.

00:09:01.490 --> 00:09:04.150
Harga, detail produk, info pelanggan, dan catatan pesanan

00:09:04.150 --> 00:09:06.590
tidak memerlukan aturan berbeda untuk situs web dan lantai toko.

00:09:07.490 --> 00:09:08.450
Staff menggunakan store commerce.

00:09:08.450 --> 00:09:11.910
Pembeli menggunakan storefront, tetapi keduanya mengambil data dari kondisi commerce yang sama.

00:09:12.630 --> 00:09:14.370
Hal itu menjaga pengalaman tetap konsisten

00:09:14.370 --> 00:09:16.470
dan staff tidak perlu mengingat banyak pengecualian.

00:09:17.110 --> 00:09:19.390
Jadi toko fisik menjadi lebih dari sekadar rak dan mesin kasir.

00:09:19.830 --> 00:09:21.550
Toko menjadi bagian terhubung dari seluruh operasi

00:09:21.550 --> 00:09:25.670
di mana staff dapat membantu pelanggan membeli, mengambil, mengembalikan, atau memesan produk.

00:09:25.910 --> 00:09:28.770
Mengembalikan atau memesan produk menggunakan informasi yang sudah dikelola bisnis.

00:09:29.490 --> 00:09:32.030
Namun semua layar staff tersebut memerlukan otak bersama dibanding.

00:09:32.590 --> 00:09:35.490
Satu tempat yang menangani produk, pesanan, dan harga sebelum layar.

00:09:35.490 --> 00:09:36.930
Mana pun meminta jawaban.

00:09:38.450 --> 00:09:39.370
Mesin dibalik storefront.

00:09:40.230 --> 00:09:43.290
Jadi otak bersama yang saya bicarakan tadi bernama Commerce Scale Unit.

00:09:43.850 --> 00:09:46.050
Terdengar teknis, tetapi bayangkan sebagai ruang mesin

00:09:46.050 --> 00:09:48.370
yang menjalankan setiap aturan penjualan dibalik saluran pengecualian.

00:09:48.850 --> 00:09:51.230
Baik pelanggan membeli melalui situs web, aplikasi toko,

00:09:51.390 --> 00:09:53.270
atau aplikasi belanja khusus yang dibuat bisnis,

00:09:53.470 --> 00:09:55.070
mesin ini menangani setiap permintaan.

00:09:55.590 --> 00:09:56.470
Pelanggan tidak pernah melihatnya.

00:09:56.830 --> 00:09:59.810
Mereka melihat halaman produk, layar check-out, atau perangkat pekerja penjualan.

00:10:00.370 --> 00:10:03.690
Di balik layar, Commerce Scale Unit mengambil permintaan yang dikirim layar tersebut

00:10:03.690 --> 00:10:06.610
dan menerapkan aturan perdagangan yang sama dimanapun orang membeli.

00:10:07.150 --> 00:10:08.270
Satu rangka logika untuk saya bersalut.

00:10:08.610 --> 00:10:09.270
Itulah keajaibannya.

00:10:09.690 --> 00:10:10.810
Ini membawa kita ke Headless Commerce.

00:10:11.410 --> 00:10:14.590
Headless secara sederhana berarti mesin penjualan terpisah dari layar yang dilihat orang.

00:10:15.290 --> 00:10:17.770
Mesin tersebut tidak peduli apakah pelanggan menggunakan situs web,

00:10:17.850 --> 00:10:20.290
aplikasi ponsel, kioswalayan, atau tablet pekerja toko.

00:10:20.290 --> 00:10:24.110
Ia menerima permintaan menjalankan aturan bisnis dan mengirimkan kembali jawaban.

00:10:24.790 --> 00:10:29.070
Layar adalah wajahnya, Commerce Scale Unit adalah bagian kerja dibalik wajah tersebut.

00:10:29.770 --> 00:10:31.330
Perhatikan saya tidak mengatakan layar tidak melakukan apa.

00:10:32.050 --> 00:10:34.630
Oh, layar melakukan banyak hal, tetapi logikanya tetap terpisah.

00:10:35.110 --> 00:10:38.410
Memisahkan keduanya memungkinkan pengecer mengubah atau membangun pengalaman pelanggan

00:10:38.410 --> 00:10:42.470
tanpa harus membangun ulang semua aturan untuk produk, harga, stok, promosi, dan pesanan setiap saat.

00:10:42.870 --> 00:10:44.790
Bayangkan seorang pengecer muncurkan aplikasi seller.

00:10:45.290 --> 00:10:48.230
Tanpa pendekatan ini, tim mungkin perlu membangun ulang logika

00:10:48.230 --> 00:10:52.030
yang memeriksa ketersediaan produk, menghitung harga, mendapatkan diskon, dan membuat pesanan.

00:10:52.710 --> 00:10:55.530
Dengan Commerce, aplikasi baru dapat langsung terhubung ke mesin yang sama

00:10:55.530 --> 00:10:57.790
yang sudah digunakan oleh toko online dan aplikasi Storkom.

00:10:58.110 --> 00:11:00.270
Satu rangkaian aturan mendukung banyak pengalaman pelanggan.

00:11:00.730 --> 00:11:02.750
Itulah intinya, dan inilah alasan mengapa itu penting.

00:11:03.430 --> 00:11:06.050
Pelanggan tidak peduli sistem teknis mana yang menjawab pertanyaan mereka.

00:11:07.030 --> 00:11:09.850
Mereka peduli bahwa harga di ponsel mereka sama dengan harga di toko,

00:11:09.970 --> 00:11:12.050
dan barang yang tersedia memang benar-benar bisa dipesan.

00:11:12.530 --> 00:11:15.490
Koneksi antara layar dan unit skala niaga bekerja melalui API

00:11:15.490 --> 00:11:18.250
adalah singkatan dari Application Programming Interface,

00:11:18.650 --> 00:11:20.030
tapi Anda tidak perlu menghafal kepanjangannya.

00:11:20.590 --> 00:11:22.250
Bayangkan sebuah loket layanan di toko besar.

00:11:23.130 --> 00:11:24.550
Sebuah situs web bertanya ke loket tersebut,

00:11:24.850 --> 00:11:25.750
berapa harga barang ini?

00:11:26.730 --> 00:11:28.930
Loket tersebut memeriksa aturan niaga yang memberikan harganya.

00:11:29.550 --> 00:11:30.650
Permintaan lain mungkin bertanya,

00:11:30.810 --> 00:11:32.730
bisakah pelanggan ini memesan barang ini untuk diambil?

00:11:33.310 --> 00:11:35.350
Atau tolong buatkan pesanan untuk produk berikut ini?

00:11:35.950 --> 00:11:39.450
API membawa permintaan tersebut di antara layar pelanggan dan mesin niaga.

00:11:40.430 --> 00:11:43.930
Situs web tidak perlu tahu bagaimana harga atau pesanan bekerja di balik layar,

00:11:43.930 --> 00:11:45.970
ia hanya meminta hasil melalui loket,

00:11:46.450 --> 00:11:49.410
dan unit skala niaga menerapkan aturan peritel sebelum menjawab.

00:11:50.090 --> 00:11:53.530
Pengaturan itu juga memberi bisnis ruang untuk membangun sesuatu di luar etalase standar.

00:11:54.090 --> 00:11:56.290
Mereka bisa menciptakan pengalaman belanja di dalam aplikasi sendiri.

00:11:56.770 --> 00:11:58.370
Mitra bisa membangun saluran penjualan lain.

00:11:58.930 --> 00:12:00.690
Mesin niaga yang sama dapat mendukung pengalaman tersebut,

00:12:00.930 --> 00:12:02.830
sehingga bisnis tidak perlu memulai dari awal

00:12:02.830 --> 00:12:05.250
dengan aturan penjualan yang berbeda setiap kali membuka peluang baru.

00:12:06.330 --> 00:12:09.350
Ini Dynamics 365 Commerce juga hadir dengan etalase niaganya sendiri.

00:12:09.730 --> 00:12:12.170
Itu adalah sistem situs web yang dilihat dan diklik oleh pelanggan

00:12:12.170 --> 00:12:16.110
melalui informasi produk, gambar, menu, hasil pencarian, dan langkah pembayaran kami.

00:12:17.050 --> 00:12:19.310
Ini menggunakan react, kerangka kerja, pengembangan web

00:12:19.310 --> 00:12:21.370
yang membantu tim membangun halaman web interaktif.

00:12:21.990 --> 00:12:24.450
Anda tidak perlu menjadi pengembang web untuk memahami bagian praktis.

00:12:25.170 --> 00:12:27.370
Etalase dapat menyiapkan bagian halaman di server

00:12:27.370 --> 00:12:28.790
sebelum mencapai peramban pelanggan,

00:12:29.190 --> 00:12:31.170
dan juga dapat memperbarui bagian halaman di peramban

00:12:31.170 --> 00:12:33.090
saat pelanggan mengeklik, mencari, memfilter,

00:12:33.250 --> 00:12:34.590
atau menambahkan produk ke keranjang.

00:12:36.250 --> 00:12:38.090
Kombinasi tersebut membantu situs memuat halaman

00:12:38.090 --> 00:12:39.670
dan merespons tindakan pelanggan dengan cepat.

00:12:39.670 --> 00:12:41.790
Peritel juga bisa menggunakan site builder,

00:12:42.090 --> 00:12:44.930
alat berbasis web bagi mereka yang mengelola halaman dan konten pemasar.

00:12:45.290 --> 00:12:47.070
Mereka dapat mengerjakan situs yang menghadap pelanggan

00:12:47.070 --> 00:12:49.110
tanpa mengubah mesin niaga yang menangani permintaan produk,

00:12:49.270 --> 00:12:50.570
harga, dan pesanan di belakangnya.

00:12:51.250 --> 00:12:53.110
Situs dan mesin tersebut memiliki tugas berbeda,

00:12:53.190 --> 00:12:55.430
tetapi peritel tidak semuanya menjalankan toko dalam kondisi yang serba.

00:12:56.010 --> 00:12:57.810
Satu lokasi mungkin memiliki internet yang stabil

00:12:57.810 --> 00:12:59.490
dan bekerja dengan baik dengan layanan cloud,

00:12:59.770 --> 00:13:02.590
sementara lokasi lain berada di tempat dengan konektivitas lemah atau tidak stabil.

00:13:03.150 --> 00:13:04.090
Komers memperbedaan tersebut.

00:13:04.770 --> 00:13:06.710
Unit skala niaga dapat berjalan di cloud Microsoft,

00:13:06.850 --> 00:13:08.370
tempat Microsoft mengelola layanannya.

00:13:09.670 --> 00:13:17.750
Pilihan itu memungkinkan pengecer merencanakan

00:13:17.750 --> 00:13:19.230
berdasarkan cara kerja setiap lokasi,

00:13:19.350 --> 00:13:21.650
alih-alih memaksakan satu pengaturan teknis untuk setiap toko.

00:13:22.270 --> 00:13:25.670
Unit skala dapat menjaga logika niaga yang sama lebih dekat ke toko

00:13:25.670 --> 00:13:27.370
di mana akses internet mungkin bermasalah,

00:13:27.590 --> 00:13:30.910
sementara unit cloud mendukung saluran melalui wilayah Azure yang dikelola Microsoft.

00:13:32.070 --> 00:13:34.530
Staff toko tidak perlu memikirkan hal ini saat membantu pelanggan.

00:13:35.050 --> 00:13:36.350
Mereka menggunakan layar depan mereka,

00:13:36.350 --> 00:13:38.290
pembeli menggunakan situs web atau aplikasi depan mereka.

00:13:38.290 --> 00:13:42.630
Namun, setiap saluran bergantung pada ruang mesin yang merespons dengan informasi produk,

00:13:42.770 --> 00:13:45.130
harga, jawaban stok, dan tindakan pesanan yang tepat.

00:13:45.730 --> 00:13:48.950
Setelah penjualan mulai mengalir, informasinya juga harus tetap terhubung

00:13:48.950 --> 00:13:52.990
karena produk, catatan pelanggan, dan stok tidak bisa berada di laci yang terpisah.

00:13:54.050 --> 00:13:55.750
Data, loyalitas, dan pembelian yang lebih aman.

00:13:56.270 --> 00:13:58.550
Setiap kali Anda melakukan penjualan, Anda menciptakan informasi.

00:13:59.110 --> 00:14:01.470
Produk, harga, toko, pelanggan, detail pesanan Osmo-nya.

00:14:01.470 --> 00:14:04.970
Jika informasi itu tak tersebar, sebuah bisnis bisa berjualan sepanjang hari,

00:14:05.130 --> 00:14:07.110
namun masih kesulitan melihat apa yang sebenarnya dibeli orang.

00:14:07.910 --> 00:14:12.650
Dynamics 3NA, Commerce, menghubungkan data bisnis dengan Dataverse dan penyimpanan Azure Data Lake.

00:14:13.250 --> 00:14:16.370
Dataverse berfungsi seperti lemari arsi bisnis bersama untuk aplikasi bisnis Microsoft.

00:14:16.950 --> 00:14:21.130
Commerce, penjualan, dan layanan pelanggan dapat menggunakannya untuk menyimpan dan berbagi informasi bisnis,

00:14:21.290 --> 00:14:24.670
sehingga tim tidak perlu menyaling detail pelanggan atau akun yang sama antar alat yang berbeda.

00:14:25.390 --> 00:14:26.990
Hal itu menciptakan catatan pelanggan yang lebih jatuh.

00:14:26.990 --> 00:14:32.570
Gini masalahnya, pelanggan mungkin membeli dari situs web, berbicara dengan staf penjualan di toko lalu menghubungi dukungan di kemudian hari.

00:14:33.130 --> 00:14:35.510
Ketika aplikasi yang terhubung menggunakan informasi bersama,

00:14:35.710 --> 00:14:39.310
setiap tim dapat bekerja dari detail pelanggan yang sama alih-alih memulai percakapan dari awal.

00:14:40.230 --> 00:14:42.590
Penyimpanan Azure Data Lake menangani jenis pekerjaan yang berbeda.

00:14:43.210 --> 00:14:45.110
Bayangkan itu sebagai gudang besar untuk data bisnis.

00:14:45.790 --> 00:14:49.370
Commerce dapat mengirim data transaksi ke sana bersama dengan informasi dari toko daring,

00:14:49.550 --> 00:14:53.170
sehingga bisnis dapat mempelajari aktivitas dari waktu ke waktu alih-alih hanya melihat penjualan terakhir.

00:14:53.490 --> 00:14:56.010
Ini memberi tim lebih banyak ruang untuk mengajukan pertanyaan.

00:14:56.010 --> 00:14:58.050
Produk malang laris manis di toko tertentu.

00:14:58.570 --> 00:15:00.710
Kategori mana yang menghasilkan penjualan tetapi marginnya kecil?

00:15:01.130 --> 00:15:02.530
Saluran mana yang menghasilkan pesanan terbanyak?

00:15:03.010 --> 00:15:08.830
Laporan commerce dapat membantu manajer melihat seluruh produk, kategori, kategori, karyawan, terminal, toko, dan saluran penjualan.

00:15:09.390 --> 00:15:12.350
Staff toko juga dapat melihat laporan yang terhubung ke titik penjualan,

00:15:12.650 --> 00:15:16.510
sementara orang di kantor belakang dapat meninjau aktivitas di seluruh bisnis setelah data disinkronkan.

00:15:17.030 --> 00:15:18.630
Laporan tersebut tidak menjalankan toko untuk shop.

00:15:18.870 --> 00:15:21.930
Hal ini memberikan pandangan yang lebih jelas tentang apa yang terjadi,

00:15:21.930 --> 00:15:25.530
sehingga manajer dapat melihat pola sebelum memutuskan perubahan stok, harga, atau promosi.

00:15:26.890 --> 00:15:28.650
Loyalitas pelanggan berada yang saling terhubung ini.

00:15:29.310 --> 00:15:32.330
Pengejar dapat membuat program loyalitas di mana setiap pembelian mendapatkan poin.

00:15:32.890 --> 00:15:38.030
Pelanggan nantinya dapat menukarkan poin tersebut untuk pembelian di masa mendatang baik di toko, daring, atau keduanya.

00:15:38.710 --> 00:15:41.110
Hal itu mengubah pembelian sederhana menjadi hubungan yang berkelanjut.

00:15:41.110 --> 00:15:43.610
Ketika pelanggan memilih untuk mengidentifikasi diri,

00:15:43.810 --> 00:15:46.490
commerce juga dapat membawa riwayat pembelian mereka ke dalam percakapan.

00:15:46.910 --> 00:15:51.790
Staff penjualan mungkin melihat informasi yang membantu mereka menjelaskan dengan lebih jelas apa yang pernah dibeli orang tersebut sebelumnya,

00:15:51.910 --> 00:15:54.790
sementara toko daring dapat menampilkan rekomendasi produk berdasarkan pola pembelian.

00:15:55.830 --> 00:15:57.490
Rekomendasi tidak membaca pikiran pelanggan.

00:15:58.090 --> 00:16:01.770
Rekomendasi menggunakan informasi belanja dan pembelian untuk menyarankan parang yang mungkin ingin diletakkan.

00:16:02.290 --> 00:16:04.590
Hal itu dapat membantu orang menemukan produk terkait,

00:16:04.590 --> 00:16:08.890
tetapi pengejar tetap membutuhkan data produk yang masuk akal dan pengalaman belanja yang menghargai pelanggan.

00:16:09.730 --> 00:16:10.870
Ulasan daring juga perlu diperhatikan.

00:16:11.370 --> 00:16:13.970
Commerce menyertakan peringkat dan ulasan untuk etalase e-commerce,

00:16:14.110 --> 00:16:18.790
sehingga pelanggan dapat memberikan masukan dan pengejar dapat menampilkan peringkat di halaman produk,

00:16:19.070 --> 00:16:19.250
ROG.

00:16:19.870 --> 00:16:23.750
Azure Cognitive Services dapat secara otomatis menyaring kata-kata kasar dalam 40 bahasa,

00:16:24.070 --> 00:16:26.590
dan pengejar juga memiliki alat moderator untuk menangani masalah,

00:16:26.750 --> 00:16:29.550
masukan, permintaan penghapusan, dan permintaan data.

00:16:30.150 --> 00:16:32.010
Sistem ulasan membutuhkan lebih dari sekadar skor bintang.

00:16:32.250 --> 00:16:36.710
Sistem ini membutuhkan cara agar halaman produk tetap berguna tanpa membiarkan setiap masalah ditemukan secara nelap.

00:16:37.030 --> 00:16:40.830
Penipuan pembayaran menciptakan kekhawatiran lain, terutama saat pesanan masuk melalui saluran digital.

00:16:41.570 --> 00:16:46.130
Dynamics 365 Fraud Protection dapat terhubung dengan commerce untuk mendukung keputusan penipuan secara otomatis.

00:16:46.610 --> 00:16:49.350
Layanan ini menggunakan informasi dari jaringan perlindungan penipuan,

00:16:49.470 --> 00:16:52.810
sinyal perangkat, dan aturan yang ditetapkan oleh bisnis untuk membantu menilai transaksi.

00:16:53.130 --> 00:16:54.510
Tidak ada perangkat lunak yang menghapus semua risiko.

00:16:54.870 --> 00:16:58.190
Pengejar tetap membutuhkan kebijakan yang jelas dan orang yang dapat menangani pengecualian.

00:16:58.370 --> 00:17:01.210
Tetapi alat penipuan yang terhubung dapat membantu bisnis meninjau pesanan daring

00:17:01.210 --> 00:17:03.150
tanpa memperlakukan setiap pelanggan sebagai masalah.

00:17:03.150 --> 00:17:07.870
Jadi, commerce menyatukan data penjualan, loyalitas pelanggan, ulasan, dan pemeriksaan penipuan di sekitar pembelian.

00:17:08.330 --> 00:17:09.570
Itu mungkin terdengar banyak karena memang demikian.

00:17:09.910 --> 00:17:11.030
Pertanyaan berikutnya lebih sederhana.

00:17:11.330 --> 00:17:13.250
Bisnis mana yang benar-benar membutuhkan platform ini?

00:17:13.530 --> 00:17:15.210
Dan pekerjaan apa yang masih diserahkan kepada manusia?

00:17:16.550 --> 00:17:19.190
Siapa yang menggunakan commerce dan apa yang tidak digantikannya?

00:17:19.890 --> 00:17:22.390
Bayangkan sebuah merk pakaian dengan toko fisik dan situs webnya sendiri.

00:17:23.050 --> 00:17:27.450
Bisnis tersebut membutuhkan informasi produk, harga, jumlah stok, dan detail pesanan yang sama di kedua tempat.

00:17:27.450 --> 00:17:31.710
Dynamic Stigran temelima commerce menghubungkan semua sabaran tersebut sehingga semuanya tetap konsisten.

00:17:32.250 --> 00:17:34.150
Oh, tidak perlu lagi saling mengirim lembar sebar melalui Surreal.

00:17:34.590 --> 00:17:36.090
Apakah penting jika Anda menjalankan satu toko?

00:17:36.270 --> 00:17:36.950
Tidak juga.

00:17:37.750 --> 00:17:41.610
Yang terpenting adalah toko, situs web, dan tim kantor belakang menggunakan informasi bersama

00:17:41.610 --> 00:17:44.110
yang sama alih-alih saling mengirim pembaruan antar sistem yang terpisah.

00:17:44.430 --> 00:17:45.130
Itulah gas utamatin.

00:17:46.070 --> 00:17:49.350
Commerce juga berfungsi bagi produsen dan distributor yang menjual ke bisnis lain.

00:17:49.950 --> 00:17:53.770
Misalnya produsen memberi distributornya portal swalayan untuk memeriksa inventaris,

00:17:53.930 --> 00:17:56.070
melihat produk, dan melakukan pemasanan.

00:17:56.070 --> 00:18:00.770
Itu adalah commerce B2B team, dan commerce mendukung pengalaman belanja tersebut melalui API commerce-nya.

00:18:01.710 --> 00:18:04.230
Berhatikan bahwa pembelian bukan tim seorang pembelian datang langsung lagi.

00:18:05.170 --> 00:18:09.070
Bisa jadi sebuah perusahaan yang melakukan pesanan berulang memeriksa ketersediaan atau pengarga sendiri.

00:18:09.930 --> 00:18:11.490
Sekarang, apakah commerce menggantikan peran manusia?

00:18:12.290 --> 00:18:15.330
Tim kantor belakang tetap menangani pengaturan produk, harga, dan promosi,

00:18:15.670 --> 00:18:17.870
lacakan stok dan pesanan, serta laporan penjualan dan margin.

00:18:18.750 --> 00:18:20.530
Commerce memberi tim tersebut alat yang terhubung,

00:18:20.770 --> 00:18:23.870
namun bukan berarti sekarang Anda mengubah retail menjadi sistem yang berjalan sendiri.

00:18:24.190 --> 00:18:25.110
Anusia tetap penting.

00:18:25.110 --> 00:18:26.530
Kebanyakan orang mendengar,

00:18:26.630 --> 00:18:29.310
oh commerce, oh, dan berpikir itu hanya berarti membangun toko online.

00:18:29.770 --> 00:18:31.430
Toko online bisa menjadi bagian darinya.

00:18:31.590 --> 00:18:33.150
Namun commerce menjangkau jauh lebih dari itu,

00:18:33.230 --> 00:18:35.510
oh, hingga kemeja kasir, catatan pelanggan, program loyalitas,

00:18:35.590 --> 00:18:38.630
pengaturan produk, penangan pesanan, dan semua data di balik tugas-tugas tersebut.

00:18:39.930 --> 00:18:41.610
Ini tidak menggantikan gudang pekerja toko,

00:18:42.110 --> 00:18:42.910
kurir pengiriman Anda.

00:18:42.910 --> 00:18:44.330
Terima kasih.

00:18:44.330 --> 00:18:44.390
Terima kasih.

00:18:44.390 --> 00:18:44.650
Terima kasih.