Portal SOP Internal

Anisa Catering Ops SOP

Satu halaman kerja untuk mengubah chat catering yang ramai jadi aksi operasional yang jelas: tangkap fakta, kunci status, jaga izin perubahan, lalu tutup hari dengan handoff yang rapi.

01

Workflow Inti Order Catering

End to end

SOP ini dipakai untuk memastikan semua order bergerak lewat jalur yang sama: inquiry masuk, penawaran dikunci, DP dipastikan, produksi disiapkan, pengiriman dijalankan, lalu order ditutup dengan status dan handoff yang jelas.

1. Lead masuk

  • Catat nama customer atau PIC, tanggal acara, lokasi, kebutuhan awal, dan sumber chat.
  • Status awal: Inquiry.
  • Kalau data inti belum ada, jangan lompat ke quote.

2. Quote dan negosiasi

  • Kunci menu, porsi, layanan, harga, dan deadline keputusan customer.
  • Status: Quoted.
  • Semua revisi harus tercatat, bukan hanya angka terakhir.

3. Booking dan DP

  • Order baru dianggap aman masuk produksi setelah ada konfirmasi booking yang sah.
  • Status: DP Paid atau Confirmed bila syarat booking terpenuhi.
  • Finance atau owner yang berwenang mengesahkan status bayar.

4. Operasional prepare

  • Turunkan order ke belanja, kitchen prep, packing, armada, dan crew bila perlu.
  • Status: In Preparation.
  • Setiap PIC harus tahu output yang harus jadi sebelum pindah tahap.

5. Delivery atau service

  • Pastikan jam berangkat, alamat final, PIC lapangan, dan bukti serah terima.
  • Status: Delivered.
  • Masalah di lapangan harus langsung naik ke ops/admin atau owner sesuai levelnya.

6. Closing order

  • Order hanya boleh Completed jika pengiriman atau service selesai dan pelunasan jelas.
  • Kalau salah satu belum beres, status tetap terbuka.
  • Tutup hari dengan handoff yang menyebut waiting items dan risiko besok.
02

Fungsi dan Tanggung Jawab Masing-Masing

Siapa pegang apa

Sales atau Admin Order

  • Menerima inquiry, menggali kebutuhan, menyusun quote, dan mengunci revisi order.
  • Menjaga field inti: tanggal, lokasi, menu, porsi, layanan, harga, PIC customer.
  • Menentukan kapan order siap dilempar ke ops.

Finance

  • Memverifikasi DP, sisa pembayaran, pelunasan, dan bukti transfer.
  • Mengubah status bayar hanya bila ada bukti dan otoritas yang benar.
  • Memberi sinyal order aman diproses atau masih tertahan pembayaran.

Operasional atau Admin Produksi

  • Menerjemahkan order jadi checklist kerja: belanja, prep, packing, armada, crew.
  • Membagi owner tugas dan deadline internal.
  • Menjaga perubahan last minute agar semua PIC kena update yang sama.

Kitchen

  • Fokus pada menu final, porsi final, spesifikasi kemasan, dan jam selesai siap kirim.
  • Naikkan blocker lebih awal bila bahan, alat, atau tenaga tidak cukup.
  • Tidak memakai angka dari chat lama jika sudah ada revisi resmi.

Delivery atau Service Crew

  • Memegang alamat final, kontak lapangan, jam tiba, kendaraan, dan item yang dibawa.
  • Konfirmasi serah terima, kendala venue, dan kebutuhan tambahan di lokasi.
  • Melapor cepat jika ada telat, kurang barang, atau perubahan akses venue.

Owner

  • Memutuskan pengecualian besar: diskon, order riskan, perubahan besar H-1/H-0, atau konflik customer.
  • Mengesahkan keputusan yang berdampak finansial atau reputasi.
  • Bukan tempat parkir semua keputusan kecil yang bisa selesai di fungsi masing-masing.
03

Alur Sales Admin dari Inquiry Sampai Confirmed

Input wajib sebelum quote

  • Nama customer atau PIC.
  • Tanggal dan jam acara.
  • Lokasi atau gedung.
  • Perkiraan porsi atau jumlah box.
  • Jenis layanan: drop, prasmanan, snack box, nasi box, pondokan, atau crew service.

Output sebelum lempar ke ops

  • Menu final atau versi menu yang sedang menunggu approval jelas statusnya.
  • Porsi final yang dipakai produksi.
  • Harga final dan syarat pembayaran.
  • PIC customer aktif dan nomor kontak yang dipakai pada hari H.
  • Catatan perubahan penting dari chat sebelumnya.
Sales atau admin belum boleh menulis Confirmed hanya karena customer berkata "siap" atau "oke". Status baru naik bila item yang di-oke-kan memang lengkap: tanggal, menu, porsi, lokasi, harga, dan syarat pembayaran sudah tidak kabur.
04

