Cara kerja inti profesi support: memilih dan mengamankan tool remote dari AnyDesk hingga Quick Assist, etiket sesi remote yang profesional, anatomi sistem ticketing dan field pentingnya, standar penulisan tiket yang bisa dibaca orang lain, serta alur menangani satu tiket lengkap dari telepon pertama sampai resolusi terdokumentasi

Setelah di episode 8 kalian siap mendukung email dan aplikasi produktivitas, sekarang kita bahas cara kerjanya sendiri: bagaimana menyentuh komputer user tanpa berdiri di sampingnya (remote support), dan bagaimana semua pekerjaan itu tercatat resmi di sistem ticketing. Dua hal ini adalah operasional harian yang membedakan support amatir dari profesional.
Mengapa ini penting? Karena perusahaan tidak menilai kalian hanya dari masalah yang terselesaikan, tapi dari jejak kerja yang tertib: setiap sesi ada persetujuan, setiap tiket ada riwayat, setiap solusi bisa ditemukan ulang oleh rekan kerja. Di episode 2 kita belajar teori lifecycle-nya — episode ini adalah praktiknya.
| Tool | Kekuatan | Cocok Untuk |
|---|---|---|
| AnyDesk | Ringan, cepat, gratis personal | Support lintas lokasi umum |
| TeamViewer | Fitur lengkap, unattended access matang | Perusahaan kecil-menengah |
| Quick Assist | Bawaan Windows, tanpa instalasi | Kasus dadakan di Windows |
| RustDesk | Open source, bisa self-host | Perusahaan peduli data internal |
| RDP | Native Windows Pro, butuh jaringan/VPN | PC kantor yang sudah dikelola |
Aturan praktis: pakai tool yang disetujui perusahaan, bukan yang paling nyaman pribadi. Tool remote adalah akses level admin ke mesin user — ia harus lolos kebijakan keamanan (episode 18).
Sesi remote menyentuh privasi user. Protokol profesional:
Warning
Waspadai modus penipuan: pelaku scam menelepon mengaku "dari IT" lalu meminta korban menjalankan AnyDesk/Quick Assist. Sebagai staf IT asli, selalu identifikasi diri lewat kanal resmi — dan edukasi user bahwa IT tidak pernah meminta password atau minta install tool remote via telepon dingin.
Untuk server dan mesin produksi, kalian butuh akses tanpa user menyetujui tiap kali (unattended). Prinsip pengamanannya:
Semua platform (Jira Service Management, Zendesk, Freshdesk, osTicket) berbagi field inti:
| Field | Isi yang Benar |
|---|---|
| Subject | Ringkas + objek: "Outlook gagal kirim lampiran di atas 20 MB" |
| Requester/Pelapor | Orang yang dilayani (bukan selalu yang menelepon) |
| Description | Gejala, waktu mulai, pesan error verbatim |
| Priority | Hasil matriks impact × urgency (episode 2) |
| Category | Email / Hardware / Network / Account / Software |
| Internal notes | Diagnosis dan langkah — tidak dibaca user |
| Public replies | Komunikasi ke user — bahasa manusia |
Kebiasaan emas: internal note untuk teknis, public reply untuk komunikasi. Mencampurnya membuat log menjadi tidak sopan atau tidak berguna.
Log tiket ditulis agar orang lain bisa melanjutkan tanpa menelepon kalian. Bandingkan:
BURUK:
"User komplain outlook. Sudah dicek normal. Close."
BAIK:
14:02 User melapor Outlook tidak bisa kirim sejak pagi, error 0x8004010F saat Send.
14:05 Webmail OK → akun & layanan sehat, indikasi profil lokal.
14:12 Profil Mail dibuat baru, cached mode 12 bulan. Kirim uji sukses.
14:20 User konfirmasi normal. Saran arsip folder Sent (>4 GB).Versi kedua menyelamatkan rekan shift malam ketika masalah serupa datang pukul 2 pagi.
Mari rangkai semuanya dengan studi kasus end-to-end:
1. MASUK Telepon dari Finance → buka tiket #3112, subject jelas,
priority P3 (satu divisi tapi ada printer cadangan)
2. TRIAGE Tanya: semua user atau satu? Semua → lanjut; satu → lokal saja
3. DIAG Ping IP printer: timeout → cek fisik: kabel network lepas
setelah pindahan meja kemarin
4. FIX Colok ulang, tunggu DHCP, print test page sukses
5. CLOSE Public reply: penyebab + solusi + tips cek lampu indikator
Internal note: "printer ini sering pindah colokan, pertimbangkan
static DHCP reservation"
6. LEARN Usulkan KB article "Cek 3 hal saat printer offline"Perhatikan: total waktu efektif mungkin 15 menit, tapi nilai prosesnya jauh lebih besar — tiket bisa diaudit, tren bisa dianalisis, dan usulan perbaikan lahir dari data.
Sistem ticketing melahirkan angka yang menilai tim:
Jangan gamel metrik dengan cara busuk (menutup tiket paksa demi MTTR, misalnya) — angka yang dimanipulasi akan kembali sebagai insiden dan kehilangan kepercayaan user.
Tip
Tutup setiap sesi kerja hari ini dengan ritual 10 menit: scan antrian, pastikan tidak ada tiket pending melewati SLA, dan tulis handover singkat bila besok libur. Konsistensi ritual kecil inilah yang membuat supervisor tenang mempercayakan shift ke kalian.
Inti yang harus dibawa pulang:
Di episode 10 selanjutnya kita masuk zona keamanan: security awareness support — jenis-jenis malware dan cara membersihkannya, membantu user mengenali phishing, kebijakan password dan MFA yang benar, serta langkah respons pertama saat insiden keamanan terjadi di depan mata kalian. Sampai jumpa!