これまでのところ、これらの各プロセスは個別のシステムが担当しています。登録済みメールのサービス、送信または注文処理を使用するには、それぞれとの統合が必要です。さらに、クライアントが「ワンストップショップ」ベースでメールのすべての機能に確実にアクセスできるようにしたいと考えています。このアイデアを実装するために、私たちはあなたに伝えたい統合プラットフォームを作成しています。
統合を「1つのウィンドウ」で組み合わせます
すべてのメールサービスへのアクセスを容易にするために、次のようなシステムが必要です。1）全員のビジネスプロセスを深く掘り下げることなく、Mail APIをStore APIに接続します。 2）すべてのサービスを「1つのウィンドウ」で接続します。これらのタスクは、統合プラットフォームによって解決されます。
現在、個別のコネクタを作成して、Dispatch、Fulfillment、Electronic Registered LetterでクライアントをAPIと統合しています。各サービスには独自のサービスがあります。コネクタは、ストアとポストがお互いを理解するのに役立つ「トランスレータ」です。クライアントAPIからの情報をフォーマットに復号化してから、反対方向に復号化します。
これらのコネクタの1つを作成して、BeruマーケットプレイスをSendingに接続しました。これは、部門への配達用の小包の準備を自動化するサービスです。コネクターはYandex APIからXML形式でデータを受信し、JSONに変換して送信アカウントに転送し、クライアントのプロセスに合わせて作業手順を調整します。
メールには、トラック番号の割り当て、システムへのデータの送信、データのトラッキングへの転送など、いくつかのアクションがあります。店舗で：注文して住所を確認し、送料を表示して追跡番号を取得します。MailおよびShopプロセスのこれらのアクションは、順序が異なり、異なる方法で呼び出される場合があります。最初のステップでは、住所をチェックして関税を計算する必要があり、ストアは最初に注文を作成します。2つのシステムが相互に理解できるように、これらの手順を調整するにはヘルプが必要です。
ストアは「モスクワからサラトフに重量1 kgの新しい小包を作成する」というメール要求を送信し、コネクターはそれを変数「新しい小包を作成する」「ルート：モスクワ-サラトフ」「重量：1 kg」に配置します。これは、APIで理解できます。倉庫から商品を保管および送信するためにフルフィルメントに接続したい場合は、別のコネクターを作成する必要があります。
メールサービスに接続する通常のプロセス
良いニュースは、コネクタが特定のAPI形式（XML、JSONなど）用に記述されているため、同様の要件を持つクライアントで再利用できることです。ただし、これが機能するためには、すべてのメールサービスが通信し、既製のコネクタが接続されるカーネルを作成する必要があります。統合プラットフォームの基盤であるこのコアは、一般的な郵便注文管理システムになります。次に、接続プロセスは次のようになります。
統合プラットフォームを介したすべてのメールサービスへの接続
プラットフォームは、アナリストが特定のアクションのビジネスプロセスを構築するBPMNシステムの原理で動作します。それはあなたが任意のフォーマットから望ましいものにデータを変換することを可能にします。手動で行う必要があるのは、注文管理用の変数を組み合わせるだけです。
コネクタを使用して、データ形式を変換し、アクションの順序を比較します。これには1〜2か月かかります。また、統合プラットフォームを使用すると、プログラマーの関与を最小限に抑えながら、複雑な開発をせずに1〜2週間ですべてのシステムに新しいクライアントを接続できます。
注文による作業の構造の変更
現在、すべてのメール操作は異なるシステムによって制御されており、それぞれが独自のステップを担当し、残りのシステムとデータを交換しません。 OMSはすべてのタスクを組み合わせ、1つのポイントからそれらを使用します。
統一注文管理システムは、メールエコシステム内のすべての顧客ニーズをカバーします。 1つの倉庫から在庫残高を受け取り、フルフィルメントに転送し、出荷の準備をして、配送用に発送することができます。また、内部プロセスの機能を拡張します。これにより、Postがまだ提供していないサービスを起動できます。かさばる商品の配送、部門から特定の受取人への宅配便などです。
一般的な郵便注文管理システムは、すべての着信タスクを受け入れ、優先順位と期限を決定し、誰がいつタスクを転送するかを決定し、受領から完了までの順序のすべての変更を制御する多腕のオペレーターと考えることができます。
OMSスキーム
たとえば、エレベーターなしで25階まで上がる必要のある冷蔵庫の配送の申し込みを受け取りました。ポストには、そのような大きな製品の配送サービスはなく、独自の引越業者もありません。 OMSは、パートナーの中から適切な請負業者を選び、その仕事を彼に指示します。そして、パートナーが自分の車に収まらない小包の注文を受け取ったとき、私たちは自分の注文を受け取り、自分の輸送を再ロードできます。各OMS参加者は顧客と請負業者の両方の役割を果たすことができるという事実により、それぞれのリソースを最適に使用するために、Postとパートナー間で注文を分配する機会があります。
ポスト内のOMSパイロットは翌月に開始されます。その後、OMSの注文ライフサイクルとクライアントのビジネスプロセスを組み合わせる統合プラットフォームの開発を開始します。すぐに、1つの単純な統合で複数のメールサービスに接続できるようになります。
Open Mail API
コネクタは、独自のAPI標準を持つオンラインプラットフォームでのみ必要です。このような制限がない場合は、倉庫、仕分けシステム、またはワークフローを、オープントラッキングAPIおよび小包発送APIを介してデータ交換に接続できます。
この機会にオゾンを使用します。通常のAPI機能を使用して、郵便局を介して毎月300〜400,000の小包を送信する巨大な市場向けの小包の作成、準備、追跡のチェーン全体を閉じることができました。
- API - OZON . – , . , .
- OZON.
- API OZON . , , , .
APIは、独自の注文管理システムを持つ顧客によって使用されます。ストアが人気のあるCMS（InSales、amoCRM、ShopScript、1C-BitrixまたはCS：Cart）のいずれかで実行されている場合は、公式のMailモジュールに基づいて動作するアプリケーションを使用できます。
CMSプラットフォーム上のストア用のモジュール
モジュールは、パッケージのパラメーターをストアバスケットから関税、時間計算サービス、追跡サービスに送信します。そこから、配達時間と費用に関する情報を取得し、それを送信の個人アカウントに転送します。そこで、優先的な準備が行われます。住所ラベルが形成され、トラック番号が割り当てられます。
シップメントの個人アカウントから、ドキュメントと追跡データがストア管理システムのインターフェースに返されます。売り手は、通常のCRMで小包の配送用のラベルを印刷し、トラック番号を顧客に転送できます。
ブランチ選択ウィジェット
購入者がサイトを離れずにすべての注文データを入力すると、購入への変換率が高くなります。配達登録の段階で、最寄りの支店の住所、郵便番号、営業時間を覚えたり、販売者のWebサイトの外でこの情報を探したりする必要がないように、郵便局の地図と注文の発行場所のウィジェットを使用できます。
クライアントはカードのブランチを選択し、それに関する情報（住所、営業時間、支払い方法、およびコストと配達時間）を確認します。これらは、オープンAPIサービスtariff.pochta.ruおよびdelivery.pochta.ruから取得されます。
バイヤーは1つのウィンドウですべての重要な情報を受け取ります-部門の期間、コスト、スケジュール
Webサイトやアプリケーションにウィジェットをインストールするのに特別な知識は必要ありません。コンストラクターは数回のクリックで構成され、widget.pochta.ruで使用できます。
ビジネスからのほとんどすべてのリクエストを解決する一連のソリューションがありますが、そこで止まらず、顧客のための単一のエントリポイントを作成します。これにより、企業はロジスティクスをプロセスに簡単に統合するためのツールを受け取り、Postは自社の製品とサービスを促進および開発するためのもう1つの強力なチャネルとなります。
このアプローチを共有し、全国の何百ものオンラインストアで使用されるサービスの変革に参加したい場合は、Postal Technologiesチームでお待ちしています。ロシアの9つの都市の空席は、ウェブサイトhr.pochta.tech/vacanciesで確認できます。