Tiga bulan lalu gw masih ngerjain ticket support sendiri sambil ngajarin junior PM cara handle client tier B. Sekarang client loe 18, headcount 14, dan gw baru pertama kali dalam 2 tahun gak masuk chat WhatsApp client jam 9 malam.
Ini bukan cerita motivasi. Ini catatan operasi beneran setelah gw hampir kehilangan dua key designer dan tiga dev senior gara-gara konteks-switching berlebihan. Waktu scale dari 6 ke 18 klien, logika dasar business development gagal total. Yang lo perlukan bukan lebih banyak caffeine atau retreat tahunan — lo butuh brutal simplifikasi.
Kenapa Heroism Founder Itu Liabilitas Saat Scale-Up
Masalah utama kebanyakan founder creative agency adalah ego "aku yang bisa ngelewatin apapun". Pas tim lo masih 5 orang dan 6 klien, heroism itu aset. Lo bisa jawab Slack, approve design, sekaligus ngetik kontrak client langsung dari laptop mobil.
Ketika reach udah 14 kepala dan 18 akun klien, heroism berubah jadi bottleneck struktural. Otomatis.
Data internal kita selama Q2-Q3 kemarin ngebuktiin ini jelas: on-time delivery record kita cuma 62%. Bukan karena tim gak kompeten, tapi karena dependency chain-nya nempel ke satu titik—namanya gw. Meeting standup jadi 45 menit karena harus nunggu decision dari founder. Approval asset design rata-rata tunggu 36 jam. Client start complain pelan-pelan.
Yang ngeselin: kami coba rekrut lebih banyak PM mid-level buat bantu. Result? Chaos bertambah. Tanpa SOP handoff yang dipaksa, ditambah PM cuma bawa gaya komunikasi masing-masing, quality malah drop. Jadi gw stop hiring dulu. Gw ganti pendekatan dari "more hands" ke "clear lanes".
Client Tiering: Jangan Perlakukan Semua Klien Sama
Kalau lo pikir semua klien equal, lo salah besar di level scaling. Dulu kita treat PT Maju, CV Karya, dan client retail lokal sama persis. Revisi unlimited, meeting mingguan, direct line ke founder. Itu suicide note bertajuk cashflow.
Kita mulai cut client into tiga tier berdasarkan margin contribution dan strategic alignment:
Tier A (Strategic Partners) – 3 klien paling tinggi margin + reference value. Dapat dedicated account manager, fixed 2 revision rounds di contract, weekly sync 30 menit max. Akses ke founder cuma untuk quarterly roadmap.
Tier B (Cash Cow) – Volume stabil, scope jelas. Handoff ke PM standar, revision limit 3 rounds via portal. Support via ticketing async. Gw gak liat detail teknis, cuma track SLA.
Tier C (Maintenance/Churn-Friendly) – Scope kecil, rate low. Kita kasih package self-service + community access. Kalau mau priority handling, upgrade ke Tier B atau keluar. Brutal? Ya. Tapi survival.
Client PT Maju kemarin push mau tambah deliverable dadakan pas Sprint 4 berjalan. Karena mereka masuk Tier A, kita punya ruang negosiasi: tambah scope berarti geser timeline atau increase budget. Mereka pilih geser timeline. Delivery tetap on-track. Kalau dulu, gw pasti bilang "iya iya nanti diurus" dan jebolkan kapasitas tim.
Tiering ini gak bikin kita jadi jahat. Justru bikin kita transparan sejak day-one. Brief masuk, otomatis ketanggung jawab sesuai tier protocol.
Template Handoff yang Wajib Dipaksa (Bukan Disarankan)
Dulu handoff dari sales ke PM itu cuma voice note panjang di Telegram plus PDF scope yang udah 4x di-edit. Result-nya predictable: developer nunggu clarification 2 hari, designer bingung验收 criteria, PM ngegas ke atas karena deadline numpuk.
Kami build manual handoff protocol. Bukan Google Doc biasa. Ini mandatory checklist di tool internal:
- Locked scope statement (no ambiguous phrases like "sesuai kebutuhan")
- Acceptance criteria spesifik per deliverable
- Internal dependency map (siapa approve apa, urutan timeline)
- External communication script (bagaimana PM broadcast milestone ke client)
- Risk flag section (apa yang kemungkinan delay + mitigasi)
Setiap field wajib isi. Kosong? Auto-reject. Sales gak bisa close deal tanpa kelengkapan ini.
Di SatuTim kita pakai fitur Discussions buat validasi handoff sebelum task masuk pipeline. Setiap requirement diklaim oleh PM dan designer secara async. Nggak perlu nunggu meeting full team. Kalau ada gap, diskusi langsung di thread, bukan di grup chat umum yang nyembunyiin pertanyaan penting.
Hasilnya? Rata-rata clarification time turun dari 36 jam jadi 4 jam. Cycle time overall turun 18%. Dan yang paling nge-gass: gw berhenti jadi translator antara sales dan eksekutor.
WIP Cap 3 Stream Per Orang: Aturan Keras yang Nyelamatin Cycle Time
Kontras switching itu mahal. Dari riset produktivitas knowledge worker sampai experience lapangan kita, manusia maksimal bisa maintain 2-3 concurrent workstreams dengan kualitas acceptable. Lebih dari itu, context tax-nya bikin velocity melambat dan bug/error naik.
Kita pasang hard cap: maksimal 3 active stream per person. Bukan saran. Rule.
Awalnya banyak senior dev dan lead designer protes. "Kan aku lagi idle, mau ambil task lain aja." Gw tolak. Lebih baik idle 2 hari daripada bikin quality drop dan deadline miss di sprint berikutnya. Tim gw awal-awal memang agak mager dan skeptis, tapi setelah 2 sprint berlalu, pattern berubah.
Panjang task list turun drastis. Fokus naik. Lead designer cuma pegang 2 project design + 1 mentoring session. Senior dev fokus 2 feature rollout + 1 code review batch. PM jaga 3 account dengan status update harian di channel terpisah.
Ketika throughput udah macet, kita gak nambah orang. Kita potong WIP. Prioritaskan yang block cash flow atau yang deadline-H-minus-5. Sisanya pending. Kelar satu, baru open slot baru. Simple tapi jarang dipakai karena founder suka merasa diri harus memaksimalkan setiap menit karyawan.
Cap 3 stream ini juga bikin kita sadar berapa benar-benar capacity kita. 14 orang x 3 = 42 max concurrent streams. Kalau client request melebihi 40, kita harus bilang no atau negotiate timeline. Growth yang dipaksakan tanpa room di capacity cuma utang berbunga.
KPI yang Gak Bisa Bohong: Delivery Consistency & Founder Availability
Revenue itu lagging indicator. Saat scale-up, leading indicator yang lo pantau harusnya delivery consistency dan founder availability.
Delivery consistency kita ukur lewat on-time delivery rate (OTDR). Baseline kita 62%. Setelah implementasi tiering, handoff template, dan WIP cap, OTDR naik ke 89% dalam 3 bulan. Bukan magic. Hanya proses yang konsisten dijalankan.
Founder availability diukur lewat jumlah ticket/support interaction yang melibatkan founder per minggu. Target: nol. Bukan karena lo malas, tapi karena sistem udah jalan. Kalau founder masih kena issue operasional sehari 2-3 kali, artinya SOP lo belum siap scale.
KPI ini gak glamorous. Investor gak tertarik denger OTDR 89% saat pitching. Tapi buat operasional harian, ini tembok penahan chaos. Kalau lo paksa revenue naik 300% sementara OTDR turun ke 50%, lo lagi beli time dengan harga mahallll—dan eventually akan default.
Kita pake dashboard internal sederhana: column OTDR mingguan, column founder-ticket-log, column avg WIP/person. Review-an tiap Jumat sore. Tidak perlu slide deck. Cukup lihat angka, identify outlier, potong atau extend scope. Gampang. Tapi disiplin eksekusinya yang bikin beda.
Coba minggu ini: audit WIP tim lo. Hitung berapa stream aktif tiap orang. Kalau lebih dari 3, mulai potong prioritas. Atau tanya: kalau founder lo sakit besok, apakah operasional tim lo macet atau jalan?