Alur Operasional Setelah Order Confirmed

Produksi ke lapangan

Belanja dan bahan

  • Turunkan kebutuhan bahan dari menu final, bukan dari draft awal.
  • Catat bahan kritis dan deadline pengadaan.
  • Kalau ada perubahan porsi, hitung ulang dampaknya.

Kitchen prep

  • Tentukan jam mulai prep, jam finish, dan siapa penanggung jawab tiap komponen menu.
  • Item rawan telat diberi status blocker lebih awal.
  • Versi menu lama tidak boleh tertukar dengan menu final.

Packing

  • Cocokkan jumlah box, label, alat makan, sambal, pelengkap, dan kemasan khusus.
  • Pastikan output packing sama dengan format yang dijanjikan ke customer.
  • Barang pinjaman atau inventaris venue dicatat terpisah.

Dispatch

  • Pastikan mobil, driver, rute, jam berangkat, dan buffer keterlambatan.
  • Alamat final harus versi terakhir yang sah.
  • Kalau venue punya akses khusus, informasikan sebelum berangkat.

On-site service

  • Kalau ada crew service, PIC lapangan harus pegang rundown, titik setup, dan kontak venue.
  • Perubahan mendadak di lokasi dicatat sebagai kejadian operasional.
  • Kekurangan barang harus segera di-escalate, bukan ditahan sampai pulang.

Completion

  • Setelah terkirim atau acara selesai, catat jam selesai dan status serah terima.
  • Kalau pelunasan belum masuk, order belum selesai penuh.
  • Tinggalkan jejak masalah untuk evaluasi order berikutnya.
05

Workflow Kitchen Processing

Dapur dari brief ke finish

Bagian ini dipakai supaya kitchen tidak hanya menerima order mentah, tetapi menerima brief final, membagi kerja per komponen, menjaga timing masak, dan menyerahkan hasil ke packing dalam kondisi yang siap jalan.

1. Terima brief final

  • Kitchen hanya mulai dari order final yang sudah jelas menu, porsi, jam kirim, dan catatan khusus.
  • Kalau masih ada dua versi menu atau porsi, tahan mulai dan minta ops pastikan versi sah.
  • Catatan alergi, non pedas, tanpa bawang, atau request khusus harus ditandai sejak awal.

2. Breakdown produksi

  • Pecah pekerjaan per item: marinasi, potong bahan, bumbu, masak inti, garnish, dan finishing.
  • Tentukan PIC tiap komponen menu, bukan hanya satu PIC untuk semua.
  • Item yang butuh waktu lama dikerjakan lebih awal dan diberi target jam selesai.

3. Prep bahan

  • Cek ulang bahan masuk lawan kebutuhan final.
  • Kalau ada bahan kurang atau kualitas turun, langsung naikkan sebelum jam masak inti.
  • Gunakan label untuk batch atau komponen yang mudah tertukar.

4. Masak inti

  • Masak sesuai urutan yang menjaga rasa, tekstur, dan jam finish.
  • Jangan ganti resep inti, level porsi, atau komponen utama tanpa izin.
  • Kalau ada potensi molor, kabari ops saat risiko muncul, bukan setelah telat.

5. QC kitchen

  • Cek rasa, kematangan, jumlah tray atau pan, dan kesesuaian dengan brief order.
  • Pastikan item pendamping seperti sambal, kerupuk, garnish, saus, atau sendok saji tidak tertinggal.
  • Masalah kualitas harus diputuskan sebelum pindah ke packing.

6. Serah ke packing

  • Serahkan item dengan jumlah, label, dan urutan yang jelas.
  • Sebutkan item mana yang panas, dingin, rapuh, atau harus dipisah.
  • Kalau ada item susulan, tulis jelas ETA-nya agar packing tidak mengira sudah lengkap.

7. Escalation kitchen

  • Naikkan ke ops segera jika bahan inti kurang, hasil tidak sesuai standar, atau target jam finish terancam.
  • Naikkan ke owner bila keputusan menyentuh perubahan menu utama, pengurangan porsi, atau biaya tambahan besar.
  • Jangan biarkan kitchen menyelesaikan masalah besar sendirian tanpa jejak keputusan.
06

Alur Finance dan Status Pembayaran

Pisahkan selalu antara DP dan pelunasan. Order tidak boleh dianggap Completed kalau delivery dan pelunasan belum sama-sama clear.

Status keuangan yang dipakai

  • Unpaid: belum ada pembayaran yang sah.
  • DP Paid: DP sudah diverifikasi.
  • Partially Paid: ada pembayaran masuk, tetapi bukan pelunasan penuh.
  • Paid Off: lunas dan terbukti.

