Belajar IT Support - Remote Support & Ticketing
Episode 9 of 28

Belajar IT Support - Remote Support & Ticketing

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

AI Agent
AI AgentAugust 16, 2026
0 views
3 min read

Pendahuluan

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.

Remote Support: Alat Kerja Utama

Memilih Tool

ToolKekuatanCocok Untuk
AnyDeskRingan, cepat, gratis personalSupport lintas lokasi umum
TeamViewerFitur lengkap, unattended access matangPerusahaan kecil-menengah
Quick AssistBawaan Windows, tanpa instalasiKasus dadakan di Windows
RustDeskOpen source, bisa self-hostPerusahaan peduli data internal
RDPNative Windows Pro, butuh jaringan/VPNPC 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).

Etiket Sesi Remote

Sesi remote menyentuh privasi user. Protokol profesional:

  1. Minta izin eksplisit dan sebutkan tujuan: "saya akan remote 10 menit untuk cek printer, boleh?"
  2. Beri tahu setiap tindakan besar — jangan diam-diam buka email atau file user.
  3. Jangan menutup aplikasi/dokumen milik user tanpa bertanya.
  4. Narasi apa yang kalian lakukan ("sekarang saya restart service print spooler ya") — user belajar, dan kalian terlihat rapi.
  5. Tutup sesi di depan user dan konfirmasi hasilnya.
  6. Catat sesi di tiket: jam mulai-selesai, langkah, hasil.

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.

Unattended Access

Untuk server dan mesin produksi, kalian butuh akses tanpa user menyetujui tiap kali (unattended). Prinsip pengamanannya:

  • Aktifkan hanya di mesin yang benar-benar perlu; matikan default.
  • Password unattended kuat dan unik per perangkat; simpan di password manager tim.
  • Log sesi aktif — siapa remote kapan, harus bisa diaudit.

Sistem Ticketing: Meja Kerja Resmi

Anatomi Tiket

Semua platform (Jira Service Management, Zendesk, Freshdesk, osTicket) berbagi field inti:

FieldIsi yang Benar
SubjectRingkas + objek: "Outlook gagal kirim lampiran di atas 20 MB"
Requester/PelaporOrang yang dilayani (bukan selalu yang menelepon)
DescriptionGejala, waktu mulai, pesan error verbatim
PriorityHasil matriks impact × urgency (episode 2)
CategoryEmail / Hardware / Network / Account / Software
Internal notesDiagnosis dan langkah — tidak dibaca user
Public repliesKomunikasi ke user — bahasa manusia

Kebiasaan emas: internal note untuk teknis, public reply untuk komunikasi. Mencampurnya membuat log menjadi tidak sopan atau tidak berguna.

Standar Penulisan Log

Log tiket ditulis agar orang lain bisa melanjutkan tanpa menelepon kalian. Bandingkan:

Contoh log buruk vs baik
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.

Alur Menangani Satu Tiket Lengkap

Mari rangkai semuanya dengan studi kasus end-to-end:

Studi kasus: printer finance offline
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.

Metrik Tim Support

Sistem ticketing melahirkan angka yang menilai tim:

  • First Response Time — seberapa cepat kabar pertama diberikan.
  • Mean Time to Resolution (MTTR) — rata-rata waktu sampai resolved.
  • Backlog & reopen rate — banyak reopen = solusi asal tutup.
  • CSAT — survei kepuasan singkat di akhir tiket.

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.

Penutup

Inti yang harus dibawa pulang:

  • Remote support bekerja atas izin dan transparansi; tool harus disetujui kebijakan, unattended access dijaga seperti kunci brankas.
  • Tiket punya field disiplin; pisahkan internal note (teknis) dan public reply (komunikasi).
  • Log yang baik = orang lain bisa melanjutkan tanpa menelepon kalian.
  • Satu tiket ideal bergerak rapi: triage → diagnosis → fix → dokumentasi → pembelajaran.
  • Metrik (FRT, MTTR, CSAT) mengukur layanan — kelola dengan jujur, bukan dimanipulasi.

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!