守れるストアプラットフォームを選ぶ

概要

多くのプラットフォーム推奨は、自信に包まれた推測に過ぎません。必要なのは、個人的な好みではなく、あらゆるクライアントに対応できる意思決定プロセスです。このガイドでは、クライアントにプラットフォーム選びを任せることから、決済を後回しにすることまで、ストア構築を狂わせるよくある神話を解説します。プラットフォームの階層を定義し、短いディスカバリーを実施し、決済手数料と入金スピードを含むコストモデルを構築する方法を学べます。さらに、注意点として、標準化すべきは製品ではなくプロセスであることもお伝えします。目標は、次の推薦に説明責任を持たせられる再現可能なフレームワークです。

新しいストアプロジェクトを任されたとします。クライアントが「どのプラットフォームをおすすめしますか？」と尋ねてきたら、実際に何と答えますか？

お気に入りのプラットフォームで答えれば、それは勘に基づいたビジネス上の決定になります。その朝に見つけた比較表で答えれば、他人のビジネスのために書かれたブログに決定を委ねたことになります。クライアントは、自社の商品、決済事情、キャッシュフローに合うプラットフォームを必要としています。そしてあなたには、来月、再来月と訪れる誰にでも対応できるプロセスが必要です。

ほとんどのeコマースプラットフォームに関するアドバイスは、ストアオーナー向けに書かれています。このガイドは、ストアを納品し、アーキテクチャには関心がないクライアントに選択を説明し、最初のミーティングに参加していない開発者に引き継ぐ必要がある人のために書かれています。あなたの仕事は、決定を安易にせずに再現可能にすることです。

その最も早い方法は、多くのチームが抱く前提に切り込むことです。ここに神話と現実を示します。

神話	現実
最高のプラットフォームが一つ存在する。	最適性は、商品の複雑さ、決済ニーズ、誰がストアを運営するかによって異なる。
クライアントがプラットフォームを選ぶ。	あなたがディスカバリーを実施し、説明可能な推薦を行う。
月額料金が最も安いものが勝ち。	総コストには、決済手数料、アプリ、保守、あなたの時間が含まれる。
どの決済ゲートウェイでも機能する。	ゲートウェイの選択は、キャッシュフロー、海外販売、サポート負担を左右する。
ローンチがゴールである。	ローンチは測定と反復の始まりである。
全クライアントに一つのプラットフォーム。	標準化すべきはプロセスであり、製品ではない。

「最高のプラットフォームが存在する」は心地よい嘘

原則：普遍的な最高のプラットフォームは存在しません。あるのは適合カテゴリーだけです。ほとんどのプラットフォームガイドは人気順に選択肢をランク付けし、一番上を選ぶよう勧めます。そのランキングは平均的な読者向けに最適化されており、あなたは平均的なクライアントと仕事をすることはありません。

代わりにこうしましょう。クライアントに会う前に、ストアの3つの階層を定義します。

第1層：シンプルなストア。数十の商品、地元配送、サブスクリプションなし、小規模チーム。これらのクライアントは、低コスト、迅速なセットアップ、すぐに使える決済処理を必要とします。このカテゴリーには、Square OnlineやEcwidのような初心者向けのホステッドオプションが含まれます。これらは、技術的な経験のない起業家にとって優れた出発点としてよく説明されています。

第2層：成長中のマーチャント。より大きなカタログ、実際のマーケティング予算、デザイン管理やアプリへの欲求。使いやすさと柔軟性のバランスが取れたプラットフォームが必要です。ここは混雑した中間層であり、あなたのクライアントの大半がここにいます。

第3層：複雑なオペレーション。大規模なカタログ、サブスクリプション、B2B価格設定、国際展開、またはすでにWordPressに組み込まれているチーム。セットアップに時間がかかっても、スケーラビリティとカスタマイズが必要です。

あなたのルール：クライアントを理解する前に階層を選ばないこと。数十の商品を扱うキャンドルメーカーにエンタープライズ向けカタログシステムは不要です。サブスクリプションボックス会社に、地元の受け取り向けに設計されたプラットフォームは不要です。

すべての候補を無料トライアルで試しましょう。マーケティングビデオではなく、商品アップロードの流れをテストします。実際の写真を使って実際の商品をアップロードします。価格を変更してみます。注文を返金してみます。そのテストを乗り越えたプラットフォームが検討に値します。

