← Kembali ke blog

Relay Tutup, Pelajaran Penting tentang Risiko Ketergantungan pada Platform Workflow Automation

TechCrunch melaporkan Relay akan berhenti beroperasi dan sebagian stafnya bergabung dengan tim Google Chrome. Dari sisi bisnis, kasus ini menjadi pengingat penting untuk mengelola risiko ketergantungan pada platform workflow automation.

Relay Tutup, Pelajaran Penting tentang Risiko Ketergantungan pada Platform Workflow Automation

Relay Tutup, Pelajaran Penting tentang Risiko Ketergantungan pada Platform Workflow Automation

TechCrunch melaporkan bahwa Relay, startup yang menawarkan workflow automation untuk bisnis, akan berhenti beroperasi. Dalam laporan yang terbit pada 17 Agustus 2026, TechCrunch juga menyebut CEO Relay dan sebagian stafnya berencana bergabung dengan tim Google Chrome.

Di sisi lain, halaman resmi Relay.app menyatakan layanan ditutup untuk pengguna gratis pada 15 Agustus 2026 dan untuk pelanggan berbayar pada 14 September 2026. Ini penting dibedakan: informasi jadwal penutupan layanan berasal dari halaman resmi Relay.app, sedangkan informasi tentang perpindahan CEO dan sebagian staf ke Google Chrome berasal dari laporan TechCrunch.

Laporan media tetap bukan pengganti konfirmasi resmi dari pihak terkait. Sampai informasi yang tersedia dalam riset ini, tidak ada dasar untuk menyatakan bahwa seluruh produk, teknologi, atau aset Relay diakuisisi Google. Sumber yang tersedia hanya menyebut CEO dan sebagian staf bergabung dengan tim Google Chrome.

Apa yang diketahui sejauh ini

Beberapa poin yang bisa dicatat secara hati-hati:

  • TechCrunch melaporkan Relay akan berhenti beroperasi.
  • TechCrunch melaporkan CEO dan sebagian staf Relay berencana bergabung dengan tim Google Chrome.
  • Halaman resmi Relay.app menyatakan layanan ditutup untuk pengguna gratis pada 15 Agustus 2026.
  • Halaman resmi Relay.app menyatakan layanan ditutup untuk pelanggan berbayar pada 14 September 2026.
  • Tidak ada informasi terverifikasi dalam sumber yang tersedia tentang penyebab penutupan, kondisi keuangan, atau kualitas produk Relay.
  • Tidak tepat menyimpulkan bahwa semua platform automation tidak aman atau pasti akan tutup hanya dari satu kasus ini.

Bagi saya, bagian paling penting dari berita ini bukan sekadar satu startup automation yang berhenti beroperasi. Yang lebih relevan untuk pemilik bisnis, profesional, dan UMKM adalah bagaimana proses bisnis berjalan ketika satu platform penting tiba-tiba berubah arah.

Automation adalah sistem operasional, bukan sekadar kumpulan konektor

Workflow automation sering terlihat sederhana: hubungkan form ke spreadsheet, kirim notifikasi ke Slack, buat task otomatis, sinkronkan data CRM, atau jalankan approval internal. Namun ketika workflow itu sudah menjadi bagian dari operasi harian, ia bukan lagi sekadar fitur tambahan.

Ia berubah menjadi sistem operasional.

Masalahnya, banyak bisnis mengadopsi automation seperti mencoba tool baru, bukan seperti membangun sistem yang perlu dirawat. Selama workflow berjalan, risikonya sering tidak terlihat. Risiko baru terasa ketika vendor menutup layanan, mengubah harga, membatasi fitur, mengganti API, atau mengubah arah produk.

Kasus Relay mengingatkan saya bahwa Business Process Optimization melalui Software Engineering dan Automation harus mempertimbangkan keberlanjutan proses, bukan hanya efisiensi di awal.

Risiko utama jika bisnis terlalu bergantung pada satu platform automation

1. Portabilitas workflow yang rendah

Workflow yang dibuat di satu platform sering sulit dipindahkan ke platform lain. Nama step, format trigger, struktur conditional logic, mapping field, dan konfigurasi autentikasi bisa sangat spesifik terhadap vendor.

Jika tidak ada dokumentasi yang baik, tim bisa kehilangan pemahaman tentang cara kerja prosesnya. Bahkan workflow yang tampak sederhana bisa menjadi rumit ketika sudah berisi banyak pengecualian bisnis.

2. Kepemilikan data dan konfigurasi tidak jelas

Data transaksi mungkin tetap berada di aplikasi utama, tetapi log automation, konfigurasi workflow, riwayat eksekusi, mapping field, dan template pesan bisa tersimpan di platform automation.

Pertanyaan praktisnya: apakah semua itu bisa diekspor dengan mudah? Apakah formatnya bisa dibaca manusia? Apakah cukup untuk membangun ulang proses di sistem lain?

3. Vendor lock-in pada proses kritis

Vendor lock-in bukan hanya soal data. Dalam automation, lock-in bisa terjadi pada cara kerja proses.

Contohnya, tim sudah terbiasa menekan tombol tertentu, approval hanya lewat satu alur, atau integrasi antar aplikasi bergantung pada satu konektor khusus. Ketika vendor berubah, proses bisnis ikut terdampak.

4. Tidak ada fallback manual

Automation yang baik seharusnya tetap punya jalur manual untuk kondisi darurat. Jika sistem automation berhenti, tim perlu tahu siapa yang mengambil alih, data apa yang harus dicek, dan langkah apa yang harus dilakukan.

Tanpa fallback, gangguan kecil bisa berubah menjadi hambatan operasional.

5. Monitoring dan SLA sering diabaikan

Banyak workflow automation berjalan tanpa monitoring yang memadai. Tim baru sadar ada masalah ketika pelanggan komplain, laporan tidak masuk, atau task tidak tercipta.

