Internal · elux.space

Agentic Workflow · Landing Page

Gimana cara kita
ngumpulin SSOT?

Sebelum ngomongin agent-nya bisa apa, kita harus sepakat dulu: acuan yang dia baca itu datangnya dari mana.

Mulai Langsung ke proposal

All-hands · September 2026

Konteks

Kenapa ini dibahas

Agent gak bisa mutusin apa‑apa tanpa acuan.

Kita mau agent ikut bantu bikin landing page dari awal — bukan cuma ngecek hasil jadi. Artinya dia harus tahu section apa yang dibikin, urutannya gimana, dan kenapa.

  • Tanpa acuan, tiap run hasilnya beda-beda
  • Gak ada dasar buat bilang output-nya bener atau salah
  • Tiap orang di tim punya standar sendiri di kepalanya

Scope hari ini: landing page aja. Bukan app, bukan dashboard.

Definisi

Yang sering disalahpahami

SSOT itu bukan kumpulan
desain bagus.

SSOT itu cara mikir kita waktu bikin LP — yang selama ini cuma ada di kepala masing-masing. Tugas kita sekarang mindahin isi kepala itu ke tulisan, biar bisa dibaca agent.

Screenshot cuma nunjukin bentuknya. Yang bikin mahal itu alasannya.

Pilihan

Ada dua cara ngumpulin

Dua-duanya masuk akal. Bedanya di sumber datanya.

Opsi A

Generate dari best practice

Riset pola LP yang umum dipakai per kategori, bikin LP referensi, turunin aturannya dari situ.

Cepat. Bisa jalan minggu ini juga, gak nunggu siapa-siapa.

Opsi B

Bedah project sendiri

Ambil LP yang udah pernah kita kerjain, klasifikasi ke 4 kategori, tarik polanya dari situ.

Lambat. Butuh waktu tim buat diwawancara satu-satu.

Bukan pilihan mutlak — bisa dikombinasi. Tapi salah satu harus jadi sumber utamanya.

Trade-off

Head to head

Yang harus kita timbang.

Aspek A · Best practice B · Project sendiri
Waktu sampai jalan± 1 minggu± 4–5 minggu
Beban timHampir nol20 menit / project
Cocok sama klien kitaBelum tentuUdah kebukti
Contoh kegagalanGak adaAda
Bisa ditiru kompetitorBisaEnggak
Risiko output seragamTinggiSedang

Baris yang aku highlight itu yang paling nentuin. LP hasil generate gak punya riwayat revisi — gak ada klien yang pernah nolak, gak ada bagian yang pernah dibuang. Padahal "ini pernah gagal dan ini alasannya" itu bagian yang paling susah dicari.

Struktur

Bentuk file-nya

Tiga layer, dipisah biar gak saling nabrak.

Layer 1 · Aturan

File .md

Konteks kategori, apa yang wajib ada, apa yang gak boleh. Ditulis bahasa manusia.

Ini yang otoritatif. Kalau bentrok, yang ini menang.

Layer 2 · Struktur

File .html

Contoh konkret urutan section. Ilustrasi dari aturan di atas, bukan cetakan.

Agent boleh lihat, tapi gak boleh nyalin mentah.

Layer 3 · Style

Injected

Warna, tipografi, mood — dikasih terpisah per klien, gak disimpan di SSOT.

Ini yang bikin klien A gak keliatan kayak klien B.

Pemisahan ini berlaku di opsi manapun. Yang masih perlu diputusin cuma: isi layer 1 dan 2 itu ditarik dari mana.

Proses

Opsi B · Langkahnya

Empat langkah, per project.

Langkah 1–2 bisa dikerjain siapa aja. Langkah 3 cuma bisa dijawab orang yang ngerjain project itu.

  1. Kumpulin — LP yang udah pernah kita kerjain, bukan referensi luar.
  2. Klasifikasi — masuk kategori mana, dilihat dari KPI yang diminta klien waktu itu.
  3. Bedah — apa yang diminta, apa yang kita bikin, kenapa gitu, mana yang gagal.
  4. Catat — format sama persis buat semua, biar polanya kelihatan.
Pembagian kerja

Biar gak berat

Yang kelihatan mata, agent yang catat.

Agent yang kerjain

Inventarisasi: ada section apa aja, urutannya gimana, tombolnya berapa, headline-nya bunyinya apa.

Bagian membosankan. Gratis dan konsisten.

Manusia yang jawab

Alasan, batasan waktu itu, dan bagian yang gagal. Agent gak akan pernah tahu kenapa testimoni ditaro di atas.

Ini yang gak bisa digantiin.

Aturan keras: kolom alasan cuma boleh diisi manusia. Boleh kosong, boleh ditulis "lupa". Kalau agent yang nebak, dia bakal ngarang alasan yang kedengarannya masuk akal — dan kita gak akan bisa bedain lagi mana yang asli.

Wawancara

± 20 menit per project

Tujuh pertanyaan, sama buat semua kategori.

  1. Klien waktu itu minta apa? Salin apa adanya.
  2. Ada batasan apa? Budget, deadline, asset, klien maksa.
  3. Keputusan paling besar di project ini apa? Maks 3.
  4. Opsi lain apa yang sempat dipertimbangkan, dan kenapa ditolak?
  1. Bagian mana yang direvisi atau diprotes klien? Kenapa?
  2. Kalau ngulang sekarang, apa yang kamu ubah?
  3. Bagian mana yang khusus klien ini doang, jangan ditiru?

Nomor 4 itu kuncinya. Kalau cuma ditanya "kenapa didesain gini", jawabannya "biar clean" — gak kepake. Begitu ditanya opsi mana yang ditolak, orang terpaksa jelasin pertimbangan aslinya.

Formatnya ngobrol + rekam, bukan isi form. Form pasti diisi seadanya biar cepet kelar.

Proposal

Yang aku usulin

Pilot 12 project dulu. Jangan langsung semua.

Project

12

3 per kategori

Wawancara

20m

per project

Total jam tim

4j

dibagi ke semua

Sampai evaluasi

5mg

baru putusin scale


MilestoneTarget
Klasifikasi arsip + pilih 12 projectMg 1 · 6 Okt
Wawancara + bedah semua projectMg 2–3 · 20 Okt
Compile draft SSOT per kategoriMg 4 · 27 Okt
Tes: agent generate 1 LP, bandingin sama desainerMg 5 · 3 Nov
Evaluasi format → keputusan scaleMg 5 · 5 Nov

Kenapa 12, bukan 30: kalau format bedahnya ternyata salah, kita cuma ngulang 12.

Keputusan

Yang aku butuhin hari ini

Dua approval.

01

Jalanin pilot 12 project

3 per kategori, mulai minggu depan. Belum komitmen ke full rollout.

02

Slot waktu tim

20 menit per orang per project buat sesi wawancara. Total ± 4 jam dibagi semua.

Tanggal 5 November kita duduk lagi, lihat hasilnya, baru putusin mau diterusin atau ganti pendekatan.

elux.space · September 2026