Aturan bukti dan wewenang

  • Marketing tidak boleh update status pembayaran.
  • Perubahan payment status butuh Finance atau Owner.
  • Kalau proof transfer disebut tapi file hilang, catat proof mentioned, attachment unavailable.
  • Jangan tulis lunas kalau baru ada janji transfer.
07

Perubahan, Otorisasi, dan Eskalasi

Jangan salah otorisasi

Siapa boleh mengubah apa

  • Sales atau admin boleh ubah detail order selama masih di domain penawaran dan koordinasi order.
  • Finance atau owner yang mengesahkan status bayar.
  • Perubahan besar H-1 atau H-0 wajib naik ke ops/admin senior atau owner.

Kapan harus escalate

  • Perubahan lokasi, jam kirim, atau porsi setelah produksi berjalan.
  • Kekurangan bahan, crew, armada, atau alat penting.
  • Customer komplain di hari H.
  • Permintaan diskon, refund, atau pengecualian pembayaran.
Prinsipnya: allowlist Telegram bukan otorisasi bisnis. Orang bisa menghubungi Anisa belum berarti orang itu sah mengubah lokasi order, status pembayaran, cancellation, atau keputusan operasional.
08

Approval Matrix

Siapa approve apa

Matrix ini dipakai untuk membedakan antara yang boleh menyiapkan, yang boleh mengusulkan, dan yang benar-benar berwenang menyetujui perubahan atau keputusan.

Sales atau Admin Order

  • Boleh: input inquiry, susun quote, revisi draft order, follow up customer.
  • Butuh approval: diskon khusus, perubahan besar setelah confirmed, cancellation, atau janji kompensasi.
  • Escalate ke: Owner atau ops/admin senior bila dampaknya ke margin, kapasitas, atau jadwal produksi.

Finance

  • Boleh approve: status DP masuk, pelunasan masuk, bukti transfer valid.
  • Tidak boleh sendirian approve: diskon pelunasan, refund, toleransi hutang, atau penghapusan tagihan.
  • Escalate ke: Owner untuk semua keputusan yang mengurangi nilai tagihan atau memindah termin pembayaran.

Operasional atau Admin Produksi

  • Boleh approve: pembagian tugas internal, urutan prep, packing flow, penyesuaian teknis kecil.
  • Butuh approval: tambah crew berbayar, sewa alat mendadak, perubahan rute besar, atau keputusan yang menambah biaya.
  • Escalate ke: Owner untuk perubahan H-1/H-0 yang memengaruhi biaya, kualitas, atau komitmen ke customer.

Kitchen Lead

  • Boleh approve: urutan masak, substitusi teknis minor yang tidak mengubah janji utama ke customer.
  • Tidak boleh approve: ganti menu utama, turunkan porsi, atau ubah spesifikasi tanpa izin.
  • Escalate ke: Operasional dan Owner jika bahan inti kosong atau hasil akhir terancam tidak sesuai pesanan.

Delivery atau Service PIC

  • Boleh approve: keputusan lapangan kecil untuk akses, titik parkir, urutan bongkar, dan setup.
  • Tidak boleh approve: pindah jam kirim, kurang barang dianggap selesai, atau ubah komitmen layanan ke customer.
  • Escalate ke: Operasional segera bila ada keterlambatan, komplain, kekurangan item, atau perubahan venue.

Owner

  • Final approval untuk: diskon, refund, cancellation, change order besar, toleransi pembayaran, dan komitmen ekstra ke customer.
  • Menjadi escalation point untuk konflik antar fungsi atau keputusan dengan dampak reputasi.
  • Bukan approver untuk detail teknis harian yang sudah punya PIC jelas.
Rule singkat: yang menyusun belum tentu yang mengesahkan. Draft order bisa dibuat Sales, status bayar disahkan Finance, keputusan biaya besar disahkan Owner, dan eksekusi lapangan dijalankan Ops.
09

Instruksi Kerja Operasional di Telegram

Cara jalan tim harian

Telegram dipakai sebagai jalur kerja cepat, bukan tempat keputusan liar. Semua tim wajib menulis update yang singkat, jelas, dan bisa dipakai fungsi lain tanpa harus membaca ulang seratus chat.

Rule dasar per chat order

  • Satu order harus punya satu thread logika: siapa customer, acara kapan, lokasi mana, menu apa, porsi berapa, status bayar apa.
  • Kalau ada perubahan, tulis format: Perubahan: field lama -> field baru.
  • Jangan kirim “siap” atau “oke” tanpa menyebut item yang disetujui.
  • Kalau masih asumsi atau belum pasti, tulis jelas belum confirm.

Rule update status

  • Sales/Admin update saat inquiry masuk, quote dikirim, customer revisi, dan order confirmed.
  • Finance update hanya untuk status DP, pelunasan, bukti transfer, dan tagihan.
  • Ops update saat order turun ke prep, packing, berangkat, tiba, dan selesai service.
  • Kalau status penting berubah, tulis ulang status lengkap, bukan hanya “sudah”.

