こんにちは、Habr。 長い間、この大きくて複雑な記事にどのようにアプローチするかを考えていました。
1年前、古いラッパーで新しいフォーマットの車を注文するサービスを開始することが決定されました。
コールセンターはありません。乗客向けのモバイルアプリケーションはありません。すべての注文は、ロボットが合成および音声認識を使用して電話で行い、かなり大きなソフトウェアパッケージを使用します。
このアイデアは長い間空中にあり、時々異なるソースで表明されていますが、私たちはそれを実装することができました。 このサービスは稼働しており、利益を生み出し、さらに成長します。
市場向けの新しいプロジェクトを立ち上げる方法に興味がある人は誰でも、アナログはありませんが、競合他社がたくさんいるので、猫をお願いします。
開始する
1年半前に転換点が来たので、私たちは積極的にプロジェクトに参加することにしました。 候補者のリストが編集され、激しい議論が始まりました。 そして、最も興味深いのは、現在のプロジェクトがこのリストになかったことです。 1つのプロジェクトで選択が決まり、その後MVPが実装されましたが、「音声合成と認識を使用して、ディスパッチャなしで電話でカーオーダーサービスを作成する」というアイデアが浮上しました。 この考えは、誰にでも実行可能とは思えませんでしたが、私は疑問を抱いていましたが、彼らが言うように、あなたはそれを試さないでしょう-あなたはそれを認識しません。 開発が始まりましたが、これが最初の間違いでした。
最初の都市
そして、アイデアは製品に変わり始めました。 当初、スクリプトを呼び出すために多くの時間が費やされました（そして、無駄に、より重要なことを考える価値がありました）。
旅行を作成するための一般的なスキーム：
- 回路は簡単だった
- 乗客が呼んでいる
- 電話を取ります
- あいさつ
- ロボットは、旅行の開始場所を尋ねます。
- 答えを得る
- 認識してジオコードし、失敗した場合は再度尋ねます
- ロボットは乗客がどこに行くか尋ねる
- 認識してジオコードし、失敗した場合は再度尋ねます
- システムは旅行を作成し、距離、価格、旅行時間を計算します
- ロボットは旅行のパラメーターを乗客に通知し、確認を求めます
- 乗客は同意し、ドライバー配布旅行を送ります
- 電話を下ろす
旅行の一般的なスキーム：
- 最寄りのドライバーを探しています
- 運転手に運転手を渡す
- 運転手が乗る
- 乗客を呼び、車に関する音声データ
- 運転手は運転したことを押します
- 乗客に電話して、車が運転したと声をかけた
- 乗客が座る
- 運転手が旅行の開始を押す
- 最後に、ドライバーは旅行の完了をマークします
- 顧客向けのサービスの最初の外観を得た後、開発を開始しました。
準備する
当初は、このサービスを宣伝する方法、ドライバーを探す方法はわかりませんでした。 また、どれだけ多くの問題を解決する必要があるのかも考えもしていませんでした。
人口50万人の地域センターで開始することが決定されました。
乗客を引き付ける広告は、ソーシャルグループの形式を選択しました。 ネットワーク、コンテキスト広告、アスファルト、バナー。
ドライバーは、Avitoおよびソーシャルのグループを通じて惹かれました。 ネットワーク。 ドライバーが都合の良いときにいつでもラインに入るというスキームが選択されました。
打ち上げと失敗
そして、指定された日付までに、すべての準備が整い、打ち上げ日が来ました。 起動後、すぐに膨大な数の問題が発生しました。
乗客
小さい人たちが電話をかけてきたが、その数は時間の経過とともに大きくなることはなかった。私たちが手に入れることができる広告の量は明らかに財政的に十分ではなかったことが明らかだった。 結局のところ、市の50万ドルの広告予算は1か月あたり少なくとも20万ルーブルである必要があるため、少なくとも6か月間広告する必要がありました。 すなわち 最低広告予算120万ルーブル。
ドライバー
私たちは、ドライバーがいると素朴に信じていました。 実際、私たちは多くの人々を獲得しました。 多くはオンラインに行かず、多くはオンラインになったばかりで、隣にある注文さえ受けませんでした。 また、ドライバーで大都市を均一にカバーすることもできませんでした。
その結果、サービスを展開するには、少なくとも10人のドライバーを給料に支払うか、追加料金をドライバーに導入する必要があることが明らかになりました。
私たちはたくさん試しました：
- 彼らは自分で運転し、乗客から自分に合ったものとそうでないものを見つけました。
- 彼ら自身が乗客であり、ドライバーと交流しました。
- 彼らは友人や知人を集めました。
- 他のサービスの所有者と通信しました。
1か月の稼働後、サービスは1日に10件の注文を記録し、バケットを1滴落とすだけでした。
しかし、それは彼らが関与した業界の最初のアイデアを獲得しました。
ロールアウトにはかなりの予算が必要であることが明らかになりました。 50万の都市で6か月間、最低でも200万ルーブルです。 そして、そのような資金の入手可能性でさえ、高い競争を考えると、プロジェクトの成功を保証しませんでした。
2番目の都市（灰からのフェニックスの復活）
最初のパンケーキはゴツゴツしたものでしたが、知識と経験を得て、資金の形での輸血がまったくない作業システムを手元に持っていました。 技術的な観点から、すべての問題を解決し、次に何をすべきかという疑問が生じたことは注目に値します。
ためらうことなく、私たちは非常に良い本「マーケティング戦争」からのヒントの1つに従いました。
50万の都市は私たちにとっては強すぎること、そして魚が多すぎて戦う意味がないことが明らかになりました。 このアイデアは、最大10万人の都市で手を試すために選ばれました。
準備する
今回は、すべて開発からではなく、市場インテリジェンスから始まりました。 約3万5千人の人口を抱える地域の地区センターが選ばれました。 また、必要に応じて旅行できるように、彼らは私たちに近い都市を探しました。
私たちは街に旅行し、仕事をしなければならない状況を評価し、競合他社を探しました。
プロモーションの主なソースが特定されました。 小さな町で判明したように、プラスとマイナスほど多くはありません。 一方では、必要なお金が少なく、他方では、大規模な広告キャンペーンを迅速に行うことは困難です。
ここでの競争では、すべてがはるかに簡単でした。 このような小都市でのすべての競合サービスは、ライブコントローラーを備えたトランシーバーで動作します。 ここで、当社の製造可能性は大きな競争上の優位性になりました。
乗客を引き付ける広告は、ソーシャルグループの形式を選択しました。 ネットワーク、コンテキスト広告、バナー、ラジオ。
業務プロセス
ドライバーの場合、無料のスケジュールでの作業を含むスキームが依然として選択されました。
市には単一の価格が設定されていたため、住所を認識せず、単にサウンドファイルをドライバーに送信することができました。
移動時間と距離を数える必要がなくなりました。 市外への旅行の価格は、ドライバーによって決定されました（しかし、無駄でした）。
打ち上げ
そして今、地域センターでの失敗から数ヶ月後、小さな町での新しい試み。 打ち上げ前に、ドライバーの会議が開催され、仕事のルールが明確になりました。
打ち上げは活発で、初期にはすでに1日20件の注文がありました。
成長
2か月間、このサービスは小さな町のリーダーになり、私たちのおかげで他のサービスは閉鎖され始めました。 競合他社の呼び出しは、サービスを購入するというオファーから始まりました。 それは成功するでしょう、モデルは完全に報われました。 もちろん、成長の過程で、膨大な数の技術的およびビジネス上の問題に遭遇しましたが、すべてが解決しました。 そして重要なことは、注文を受け入れるロボットに怖がらなかった人々は、すぐにそれに慣れました。
イノベーション
小さな町で、私たちは大きな一歩を踏み出しました。
収益化
当初、収益化モデルはまったく考えられておらず、大きな失敗でした。 最初は、ドライバーは無料で旅行し、通信事業者、音声合成および音声認識サービス、ホスティングなどに支払いました。 モデルが機能していることが明らかになったときに、収益化が導入されました。
シフト
重大な問題の1つは、ドライバーが希望するときに列に並ぶことであり、それを制御する方法はありません。 シフトを導入し、同時にそれらを支払わせることが決定されました。 1日を4時間の6シフトに分割しました。 シフト価格は乗客の呼び出し回数に依存していました。
割引き
トリッキーな割引システムが導入されました。 シフトごとのドライバーの場合（たとえば、1日あたりの2番目のシフトは30％安くなります）乗客の場合、n回目の旅行ごとに割引が導入されました。
距離からの価格
当初、市内には単一の価格がありました。 その理由は、小さな町の住民の技術的な困難と精神性でした。 その後、サービスが成長したときに、出発地と目的地の住所を認識するシステムを導入し、価格の距離依存性に切り替えました。 小都市では、キロメートルごとに価格を設定しても意味がありません。価格のグラデーションを作成するだけで十分です。
第三都市
小都市の経験では、モデルはスケーリングの準備ができていると判断され、今では新しい都市を接続するだけで十分です。
準備する
彼らは遠くまで行かず、100 kmの別の地区センターが選ばれました。 人口は約33千人でした。 プロモーション方法は同じでした。 乗客と運転手との仕事のスキームは、変更しないことを決定しました。
起動と失敗
第三都市での打ち上げは、予期しない新たな問題を明らかにしました。
最初の問題
適切な数のドライバーを採点しなかった、または入力したと思った。 多くの人が電話をしましたが、本当に働きたい人はほとんどいませんでした。 私たちの推定によると、その後、彼らが働くと言うすべての人々のうち、実際に働くのは約10〜20％だけです。
第二の問題
打ち上げは2月23日の3日前に行われ、祖国の擁護者の日が来ると、注文のピークがありました。
その日、60人の乗客が電話をかけましたが、ドライバーはライン0に入りました。これは完全な驚きでした。 その後、3月8日になり、再び注文の大部分が配達されませんでした。
すべてが「シールド付きまたはシールド付き」という表現になり、最終的にシールドになりました。
リハビリテーションの試み
頑固にあきらめず、緊急対策を開始しました
- 旅行のドライバーへの追加支払い
- 週ごとのドライバーの補足
- ドライバーを引き付けるために新しいチャネルをテストしました
主な問題はドライバーでした。彼らは何らかの方法で働きたくありませんでした。 この都市では、ロシアの主要な問題に直面しています 。 人々は働きたくないのです 。
彼らはしばしば仕事を得るために私たちに電話します、そして、あなたがお金を稼ぐために働く必要があるとわかるとき、我々は彼らが思う
第三の都市のための数ヶ月の闘争は失敗しました。 現時点では、すべてがチャンスに任されています。 数人のドライバーがそこで働いており、1日あたり10〜30件の注文があります。 この失敗は非常に良い教訓であることが判明しました。
第4都市
そして今、私たちは1つの都市-成功と1つの都市-失敗を持っています、そして私たちはさらに進む必要があります（最初のことは考慮していません）。 得られた経験は、何をすべきか、何をすべきでないかを示しています。 私たちは先に進みます...
転倒の月
すべてが落ちたのはとても興味深い月でした。
- サーバールームの照明をオフにしました。
- インターネットをオフにしました。
- クラウドテレフォニーは機能しませんでした。
- 私たちのサービスは落ちました。
時には午前3時に来て、問題に対処する必要がありました。
テクノロジーとアーキテクチャ
プロジェクトのサーバー部分の基礎はSOAが採用しました。 主なサービスが強調されました：
コア-注文、ドライバー、乗客と連携します。 さまざまな注文分散アルゴリズムと永続的なマスターデータストレージがあります（PHP）
Dialog-リアルタイムで通話を処理するサービス。乗客との対話用のさまざまなスクリプトがあります。 （Javascript）
音声は音声認識のためのサービスです。 （Javascript）
Geoはジオコーディングサービスです。 （Javascript）
ロガー-ロギングサービス（FluetnD、Elastic、Kibana）
ボット-ドライバー用の電報ボット。 （Php）
ルート-最適なルートを見つけるためのサービス。 （Javascript）
開発と生産の両方にDockerを使用することも決定されました。
ドライバーの申請は、Telegramに基づいて行われます。
計画
小さな目標：これらは10人の都市で、人口は最大10万人です。 現時点では、これをどのようにどのような時間枠で達成するかについての計画がすでにあります。 具体的には、2つの計画があります。 最初の計画：すべてを自力で、そして自分のお金で行う方法、2番目の計画は投資の誘致に結びついています（現在、私たちは積極的に探しています）。
大きな目標は、人口が最大10万人のロシアの都市の30％です。 しかし、この目的のために、すでに投資のみの計画があります。 ここで数十年成長するために自分で。
また、サービスを改善し、新しいサービスを追加し、関連業界に参入するための多くの計画があります。
タクシー会社向けのプラットフォームを徐々に開発および準備しています。これにより、オペレーターの数を減らし、低コストで小規模なサービスを作成できます。
もちろん、他の分野で音声合成と認識を行うプロジェクトが既にいくつかあり、それらを開発して市場に投入するつもりです。
結論
音声合成と認識、およびある種のAIが既に使用されている新しいユーザーインターフェイスが登場しました。 AmazonのAlexaを考えてみてください。 音声インターフェースに目を向けることは非常に重要です。 技術の現在の開発により、小規模な組織でも収益性の高いアプリケーションを見つけることができます。
練習が示すように、人々がロボットと話をしないというすべての恐怖は根拠がありません。
PS：
コミュニティに興味がある場合は、プロジェクトテクノロジー、周辺のクラウドテレフォニーを使用する際の問題、および興味深く、別の記事に十分な情報が含まれているものに関する記事をさらに準備できます。