問い合わせは昼夜を問わず届く。返す速さと正確さが、そのまま信頼になる。分かっていても、現場には三つの壁がある。
受信箱は増える一方。急ぎの一通が、その他の中に埋もれる。気づいたときには、商機が冷めている。
文面の質も、判断の基準も、担当者しだい。忙しい日の返信と、落ち着いた日の返信は、同じ品質ではない。
誤送信は一通で信頼を失う。だから「AIに全部任せる」という選択は、はじめから存在しない。
だからメルバンは、送信の一歩手前で必ず止まる。
読む・分ける・書くまでを AI が行い、送るかどうかは、人が決める。
メルマガや広告は自動で除外。電話番号しかない案件は「架電のお願い」として通知。修正はスレッドに一言 ─ 書き直して、再び承認へ。そして毎時の見張りが、異常のときだけ知らせる。正常なら、無音。
処理の流れ ─ スクロールで進みます
新しい画面を覚える必要はない。いつもの Slack に承認だけが届き、ボタンひとつで完結する。
「気をつける」ではなく「そもそも起こらない」。メルバンの安全は、運用の注意ではなく仕組みの形で保証される。
送信の引き金は、人の承認だけ。AIがどれほど自信を持っても、承認ボタンが押されるまでメールは一通も外に出ない。
認証情報や口座情報のたぐいを、AIが文面に書くことは構造的に禁止。うっかりも、悪意も、入り込む余地がない。
同じ下書きは、一度しか送れない。承認済みの案件をもう一度承認しても、二通目は出ない。押し間違いが事故にならない。
複数の宛先にも、まとめ送りはしない。一通ずつ間隔を空けて送り、相手のサーバーにも自社の評判にも負荷をかけない。
実際の決済事業のメール窓口で、受信から承認・送信までを毎日こなしている仕組みを、そのまま提供する。
着信を3分間隔で確認し、AIが下書きを
添えてSlackへ。人は読んで、決めるだけ。
過去の見逃し事例を再現した検証で、
見張りが異常を知らせるまでの実測値。
送信の引き金は、人の承認だけ。
構造上、起こらない。これからも。
※私たち自身が、決済事業のメール窓口で毎日運用しています。上記はその実測・検証値です。
受信箱の見張りは毎時・年中無休。分類・下書き・承認・送信は全件記録され、あとから辿れます。
通数・体制・つなぎ込む環境に合わせて、個別に設計します。