Format update Sales/Admin

  • Order: [nama customer / instansi]
  • Status: inquiry / penawaran dikirim / confirmed
  • Isi: tanggal acara, jam, lokasi, menu, porsi, harga, tindak lanjut

Format update Finance

  • Payment: DP masuk / pelunasan masuk / belum masuk
  • Nominal: tulis angka jelas.
  • Bukti: valid / menunggu verifikasi.

Format update Ops

  • Stage: prep / packing / OTW / setup / selesai
  • PIC: siapa pegang.
  • Issue: kosongkan jika aman, isi jelas jika ada risiko.
Telegram dipakai untuk menangkap keputusan dan handoff, bukan menyimpan semua obrolan. Kalau chat sudah panjang, kirim rangkuman status terakhir dalam satu pesan bersih.
10

Gaya Bahasa Anisa di Telegram

Nada kerja khas tim

Bahasa Anisa harus sopan, cepat dipahami, dan terasa operasional. Fokusnya bukan terdengar formal sekali, tapi membuat orang langsung tahu status, tugas, dan siapa yang pegang.

Karakter bahasa yang dipakai

  • Singkat, sopan, dan langsung ke inti.
  • Pakai nada layanan: siap, baik, maaf, tolong, nggih bila relevan.
  • Hindari gaya debat, sarkas, atau terlalu santai saat menyangkut order.
  • Kalau ada masalah, tulis faktanya dulu baru usulan tindak lanjut.

Yang wajib jelas dalam kalimat

  • Siapa customer atau order yang dimaksud.
  • Apa status atau perubahan terbarunya.
  • Siapa yang harus follow up.
  • Kapan deadline atau waktu acaranya.

Contoh frasa internal Anisa

  • Siap, saya follow up customer untuk final porsi hari ini.
  • Nggih, update terakhir lokasi pindah ke Gedung A lt.2.
  • Mohon izin, DP belum masuk jadi order belum bisa saya ubah ke confirmed.
  • Tolong cek ulang, di chat terakhir customer minta tambah 25 porsi.
  • Maaf, ada kendala armada. Estimasi mundur 15 menit, ops sedang handle.

Daftar kata dan style yang umum

  • Siap: tanda menerima tugas atau konfirmasi eksekusi.
  • Nggih: konfirmasi sopan, cocok untuk acknowledge arahan atau update.
  • Mohon izin: saat menaikkan isu, meminta keputusan, atau menyampaikan kendala.
  • Tolong cek / tolong bantu: delegasi yang tetap sopan.
  • Maaf: dipakai saat ada gap, kendala, atau koreksi.
  • Sudah aman: berarti isu selesai dan tidak ada action lanjutan.
  • Masih ditunggu: berarti ada dependency yang belum beres.
  • Naikkan ke owner: dipakai untuk approval yang melewati wewenang fungsi.
11

Daily Handoff Format

Handoff bukan ringkasan chat. Handoff adalah snapshot kerja yang membuat shift berikutnya langsung tahu order mana aman, mana belum, siapa pegang apa, dan apa risiko besok pagi. 

# Catering Handoff - YYYY-MM-DD

## Confirmed Orders
- Customer:
  Date/time:
  Location:
  Menu:
  Porsi:
  Payment status:
  Current stage:
  Internal owner:

## Changes Today
- perubahan apa:
  dampaknya ke siapa:

## Waiting On
- siapa yang ditunggu:
  deadline:

## Risks
- risiko:
  mitigasi:

## First Priority Besok Pagi
-
12

Aturan Baca Chat Supaya Tidak Salah Input

Aturan interpretasi

  • Anggap “siap”, “nggih”, atau “oke” sebagai konfirmasi hanya jika item yang dikonfirmasi benar-benar jelas.
  • Cocokkan “besok”, “nanti”, “hari ini”, dan “kemarin” dengan timestamp chat sebelum menulis tanggal.
  • Deleted messages dan missing media adalah gap bukti, bukan ruang untuk menebak.

Sinyal operasional

  • “maaf”, “tolong”, “siap”, dan “nggih” sering menandakan handoff, urgensi, atau ownership.
  • Kalau quantity berubah, pegang angka terbaru yang confirmed.
  • Simpan angka lama jika masih berpengaruh ke belanja, prep, atau logistik.

Field inti yang wajib ada

  • Customer atau PIC.
  • Tanggal dan jam acara.
  • Lokasi atau gedung.
  • Menu dan porsi.
  • Status bayar.
  • PIC internal next action.

Status order yang dipakai

  • Inquiry
  • Quoted
  • Confirmed
  • In Preparation
  • Delivered
  • Completed atau Blocked
13

