ecforce構築の進め方 — 要件定義から公開後30日までの実務

「ecforce 構築」で調べると、製品の機能紹介と、比較サイトの「ecforceとは／料金／評判」が出てきます。どちらも導入前の判断材料としては役立ちますが、実際に構築を始めたときに必要な情報とは別物です。

ここでは、要件定義から公開後30日までに何をどの順で決めるかを書きます。

製品の仕様と料金は変わります。この記事では個別の仕様を断定せず、確認すべき観点として書いています。最新の仕様は公式資料と実機のデモでご確認ください。

構築の全体像

新規構築とカート移行では、工程の重さが違います。

移行のほうが工程が多く、失敗したときの損失も大きい。新規構築と同じ感覚で見積もると必ず溢れます。

1｜要件定義で決めること

システムの設定に入る前に、事業側で決まっていないと手戻りします。順序はD2C立ち上げで決める順序と同じです。

販売モデル

• 定期便か、頒布会か、都度＋引き上げか、併売か
• 定期の最低継続回数を設けるか
• 単品から定期への引き上げを主導線にするか

引き上げを主導線にするなら、ここで決めておかないと後から作り直しになります。 単品購入者と定期契約者を同一顧客として扱う設計が前提になるためです。

決済手段

カートの機能より先に決めるべき項目です。 使いたい決済手段が定期課金に対応していなければ、他が揃っていても運用できません。

確認すること。

• 使いたい決済手段のうち、定期課金に対応しているのはどれか
• 定期に使えない手段が、定期商品のチェックアウトで非表示になるか
• カード有効期限の自動追従に対応しているか
• 決済失敗時のリトライ回数・間隔を設定できるか

最後の2つは決済失敗を解約にしないに直結します。

商品構成

• SKU数と、定期で扱う商品の範囲
• 回数に応じた同梱物の出し分けをするか
• セット販売・オプションの持ち方

2｜移行の場合の論点

新規構築ならこの節は飛ばせます。

カード情報を引き継げるか

移行の可否を実質的に決めるのはここです。 顧客にカードを再登録してもらう移行は、一度全員に解約してもらうのと同じ効果を持ちます。

• 現行の決済代行と移行先で、トークンの引き継ぎができるか
• できない場合、再登録の案内をどう設計するか（離脱率の見込み）
• 引き継げる場合でも、次回課金日をどう揃えるか

移行するデータの範囲

最後の行が抜けがちです。 稼働中の契約だけ移して、停止中の顧客が消える事故が起きます。

切り替えのタイミング

定期は毎日どこかで課金と出荷が走っています。切り替え日をどこに置くかで、二重課金や出荷漏れのリスクが変わります。

• 課金が集中する日を避ける
• 出荷指示の締切と切り替え時刻の関係を確認する
• 切り替え当日に決済が走る契約をどう扱うか

3｜デザインとLP

ecforceに限らず、定期通販のカートはLPからカートへの導線が売上を決めます。

• LPをカート内で作るか、外部で作って連携するか
• カート画面のカスタマイズ範囲（表示義務を満たせるか）
• スマートフォンでのフォーム入力のしやすさ

表示要件を満たせるかは、デザインの前に確認してください。 2回目以降の価格・支払総額・継続条件を、最終確認画面に出せない構成にしてしまうと作り直しになります。

4｜初期設定で決めること

顧客がマイページでできる範囲

ここを広く取るほど、後のCS工数が減ります。

• 次回配送日の変更、スキップ、周期変更
• 数量・商品の変更
• 支払い方法の変更
• 解約（法令上も到達可能である必要があります）

CRM・ステップメール

配送サイクル上の判断点に合わせて設計します。最小構成は5通です（ステップメール設計）。

構築時に作り込みすぎないこと。 公開後の実データを見てから調整するほうが精度が上がります。最初は判断点を埋める最小構成で十分です。

広告計測

• CVタグを申込完了ではなく決済完了で発火させる
• 獲得チャネルを契約データに紐づける（後で実質CPAを出すため）
• 可能ならオフラインCVを媒体に返す設計にしておく

2つ目を後から足すのは難しいので、構築時に入れてください。

5｜テストで必ず通す業務フロー

機能の確認ではなく、自社の注文を1件、最初から最後まで通すのが目的です。

8を飛ばさないでください。 決済が通っていない注文が出荷される事故は、定期通販で最も起きやすいものの一つです。仕様書ではなく、実際に失敗させて挙動を見てください。

10ができないと、公開後に継続率の測定ができません。

6｜公開後30日でやること

構築は公開して終わりではありません。最初の30日で見る数字が、その後の改善の基準になります。

30日の残存率が、以降すべての改善の基準線になります。ここを測れる状態にしておくことが、構築のゴールです。

7｜自社で構築するか、外部に頼むか

判断軸は工数ではなく、上の1〜5を自社で決め切れるかです。

外部に頼んでも、販売モデル・決済手段・引き上げ設計を決めるのは事業側です。ここが曖昧なまま発注すると、要件が固まらず期間だけ延びます。

外部に頼む価値があるのは次の場合です。

• 移行で、カード情報の引き継ぎと切り替え設計の経験が必要
• 表示要件を満たすLP・カート構成の判断が必要
• 公開後の計測設計まで含めて任せたい

逆に、新規構築でSKUが少なく、決済も標準的なら、自社で立ち上げてから改善に外部を使うほうが早いこともあります。

よくある質問

構築期間はどれくらいかかりますか

要件定義がどこまで決まっているかで大きく変わります。販売モデル・決済手段・移行データの範囲が決まっていない状態から始めると、その決定に時間の大半を使います。逆にここが固まっていれば、構築そのものは想像より短く済みます。

移行で顧客のカード情報は引き継げますか

現行の決済代行と移行先の組み合わせによります。引き継げない場合、顧客に再登録を依頼することになり、実質的に一度全員に解約してもらうのと同じ影響が出ます。移行の可否を判断する最初の確認項目にしてください。

定期の一時停止中の顧客はどうなりますか

移行の見落としで最も多い箇所です。稼働中の契約だけ移して停止中の顧客が消えると、復帰の機会を失います。移行対象に含められるか、事前に確認してください。

公開前に何をテストすればよいですか

機能の一覧確認ではなく、自社の注文を1件、申込から2回目配送・周期変更・決済失敗・解約まで通してください。特に決済を実際に失敗させて、出荷が止まるかを確認することが重要です。

---

構築の進め方や移行の判断で詰まっている場合は、現状をお聞かせいただければ、どこから決めるべきかの整理をお返しします。システム選定の段階であれば、カート・基幹システム選定シートもあわせてご利用ください。