実例：地元の石鹸メーカーに会ったとします。数十の商品、サブスクリプションなし、ファーマーズマーケットで注文を受け、オンラインで販売して顧客に注文を受け取りに来てもらいたいと考えています。これは第1層です。統合決済を備えたシンプルなホステッドプラットフォームを推奨します。アプリはスキップします。ローカルピックアップを有効にします。1週間でローンチします。あなたはプラットフォームを売り込んだのではなく、適合を売り込んだのです。

「クライアントに選ばせる」は後で高くつく近道

原則：あなたは専門家です。クライアントはこの決定をしたくないからこそ、あなたを雇います。クライアントに選ばせると、その選択の動機（友人からの推薦、ブログ記事、気に入ったロゴなど）を引き継ぐことになります。それらはビジネス要件ではありません。

プラットフォームを指名する前にディスカバリーを実施します。短くても構いませんが、必須にします。カタログ規模、商品タイプ、サブスクリプション、国際配送、現在の注文管理、コンテンツを更新する担当者、月額費用の予算、スケジュールについて尋ねます。また、支払い方法（単発購入、定期支払い、またはその両方）も尋ねます。

回答を1ページの推奨事項にまとめます。1ページに3つの選択肢を提示します。1つ目はあなたの推奨、2つ目は代替案、3つ目は現段階では避けるべきものです。それぞれに「これは適合する理由...」「これは適合しない理由...」を一文ずつ書きます。その後、クライアントに承認してもらいます。これにより、クライアントに決定のオーナーシップを持たせつつ、失敗に導かれることを防げます。

説明可能なプラットフォーム決定には特定の形があります。それは、あなたの好みではなくクライアントの制約を明示します。製品だけでなく、階層を明示します。そして、受け入れたトレードオフを明示します。たとえば、後でサブスクリプションに対応できないシンプルなプラットフォームを選ぶ場合、クライアントは何を失うのかを理解します。説明可能な推薦の構築に支援が必要な場合は、説明可能なeコマースプラットフォーム決定の作り方を参照してください。

「月額料金が最も安い」が一番安いストアとは限らない

原則：月額料金は請求書の中で最も関心が低い数字です。総コストには、決済処理、アプリのサブスクリプション、保守、および自分のセットアップ時間が含まれます。月額料金が安いがアプリが高価なプラットフォームは、基本料金が高くてもアプリが不要なプラットフォームより高くつきます。

決済処理は隠れた変数です。決済ゲートウェイに関する調査は一貫して、取引手数料、入金スピード、国際サポート、サポート品質の4つの要因を指摘しています。入金スピードはほとんどの人が考える以上に重要です。毎週サプライヤーに支払うクライアントは、迅速な支払いを必要とします。数日かけて決済されるゲートウェイは、手数料が少し高いよりも大きな痛みをもたらします。クライアントは、すべての売上が何日も宙に浮くのを見ると、あなたに電話をかけます。入金が早ければ、電話はかかりません。

手数料ページを契約書のように読みます。返金が発生した場合の扱いを尋ねます。チャージバックについて尋ねます。クライアントが他国の顧客を受け入れられるか、通貨換算がどうなるかを尋ねます。国内販売では安いゲートウェイが、国際販売では壊滅的なコストになる可能性があります。

ここで再現可能なプロセスが役立ちます。各プラットフォーム階層のコストテンプレートを作成します。基本プラン、一般的なアプリコスト、平均取引手数料、想定セットアップ時間を書き留めます。テンプレートは四半期ごとに更新します。そうすれば、次の見積もりは推測ではなく計算になります。この種の標準化こそが、エージェンシーのクライアントオンボーディングシステムを再現可能にするものであり、同じ規律をコストモデルにも適用してください。

「決済は後回し」はストアを窒息させる

原則：決済ゲートウェイはビジネス上の決定であり、技術的な詳細ではありません。それは、クライアントがいつ支払いを受け取るか、どの顧客を受け入れられるか、そしてすべての売上からどれだけ手元に残るかを決定します。

決定をプラットフォームとクライアントの現実に結び付けます。ゲートウェイをビジネスにマッチさせます：

• クライアントが実店舗とオンラインの両方で販売する場合、在庫と決済を一元管理できる統合システムを探します。調査によると、Squareはeコマース機能と決済処理を組み合わせた初心者向けのオプションとして優れています。
• クライアントが国際展開やサブスクリプション開始を計画している場合、強力なAPIを備えた開発者向けプロセッサーの方が適しています。Stripeはグローバル決済とサブスクリプションサポートで広く認知されています。
• クライアントにカードが一般的でない地域の購入者がいる場合、信頼とリーチのためにPayPalのような広く認知された電子ウォレットを追加します。