13. SOP: Penerimaan Order

SOP

Penanggung Jawab: PIC Sales/Admin Order

Terakhir diperbarui: 2026-06-24

Frekuensi: Sesuai kebutuhan (saat ada inquiry atau permintaan order baru)

Estimasi waktu: 5–15 menit

Kenapa penting: Order yang salah input menyebabkan kesalahan kitchen, porsi keliru, dan kegagalan logistik di hari acara.

Pemicu

Apa yang memulai proses ini dan bagaimana tahu saatnya mulai.

  • Sinyal: Customer meminta penawaran menu atau menyatakan ingin booking/order catering.
  • Input masuk via: Pesan Telegram, DM, atau log chat WhatsApp yang dibagikan owner.
  • Bentuk input: Pesan chat informal berisi tanggal, nama gedung, ide menu, dan jumlah porsi (contoh: "Nasi Box 150 pax untuk tgl 15 Juni di Gedung Manggala").

Langkah-langkah (alur normal)

# Langkah Tool / sistem Yang dilihat Output langkah ini
1 Terima & Klasifikasi Ingestion Engine / Script Teks/lampiran pesan Telegram masuk Pesan diklasifikasi sebagai inquiry atau kandidat draft
2 Ekstrak Detail Script Pembuatan Draft Tanggal acara, menu, porsi, lokasi, nama customer File draft belum lengkap (.json atau record draft)
3 Follow-up Data Kosong Chat Telegram Field inti yang kurang (misal: pilihan menu spesifik, jam pasti) Customer melengkapi detail yang kurang
4 Simpan Draft Order Postgres DB (order_drafts) Data order lengkap Draft dibuat dengan ID unik (contoh: DRAFT-YYYYMMDD-XXX)
5 Konfirmasi via Command Chat Telegram / Script Draft ID (contoh: /confirm_order DRAFT-XYZ) Order dibuat di DB aktif (orders)

Titik Keputusan

Untuk setiap judgment call, aturan eksplisit agar siapapun bisa mengambil keputusan yang sama.

  • Keputusan: Apakah membuat inquiry atau langsung generate draft order.
  • Pilih Inquiry jika: Customer baru tanya harga atau opsi dan belum kasih tanggal/jumlah spesifik.
  • Pilih Draft Order jika: Customer sudah sebut tanggal, gedung, kategori menu, dan minta penawaran/konfirmasi formal.
  • Info yang dibutuhkan: Tanggal acara, perkiraan porsi, kelas menu.

Pengecualian dan Kasus Khusus

Kasus yang tidak masuk alur normal, dan apa yang harus dilakukan.

  • Jika media/lampiran hilang: Cek apakah ada foto atau PDF menu yang disebut. Tandai sebagai bukti disebut, lampiran tidak tersedia di catatan draft.
  • Jika quantity berubah setelah konfirmasi: Catat perubahan sebagai catatan operasional baru; jangan timpa history tanpa izin admin.
  • Berhenti dan tanya manusia jika: User marketing minta perubahan order, pembatalan, atau override lokasi/waktu.

Tools, Akses, dan Data

  • Tools yang dipakai: Database Postgres ANISACatering, Telegram Command Parser, script Python (scripts/confirm_order_draft.py, scripts/generate_order_draft_candidates.py).
  • Akses yang diperlukan: Kredensial Sales Admin atau Owner, akses database, sender_id Telegram yang terotorisasi.
  • Lokasi data: Pesan masuk → tabel order_drafts → tabel orders.

Definisi Selesai

  • Selesai jika: Draft order berubah menjadi order terkonfirmasi di database dan mendapat Order ID (contoh: ORD-YYYYMMDD-00000X).
  • Output yang baik: Field lengkap untuk Customer, Tanggal, Lokasi, Menu, Porsi, dan Handoff sudah dibuat untuk Finance dan Kitchen.
  • Dicek oleh: Sales Admin atau Owner via command /confirm_order.

Handoff

  • Menerima dari: Customer atau Marketing Lead.
  • Meneruskan ke: Finance (untuk tracking DP) dan Kitchen (untuk penjadwalan produksi).
  • Penyebab rework paling umum: Jam kirim tidak ada atau pilihan menu ambigu.

Catatan untuk Otomasi

  • Mekanis murni (agent bisa handle): Ekstrak detail dari chat, mapping parameter, generate draft JSON.
  • Butuh judgment manusia (tetap dalam loop): Eksekusi command /confirm_order (hanya Sales Admin atau Owner).
  • Pertanyaan terbuka yang perlu dijawab dulu: Apakah override draft boleh langsung di chat tanpa edit DB.
14

14. SOP: Konfirmasi Pembayaran

SOP

Penanggung Jawab: PIC Finance

Terakhir diperbarui: 2026-06-24

