Bagaimana kami menggergaji sistem helpdesk kami

Empat tahun lalu, tim dukungan teknis studio Plarium Krasnodar menggunakan sistem tiket pihak ketiga, yang memiliki banyak kekurangan. Saat ini kami tidak hanya memiliki sistem kami sendiri, tetapi juga meja bantuan yang disesuaikan dengan kebutuhan perusahaan. Bagaimana itu terjadi - baca artikelnya.







Jadi, apa yang kami hadapi sehingga kami berpikir untuk mengembangkan sistem tiket kami sendiri? Masalah utama:

1. Tim kami menerima 1–1,5 ribu klik dari pengguna setiap hari.
2. Statistik kenyamanan kurang. Semuanya harus dicatat secara manual dalam berbagai dokumen.
3. Kesulitan utama: sebagian besar permintaan memerlukan pemeriksaan status akun pemain, yang pada saat itu tidak dapat diakses secara langsung - kami hanya bekerja dengan teks permintaan itu sendiri dan alamat email.
4. Kompleksitas dan antarmuka yang dibuat. Solusi orang lain paling sering tidak nyaman, karena tidak disesuaikan untuk permainan tertentu dan peraturan dukungan teknis untuk perusahaan tertentu.
5. Mempertimbangkan semua hal di atas, membayar untuk sistem pihak ketiga tidak terlalu menguntungkan.

Dan kami membuat keputusan yang tepat waktu - untuk menghentikan sistem tiket kami sendiri! Apa? Ada kekuatan, ada banyak ide, antusiasme - lebih dari cukup. Namun pada saat itu tidak ada proses yang relevan: kami, tim pendukung, tidak pernah memesan apa pun dari tim pengembangan toolkit internal dan tidak berinteraksi secara dekat dengannya.



Mulai dari mana? Kami menulis dalam dua kolom harapan kami dari alat (sesuatu dengan gaya "kami ingin menerima pesan dan menanggapinya") dan keluhan tentang versi saat ini ("di sini adalah jendela yang tidak nyaman, membuatnya lebih nyaman"), menyebutnya tugas teknis dan meneruskannya kepada pengembang. Proses selanjutnya memakan waktu sekitar 3 bulan. Tidak ada tahap pengujian, semua kesalahan ditemukan oleh pengembang atau dukungan itu sendiri saat menggunakan alat tersebut.



Seperti yang Anda duga, pancake ini keluar dengan kental. Kami mencobanya dan berpikir bahwa kerugian dari layanan yang dibeli tidak terlalu serius. Dan kemudian tim meja bantuan komersial mengusulkan integrasi, di mana ia akan menerima informasi tentang pengguna dari game dan mengirimkannya dalam bentuk tiket ke dukungan kami (ini akan menyelesaikan masalah utama). Namun, beberapa persyaratan integrasi bertentangan dengan persyaratan keamanan yang diterapkan oleh perusahaan. Jadi opsi apa yang kami miliki:

1. Buat integrasi yang tidak aman dengan meja bantuan komersial.
2. Gunakan fungsionalitas yang dipreteli.
3. Kembali ke pengembangan alat.

Kami mengambil jalan terakhir. Kami memperbaiki semua yang tidak berfungsi setelah iterasi pertama dan menghubungkan sistem tiket ke game. Itu memiliki fungsi dasar: kami menerima aplikasi dan menanggapinya dengan mengirim pesan ke surat. Tapi yang terpenting, kami akhirnya memiliki kesempatan untuk melihat ID pemain di sistem tiket, yang mengacu pada alat internal kami yang lain dengan informasi akun lainnya.



Tim yang menyediakan proses pengembangan awalnya termasuk pemilik produk, PM, dan tim pengembang. Kami menggambar sendiri desainnya, pengembang mengeditnya, dan sejauh mungkin, menguji produknya. Kemudian desainer UI / UX dan QA bergabung. Hasilnya adalah proses berikut: pelanggan menulis apa yang dia inginkan, UI / UX mengatakan cara terbaik untuk melakukannya, pengembang menerapkannya, memeriksa QA, dan PM mengontrol seluruh rantai dan waktu.







Setelah memperkenalkan sistem tiket dengan fungsionalitas minimal, kami mulai meningkatkan dan menyesuaikannya dengan kebutuhan dan tujuan perusahaan. Secara total, lebih dari 200 fitur telah diimplementasikan hingga saat ini, yang utama tercantum di bawah ini.

1. . , KPI , , . 7 50 .
2. — ( ) .
3. .
4. .
5. HTML- .
6. -. - .
7. .
8. . , .
9. - .
10. , .
11. ( new, waiting, answered, resolve close, inprogress, pending). ; , / ; ( ).
12. .
13. .
14. , .
15. Alur yang dapat diprogram - solusi terpasang, termasuk pemberitahuan kepada karyawan yang bertanggung jawab jika terjadi peristiwa di sistem tiket.

Apa tumpukan teknologi kami:

• Aplikasi NET Web API yang ditulis dalam C # sebagai backend;
• Klien sudut;
• MongoDB untuk database dan ElasticSearch untuk pencarian teks lengkap;
• Mailgun untuk mengirim pesan email ke pemain.

Tampilan Umum Sistem Tiket Dukungan



Mari kita rangkum.

Keuntungan mengembangkan sistem tiket Anda sendiri

1. Meja bantuan yang dipertajam untuk perusahaan Anda dalam memecahkan masalah, menyederhanakan indikator aliran dan pelacakan.
2. Pendalaman pengetahuan tentang fungsi sistem tiket dan tentang pekerjaan tim dukungan teknis yang duduk di seberang dinding dari Anda.
3. -. , - .
4. , .
5. .
6. . , - , .
7. . , , .
8. , , .
9. . , «» , , QA UI/UX- , .

1. . — , . . 40 50–70 , 3–5 ( ). -, , , , . , , -.
2. Kami harus menempuh jalan yang panjang dan sulit. Kami mengubah proses pengembangan beberapa kali, berjuang dan memasang, membuat dan mengerjakan ulang. Lebih dari 1.500 bug telah diperbaiki dalam 3,5 tahun ini.
3. Perubahan struktural akan dibutuhkan. Dibutuhkan tim yang bekerja untuk mendukung proses internal. Hal ini diperlukan untuk memisahkan antara yang memproduksi produk perusahaan dan yang membuat peralatan back office. Tidak mungkin menarik pengembang utama untuk membuat alat seperti itu.

Untuk terlibat dalam bisnis ini atau tidak, itu terserah Anda. Dan kami tidak menyesal terlibat. Itu menakutkan. Dan itu juga sangat menarik.