Bäckerherz

Bäckerherz は、シンプルで素敵なアイデアを持った配達サービスです。地元のパン屋さんの焼きたてのパンを、早朝に玄関先まで直接届ける。フィラッハとその周辺で。私のパートナーである Momo と私は、その立ち上げを手伝いました。このページでは、私たちが何に取り組んだのか、そしてそこから毎日の生産と配達を伴う事業について何を学んだのかを語ります。

Bäckerherz がしていること

Bäckerherz で注文すると、朝食の前にパンが玄関に届きます。注文はオンラインで行われ、多くのお客さんが定期注文を利用しています。その裏側では、毎晩本物の仕事が動いています。焼いて、ピッキングして、配達する。すべて街が目を覚ます前に。

技術面でその下を支えていたのは、GraphQL API を備えた自前のバックエンドとカスタマーポータルでした。定期注文は食品事業者向けの配送 ERP と同期され、営業は CRM で動き、通知はメールとメッセンジャーで自動的に送られていました。

私たちがどう手伝ったか

私はソフトウェア側を手伝いました。自動化、バックエンドの注文を取得して分析するためのツール、そして日常のための小さなヘルパーたちです。そのうちいちばん目に見える部分が Telegram の OpenClaw シフト表ボットで、それに加えてデジタルフォームや、同じパターンのほかの小さなツールが続きました。

Momo は事業のオペレーションの心臓部で働いていました。営業から、経営判断のためのレポート、シフト表の調整まで。彼女の改善アイデアの多くは、毎日使われるシステムにそのまま反映されました。

私たち二人がどちらも誇りに思っている章があります。Momo と私は、営業チームの立ち上げと教育に携わりました。電話営業は厳しい仕事です。ふつうの1か月より多くの「ノー」を、午前中のうちに聞くこともあります。それでも次の電話は、感じよく響かなければなりません。そこでモチベーションについて私たちが学んだのはこういうことです。それは頑張れという掛け声からではなく、目に見える数字と小さな成功から生まれるということ。自分の成約率を知っている人にとって、「ノー」は次の「イエス」への途中の一歩でしかありません。良い教育とは結局、数字を勇気が湧くように語ることなのです。

スタートアップは結局のところ数字のゲーム

PhotonQ では状態ベクトルが問題で、Bäckerherz では限界利益が問題でした。どちらも数学ですが、まったく別の数学です。私はこの事業のために予測モデルを作りました。その背後にある仕組みは、どんなスライド資料よりもうまくこのビジネスを説明してくれます。

ロジックはこうです。新しいお客さんは、玄関先での試供品からやって来ます。試供品はひとつごとに、原材料費、労働時間、そしてその周りの電話業務のコストがかかります。試供品のうち一部だけがお客さんになるので、獲得できた顧客ひとりは試供品の何倍もの価値があります。それに対して、定期購入の月あたりの限界利益が積み上がり、それを解約が削っていきます。早く解約する人は、自分の獲得コストをついに取り戻せなかったことになります。この差の中に、獲得コストと固定費、そして最後に残るいくばくかが収まらなければなりません。

まさにここで、感じのよい製品が計算問題に変わります。どのつまみも、ほかのつまみと結びついています。週あたりの試供品を増やせば獲得コストは上がり、コンバージョンが良くなれば下がり、解約率の低下はほかのほとんど何よりも強く効きます。よければ、自分でスライダーを動かしてみてください: 試せる予測モデル。当時私が計算に使った仕組みそのもので、自由に選んだ例の値をあらかじめ入れてあります。

その後どうなったか

Bäckerherz との協働は、いまでは終わっています。この時間を一緒に働けたすべての人に、私たちは感謝しています。毎日の生産と配達を伴う事業のためのソフトウェアについて学んだことは、下にまとめてあります。

私たちが学んだこと

満足しているお客さんがいても、それはまだビジネスモデルではない。 人に愛される製品は、需要を証明します。一件一件の配達の裏にある限界利益が、獲得コストと解約と固定費を支えられるかどうかはまったく別の問いであり、まさにその問いが勝敗を決めます。

生鮮品と物流は、ほとんど失敗を許さない。 ソフトウェアは計画し、リマインドし、分析できます。でもパンを焼いて届けてはくれません。毎日の生産と配達を伴うビジネスモデルを計画する人は、初日からオペレーションの負荷を技術と同じくらい真剣に受け止めるべきです。

自分で作るより、組み合わせる。 CRM、配送 ERP、メッセージングは既製のサービスとして使い、自前のコードは主にその間をつなぐ接着剤でした。小さなチームにとっては、それが正しい道です。借りれば済むものを自前開発するたびに、日々の業務に必要な時間が失われます。

ツールは、チームがもともといる場所に持っていかなければならない。 シフト表は、チームがもともと毎日書き込んでいた場所、つまり Telegram の中で動いていました。デジタルフォームが紙切れを置き換え、誰も新しいアプリを覚える必要はありませんでした。本当に使われる小さなツールは、誰も開かない大きなプラットフォームに勝ちます。

毎日現場に立つ人こそ、どんなソフトウェアが足りないかが見える。 最良の要件はミーティングからではなく、営業とレポートとシフト計画の間を行き来する Momo の日々の業務から生まれました。事業のためのソフトウェアは、その事業を支える人たちと一緒に作るのがいちばんです。

経験は一緒に引っ越してくる。 終わったプロジェクトからは、パターンと、ツールと、事業が本当に必要としているものを見抜く目が残ります。次のときは、それらすべてを荷物に詰めてスタートします。

このセクションの他のページ

OpenClaw シフト表ボット

Bäckerherz のシフト計画のための Telegram ボット。オープンソースのゲートウェイ OpenClaw の上に作られ、その周りに生まれた小さなツーリングも紹介します。