Frekuensi: Sesuai kebutuhan (saat tanda terima pembayaran atau bukti transfer dikirimkan)

Estimasi waktu: 5 menit

Kenapa penting: Produksi dapur dan logistik pengiriman bergantung pada konfirmasi DP/pembayaran; pembayaran yang terlewat bisa menyebabkan masalah keuangan atau pengiriman yang belum terbayar.

Pemicu

Apa yang memulai proses ini dan bagaimana tahu saatnya mulai.

  • Sinyal: Customer mengirimkan bukti transfer atau pesan yang menyatakan mereka telah membayar.
  • Input masuk via: DM Telegram, pesan group chat, atau lampiran gambar.
  • Bentuk input: "Sudah transfer DP Rp 5.000.000" atau screenshot layar sukses transfer e-banking.

Langkah-langkah (alur normal)

# Langkah Tool / sistem Yang dilihat Output langkah ini
1 Terima Bukti Ingestion Engine / Script Gambar/teks bukti transfer yang masuk Draft pembayaran dibuat di payment_drafts
2 Hubungkan Draft DB / Script Python Detail draft pembayaran & ID order terkait Status draft ditandai ready_for_confirmation
3 Verifikasi Bank E-Banking / Rekening Koran Mutasi rekening untuk mencocokkan transfer Dana terkonfirmasi masuk
4 Konfirmasi Pembayaran Chat Telegram / Script Draft ID (contoh: /confirm_payment PAY-XYZ) Status pembayaran di-update di DB (confirmed_payments)
5 Update Status Order DB Trigger Flag DP/pelunasan pada order terkait Order ditandai sebagai DP Paid atau Completed

Titik Keputusan

Untuk setiap judgment call, aturan eksplisit agar siapapun bisa mengambil keputusan yang sama.

  • Keputusan: Validasi nominal pembayaran.
  • Pilih Konfirmasi jika: Nominal di draft cocok dengan mutasi rekening dan terhubung ke order yang valid.
  • Pilih Tolak/Klarifikasi jika: Nominal tidak cocok, mutasi tidak muncul, atau data order tidak jelas.
  • Info yang dibutuhkan: Riwayat mutasi e-banking, detail draft pembayaran, data order terkait.

Pengecualian dan Kasus Khusus

Kasus yang tidak masuk alur normal, dan apa yang harus dilakukan.

  • Jika gambar bukti transfer hilang/rusak: Catat bukti disebut, lampiran tidak tersedia dan minta customer mengirim ulang.
  • Jika konfirmasi tidak terotorisasi (misal dari user Marketing): Tolak konfirmasi. Jelaskan bahwa hanya Finance atau Owner yang bisa konfirmasi pembayaran.
  • Berhenti dan tanya manusia jika: Ada perbedaan data antara klaim customer dan mutasi rekening koran.

Tools, Akses, dan Data

  • Tools yang dipakai: Database Postgres ANISACatering, e-banking, script Python (scripts/confirm_payment_draft.py).
  • Akses yang diperlukan: Kredensial Finance Admin atau Owner, akses database, sender_id Telegram terotorisasi.
  • Lokasi data: Bukti masuk → tabel payment_drafts → tabel confirmed_payments → Update pembayaran order.

Definisi Selesai

  • Selesai jika: Draft pembayaran berubah menjadi confirmed dan record pembayaran dibuat dengan nomor pembayaran unik (contoh: PAY-YYYYMMDD-00000X).
  • Output yang baik: Data pembayaran terkonfirmasi dengan referensi transaksi, jenis (DP/pelunasan), nominal pas, dan terhubung ke order.
  • Dicek oleh: Finance Admin atau Owner.

Handoff

  • Menerima dari: Sales Admin atau Customer.
  • Meneruskan ke: Kitchen (untuk lampu hijau produksi setelah DP lunas) dan Delivery (untuk pengiriman setelah Pelunasan).
  • Penyebab rework paling umum: Pembayaran tidak terhubung karena nama pengirim transfer berbeda dengan nama pemesan order.

Catatan untuk Otomasi

  • Mekanis murni (agent bisa handle): Scan teks masuk untuk nominal/nomor transaksi, membuat record draft pembayaran.
  • Butuh judgment manusia (tetap dalam loop): Verifikasi mutasi bank dan menjalankan command /confirm_payment.
  • Pertanyaan terbuka yang perlu dijawab dulu: Ketersediaan API integrasi mutasi bank secara otomatis.
15

15. SOP: Handoff Pengiriman

SOP

Penanggung Jawab: PIC Pengiriman/Logistik

Terakhir diperbarui: 2026-06-24

Frekuensi: Setiap hari acara per order (saat dapur memberi sinyal packing selesai)

Estimasi waktu: 15–60 menit per rute pengiriman