この決定を開発者の個人的な好みに委ねてはいけません。開発者は最高のAPIを持つプロセッサーを好むかもしれませんが、クライアントは最速の入金スピードを持つものを必要とするかもしれません。両方の選択肢を提示し、トレードオフを明確にします。

高くつく間違いは、最後にゲートウェイを選ぶことです。チェックアウトを設計し、すべてをテストした後で、ゲートウェイがクライアントの対象国に対応していないことが判明します。やり直しは高くつきます。ゲートウェイをプラットフォームのディスカバリーの一部にし、土壇場の統合にしないでください。

「ローンチがゴール」はストアが衰退する道

原則：測定計画なしにローンチすることは、ストアを暗闇に放り込むのと同じです。ストアの仕事はローンチ後に始まります。

ローンチ前に、基本を整えます。プラットフォームと連携するアナリティクスを導入します。モバイルビューが使いやすいことを確認します。購入者が尋ねている質問に答える商品説明を書きます。参考として、商品リスティングのヒントは、鍵を引き渡す前に確認する価値があります。

ローンチ後、最初の90日間をサイクルで進めます。1週目：チェックアウトの摩擦を修正します。離脱がどこで発生するかを観察します。初期の顧客全員に何が混乱したかを尋ねます。2週目：トラフィックの発生源を特定します。トラフィックがなければ、問題は製品ページではなくそこです。3週目：どの商品が売れているかを確認します。その結果をカタログに反映します。

オンラインビジネス開始に関する研究は、常に同じアドバイスに戻ります：小さく始め、テストし、測定し、改善する。最初の月に大規模な再設計を計画しないでください。毎週1つの小さな改善を計画します。そのリズムが、ストアが生き残るために必要なフィードバックループを生み出します。

「すべてを標準化する」は罠

原則：標準化はプラットフォームではなくプロセスに関するものです。すべてのクライアントを一つのプラットフォームに強制すると、ワークフローを快適にするためだけに適合していない案件を受けることになります。その後、プラットフォームをクライアントのニーズに合わせるために余分な時間を費やし、クライアントはあなたの硬直性に対して支払うことになります。

現実は範囲です。自分が管理するレイヤーを標準化します：ディスカバリー質問票、プラットフォーム推奨テンプレート、セットアップチェックリスト、QAチェックリスト、そしてローンチ後のレビュースケジュール。2つか3つのプラットフォーム階層を維持し、クライアントが本当にその外側の何かを必要とする場合には、文書化された例外パスを許可します。例外パスは短い段落です：このクライアントがなぜ特別なのか、追加コストはいくらか、誰が承認するのか。

これは逆説的な部分です。多くのエージェンシーチームは「効率的であれ」と聞くと、単一のワークフローを構築して応えます。一つのプラットフォームがあらゆるカタログ規模、あらゆる決済モデル、あらゆるチームのスキルレベルに対応できると自分に言い聞かせます。その信念は、クライアントが反証するまで便利です。狭いプロセスを再現可能なプロセスと混同しないでください。分岐ルールを持つ柔軟なプレイブックは、最初の例外で失敗するスクリプトよりも再現可能です。

一つのプラットフォームがすべてのクライアントに適合するわけではありません。これを受け入れ、画一的なルールではなく階層化されたプロセスを構築するチームは、現実と戦うのをやめるため、再現性で勝ちます。

今週中にフレームワークを構築する

これで各神話に対する修正が得られました。それを行動に移しましょう。

ディスカバリー質問票を作成します。印刷します。次のクライアントコールで使用します。

プラットフォーム階層を定義します。各階層について、適合するクライアントの種類と受け入れるトレードオフを明記した1段落を書きます。

1ページの推奨テンプレートを作成します。次のプラットフォーム提案に使用します。

決済ゲートウェイのルールを設定します。ゲートウェイを自分のAPIの好みではなく、クライアントの決済事情に合わせます。

ローンチ後のスケジュールを選びます。90日間、毎週1つの改善にコミットします。

その後、新しいクライアント3件でプロセスを実行します。各案件後に調整します。フレームワークは最終回答ではなく、改善していくものです。それが、うまく推測するチームと、納品ごとに上達するチームの違いです。