Untuk proses penting, kita perlu memantau status eksekusi, error rate, retry, dan notifikasi kegagalan. Jika memakai layanan berbayar, SLA dan kebijakan support juga perlu dipahami, bukan hanya harga bulanannya.

6. Integrasi terlalu erat dengan satu vendor

Semakin banyak logika bisnis ditanam langsung di platform automation, semakin sulit migrasi dilakukan. Ini bukan berarti semua workflow harus dibangun sendiri dari nol. Tetapi untuk proses kritis, desain integrasi sebaiknya memberi ruang untuk migrasi.

Misalnya, gunakan API yang terdokumentasi, simpan konfigurasi penting di repositori internal, dan pisahkan logika bisnis utama dari tool orchestration jika memungkinkan.

Rekomendasi praktis untuk audit workflow automation

Berikut langkah yang menurut saya layak dilakukan oleh tim bisnis maupun engineering setelah membaca kabar seperti ini.

1. Buat daftar semua workflow aktif

Catat workflow yang berjalan di platform automation apa pun. Untuk setiap workflow, tulis:

  • Nama proses bisnis
  • Pemilik proses
  • Aplikasi yang terhubung
  • Trigger dan output
  • Data yang diproses
  • Dampak jika workflow gagal
  • Alternatif manual jika tersedia

Tujuannya sederhana: jangan sampai ada automation penting yang hanya diketahui satu orang.

2. Klasifikasikan proses berdasarkan risiko

Tidak semua workflow punya tingkat risiko yang sama. Workflow untuk notifikasi internal tentu berbeda dari workflow untuk invoicing, onboarding pelanggan, approval pembayaran, atau sinkronisasi data penjualan.

Saya biasanya membagi proses menjadi tiga kategori:

  • Kritis: jika gagal, operasi bisnis langsung terganggu.
  • Penting: jika gagal, tim masih bisa bekerja tetapi perlu koreksi manual.
  • Pendukung: jika gagal, dampaknya relatif kecil dan bisa ditunda.

Audit dan backup sebaiknya diprioritaskan dari kategori kritis.

3. Ekspor data dan dokumentasikan konfigurasi

Jika platform menyediakan fitur export, gunakan secara berkala. Simpan juga dokumentasi workflow dalam format yang mudah dibaca, misalnya diagram alur, tabel mapping field, dan catatan aturan bisnis.

Untuk workflow penting, screenshot saja tidak cukup. Tim perlu memahami logika proses, bukan hanya tampilan UI.

4. Siapkan fallback manual

Setiap workflow kritis perlu runbook sederhana. Isinya bisa berupa:

  • Kapan fallback manual dijalankan
  • Siapa yang bertanggung jawab
  • Data apa yang perlu diambil
  • Langkah manual yang harus dilakukan
  • Cara memastikan proses selesai
  • Cara mencatat pekerjaan yang dilakukan secara manual

Fallback manual tidak harus elegan. Yang penting bisa menjaga proses tetap berjalan saat sistem otomatis bermasalah.

5. Uji jalur alternatif sebelum dibutuhkan

Alternatif yang tidak pernah diuji sering gagal saat krisis. Jika bisnis sangat bergantung pada satu platform automation, luangkan waktu untuk menguji migrasi kecil ke tool lain atau jalur internal.

Tidak perlu memindahkan semua workflow sekaligus. Mulai dari satu proses kritis, lalu ukur apa saja yang sulit dipindahkan.

6. Kurangi logika bisnis yang terlalu terkunci di tool

Untuk proses yang sangat penting, pertimbangkan arsitektur yang lebih portabel. Misalnya, platform automation digunakan sebagai orchestration layer, sementara aturan bisnis utama tetap berada di aplikasi internal, service kecil, atau script yang terdokumentasi.

Dengan pendekatan ini, jika vendor berubah arah, tim tidak perlu membangun ulang semua logika dari nol.

7. Tinjau SLA, pricing, dan rencana exit

Saat memilih platform automation, jangan hanya melihat jumlah konektor dan kemudahan UI. Tanyakan juga:

  • Apakah ada SLA yang jelas?
  • Bagaimana kebijakan export data?
  • Apakah log eksekusi bisa diunduh?
  • Bagaimana proses offboarding?
  • Apa yang terjadi jika paket berubah?
  • Apakah ada batasan API atau rate limit yang memengaruhi proses kritis?

Pertanyaan seperti ini terdengar administratif, tetapi sangat praktis ketika workflow sudah menjadi bagian dari operasi bisnis.

Penutup

Kabar Relay tutup tidak perlu dibaca sebagai alasan untuk menghindari workflow automation. Automation tetap berguna untuk mempercepat proses, mengurangi pekerjaan repetitif, dan membuat operasi lebih konsisten.

Namun, automation perlu diperlakukan sebagai sistem operasional. Artinya, ia perlu diaudit, didokumentasikan, dimonitor, dan disiapkan rencana cadangannya.

Pelajaran praktisnya sederhana: gunakan platform automation untuk mempercepat bisnis, tetapi jangan biarkan proses penting hanya bisa berjalan jika satu vendor tetap ada, tetap murah, dan tetap mengambil arah produk yang sama.

Referensi

  1. AI automation startup Relay shuts down, staff joins Google's Chrome team
    Publisher: TechCrunch
    URL: https://techcrunch.com/2026/08/17/ai-automation-startup-relay-shuts-down-staff-joins-googles-chrome-team/
    Tanggal publish sumber: 17 Agustus 2026

  2. Relay.app is shutting down
    Publisher: Relay.app
    URL: https://relay.app/
    Tanggal publish sumber: tidak terverifikasi pada halaman yang dapat diakses dalam riset ini