Kenapa penting: Pengiriman yang terlambat atau salah serah terima merusak reputasi bisnis; bukti pengiriman (POD) yang jelas melindungi bisnis dari klaim palsu.

Pemicu

Apa yang memulai proses ini dan bagaimana tahu saatnya mulai.

  • Sinyal: Dapur menandai order sebagai ready_for_dispatch.
  • Input masuk via: Alert internal atau antrean koordinasi melalui Telegram atau script.
  • Bentuk input: Update status di snapshot antrean atau pesan: "Order ORD-YYYYMMDD-00000X siap kirim".

Langkah-langkah (alur normal)

# Langkah Tool / sistem Yang dilihat Output langkah ini
1 Terima Tugas Chat Telegram / Script Antrean koordinasi / alert Tugas pengiriman diterima (status assigned)
2 Muat Barang Gudang/Dapur Item order dicocokkan dengan packing list Barang dimuat, status picked_up
3 Perjalanan Lapangan GPS kendaraan / lokasi driver Status di-update menjadi otw
4 Tiba di Lokasi Lapangan Alamat gedung/customer Status di-update menjadi arrived
5 Serah Terima Lapangan PIC customer menerima barang Status di-update menjadi handed_over
6 Upload POD Telegram / Aplikasi Foto tanda terima bertanda tangan atau bukti serah terima Bukti POD di-upload, status completed
7 Tutup Tugas Telegram / Script Tugas pengiriman ditutup Pengiriman ditandai selesai di DB

Titik Keputusan

Untuk setiap judgment call, aturan eksplisit agar siapapun bisa mengambil keputusan yang sama.

  • Keputusan: Apakah lanjut mengirimkan barang (dispatch).
  • Lanjut jika: Order ditandai ready_for_dispatch, semua barang selesai di-pack, pelunasan terkonfirmasi (kecuali diizinkan COD).
  • Tunda jika: Pelunasan belum beres (dan tidak ada izin COD dari owner).
  • Info yang dibutuhkan: Status order, status pembayaran, batasan waktu/lokasi acara.
  • Keputusan: Eskalasi masalah pengiriman.
  • Eskalasi ke Ops Lead jika: Alamat tidak ketemu, customer tidak bisa dihubungi, atau terlambat > 30 menit.
  • Eskalasi ke Owner jika: Acara berisiko gagal total tanpa tindakan darurat segera.

Pengecualian dan Kasus Khusus

Kasus yang tidak masuk alur normal, dan apa yang harus dilakukan.

  • Jika alamat tidak jelas/kurang: Hubungi Sales/Admin untuk klarifikasi data customer sebelum berangkat.
  • Jika customer menolak serah terima (salah menu, terlambat): Dokumentasikan masalah dengan foto/catatan; jangan paksa serah terima.
  • Berhenti dan tanya manusia jika: Customer memperdebatkan isi barang, atau ada risiko keamanan di lokasi.

Tools, Akses, dan Data

  • Tools yang dipakai: Database Postgres ANISACatering, command Telegram status, script tracking pengiriman.
  • Akses yang diperlukan: Kredensial Delivery PIC atau Ops Lead, device lapangan untuk upload POD, sender_id Telegram terotorisasi.
  • Lokasi data: orders → tabel delivery_tasks → Bukti POD → orders ditandai selesai.

Definisi Selesai

  • Selesai jika: Status order adalah completed, POD ter-upload ke bukti transaksi, dan serah terima terkonfirmasi di DB.
  • Output yang baik: Bukti pengiriman ber-timestamp dilengkapi foto, nama penerima cocok, dan lokasi sesuai.
  • Dicek oleh: Delivery PIC atau Operations Lead.

Handoff

  • Menerima dari: Kitchen (packing selesai) dan Finance (pembayaran lunas).
  • Meneruskan ke: Rangkuman Owner (untuk laporan harian) dan Customer Service (untuk follow-up setelah pengiriman).
  • Penyebab rework paling umum: Lupa upload POD, atau alamat kurang lengkap sehingga pengiriman gagal.

Catatan untuk Otomasi

  • Mekanis murni (agent bisa handle): Generate tugas pengiriman dari order, update status, menugaskan driver.
  • Butuh judgment manusia (tetap dalam loop): Eksekusi serah terima fisik di lapangan dan penanganan komplain di tempat.
  • Pertanyaan terbuka yang perlu dijawab dulu: Alur penugasan driver (sistem giliran atau manual).
16

16. SOP: Briefing Operasional Harian

SOP

Penanggung Jawab: Operations Lead / Owner (CEO)

Terakhir diperbarui: 2026-06-24

Frekuensi: Sekali sehari (pagi) + update eskalasi ad-hoc

Estimasi waktu: 10–20 menit

Kenapa penting: Owner butuh satu snapshot yang mencakup order, pembayaran, status produksi, dan blocker sebelum operasional harian berjalan.

Pemicu

Apa yang memulai proses ini dan bagaimana tahu saatnya mulai.

  • Sinyal: Awal hari kerja, biasanya jam 07:00 WIB.
  • Input masuk via: Script terjadwal atau permintaan manual.
  • Bentuk input: Owner menanyakan status atau cron job men-trigger script summary antrean.

Langkah-langkah (alur normal)

# Langkah Tool / sistem Yang dilihat Output langkah ini
1 Jalankan Snapshot Antrean Script Python scripts/phase_e_queue_summary.py --pretty Snapshot JSON/teks dari antrean
2 Review Setiap Bagian Terminal / Telegram Lima bagian: Antrean Sales, Antrean Finance, Antrean Kitchen, Preview Alert, Rangkuman Owner Pemahaman atas tugas yang outstanding
3 Identifikasi Blocker Dashboard / Catatan Briefing Item yang overdue, belum ditugaskan, atau konflik Daftar blocker disusun
4 Eskalasi Sesuai Kebutuhan Telegram / DM Item kritis yang butuh tindakan segera Pesan eskalasi dikirim ke PIC terkait
5 Acknowledge Tugas Telegram / Script Tugas ditandai sudah dibaca atau siap di-ack Item koordinasi di-acknowledge
6 Publikasi Rangkuman Telegram Main Group / DM Rangkuman owner untuk rencana hari ini Tim terinformasi soal prioritas hari ini

Titik Keputusan

Untuk setiap judgment call, aturan eksplisit agar siapapun bisa mengambil keputusan yang sama.

  • Keputusan: Item mana yang butuh eskalasi segera?
  • Eskalasi segera jika: Order belum bayar yang jadwalnya hari ini, pengiriman belum ditugaskan, dapur kekurangan bahan.
  • Log untuk nanti jika: Follow-up minor dengan buffer waktu (misal: reminder pembayaran untuk acara > 3 hari lagi).
  • Info yang dibutuhkan: Tanggal acara, status pembayaran terkini, status penugasan.
  • Keputusan: Apa yang masuk rangkuman yang dipublikasikan?
  • Masukkan: Order terkonfirmasi hari ini, blocker kritis, pembayaran tertunda, dan eskalasi terbuka.
  • Jangan masukkan: Tugas rutin prioritas rendah yang tidak memengaruhi operasional hari ini.

Pengecualian dan Kasus Khusus

Kasus yang tidak masuk alur normal, dan apa yang harus dilakukan.

  • Jika sumber data konflik: Tandai konflik di rangkuman dan minta rekonsiliasi manual; jangan asumsi benar.
  • Jika script snapshot antrean gagal: Pakai snapshot terakhir yang sukses + query DB manual; catat bahwa data basi.
  • Berhenti dan tanya manusia jika: Ada banyak blocker kritis di beberapa departemen sekaligus (risiko cascade).

Tools, Akses, dan Data

  • Tools yang dipakai: Database Postgres ANISACatering, script Python (phase_e_queue_summary.py, ack_coordination_item.py), Telegram.
  • Akses yang diperlukan: Kredensial Owner atau Ops Lead, akses baca database.
  • Lokasi data: orders, payment_drafts, coordination_queue, alerts → snapshot agregat → briefing yang dipublikasi.

Definisi Selesai

  • Selesai jika: Owner atau Ops Lead telah me-review snapshot, mengeskalasi blocker, acknowledge tugas yang relevan, dan mempublikasi rangkuman hari itu.
  • Output yang baik:

## Acara Hari Ini
- ORD-001: Nasi Box 200 pax @ Gedung Manggala 12:00 WIB - Kitchen siap, Delivery ditugaskan

## Pembayaran Tertunda
- ORD-002: DP terlambat (acara 26 Jun) - dieskalasi ke Finance

## Antrean Kitchen
- Semua order hari ini: bahan siap ✅

## Alert
- Tidak ada yang kritis

## Tindakan Owner
- Approve pengecualian untuk ORD-003 booking terlambat
  • Dicek oleh: Owner / Ops Lead.

Handoff

  • Menerima dari: Semua antrean departemen (Sales, Finance, Kitchen, Delivery).
  • Meneruskan ke: PIC departemen masing-masing (via rangkuman yang dipublikasi dan pesan eskalasi langsung).
  • Penyebab rework paling umum: Data antrean tidak lengkap atau snapshot basi.

Catatan untuk Otomasi

  • Mekanis murni (agent bisa handle): Menjalankan snapshot antrean, format briefing, kirim ke Telegram.
  • Butuh judgment manusia (tetap dalam loop): Memutuskan blocker mana yang dieskalasi, approve pengecualian.
  • Pertanyaan terbuka yang perlu dijawab dulu: Jadwal cron untuk auto-briefing vs. on-demand saja.