通販の基幹を、どこまで持つか。受注から債権・倉庫作業まで、Vegas が業務としてカバーする範囲を13のカテゴリで掲載しています。
各項目は「できること」と「事業者にとっての意味」で書いています。
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| 受注チャネルの統合 | ECサイト・コールセンター(電話受注)・CSV一括取込のどれで入った注文も、同じ受注データとして扱う | チャネルごとにシステムが分かれない。売上・在庫・顧客が一本化される |
| 受注登録・修正 | 管理画面から受注の新規登録・内容修正ができる。項目単位で入力チェックが働く | オペレーターのミスを、システム側で止める |
| 受注ステータス管理 | 受注 → 確定 → 出荷 → 請求 → 債権 まで、状態を持って進む。状態が変わる条件はルールとして定義されている | 「今どの注文が、何で止まっているか」が常に分かる |
| 複数お届け先・分割配送 | 1受注に複数のお届け先を持たせ、お届け先ごとに出荷を分けて作る | ギフト・まとめ買い・実家配送に標準対応できる |
| 受注の一括取込 | CSVで受注をまとめて登録。取込結果は取込履歴で確認できる | 外部モール・紙の注文・キャンペーンの一括投入に対応できる |
| 保留・差戻 | 受注を保留(入力中へ戻す+保留理由・保留日時を記録)できる。出荷・請求など下流へも波及する | 「一旦止める」が、システム上の正式な状態として残る |
| キャンセル | 受注のキャンセルが、出荷・債権・販促(値引・ポイント)へ自動で波及する | 手作業での取消漏れが起きない |
| 受注検索・抽出 | 条件を組んだ検索と、CSV出力ができる | 施策の効果検証や問合せ対応が、画面で完結する |
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| 定期契約の管理 | 定期契約を受注とは別のデータとして持ち、契約単位で状態を管理する | 「注文の集まり」ではなく「契約」として LTV を見られる |
| 次回受注の自動生成 | 契約の周期に従って、次回の受注を自動で作る | 定期の締め処理が不要になる |
| 周期・お届け日の変更(1回とばす) | 配送間隔は「○日ごと」「毎月○日」「毎月第○週○曜日」の3方式。次回お届け予定日は契約途中でも変更できる(マイページ・管理画面の両方)。作成済みのお届け受注を取り消せば、次のお届けタイミングの受注を自動で作り直す(=1回とばす) | 解約理由の上位「今回は要らない」を、解約させずに受け止められる。とばしても契約が切れないことが、状態遷移の定義として保証されている |
| 解約・停止 | 契約中・受注作成中・作成済・出荷済の、どの段階からでも解約に入れる。解約に伴う権利・ポイントの扱いもルール化されている | 解約時の返金・ポイント処理が属人化しない |
| 定期回数に連動した施策 | 「定期○回目」「契約別○回目」「累計定期購入回数」を条件に販促を出せる | 3回目に増量、6回目にギフトなど、継続率の施策を設定だけで打てる |
| 二重生成の防止 | 次回受注を作る条件に「進行中の定期受注が存在しない」ことが入っている | 手作業や再送で、注文が二重に立つ事故が起きない |
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| 顧客マスタ | 顧客情報、複数住所、支払手段、ハッシュタグ(自由タグ)を管理する | セグメントをタグで切れる |
| 名寄せ | 同一人物と思われる顧客を検出して統合する | 重複顧客による誤配・重複販促を防げる |
| 顧客ランク | 購買実績・定期契約の状態から、顧客ランクを自動算出する(判定期間つき) | ランク別の送料無料・優待を、運用で回せる |
| ポイント | 付与・使用・失効、失効予定の可視化、履歴の管理 | ポイントを外部サービスに頼らず、内製で回せる |
| 顧客権利 | 「この顧客は、この特典を1回使える」といった権利を持たせ、行使済みかを管理する | クーポンより柔軟な One-to-One 施策ができる |
| 問合せ管理 | 問合せの記録・検索・出力。顧客に紐づいて残る | コールセンターの応対履歴が、顧客軸で残る |
| 媒体送付歴(DM履歴) | どの顧客にどの媒体(DM・同梱物)を送ったかを記録し、次の施策の条件に使える | 「同じDMを二度送る」を防ぎ、送付歴で出し分けできる |
| メール送信 | 取引メール(受注確認・出荷通知など)の送信と、送信履歴の確認 | 送った/送っていないが追える |
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| 「条件 × 特典」で組む販促 | 販促を「どういう時に(条件)」「何をするか(特典)」の組み合わせとして設定する。プログラム改修なしで、新しい施策を作れる | 施策のリードタイムが「開発待ち」から「設定作業」になる |
| 条件(26種) | 商品/購入形態(通常・定期)/受注日・お届け日の期間/支払方法/受注種別/購入金額/商品購入金額合計/定期回数(3種)/顧客ランク/ポイント付与可否/誕生月/過去購入回数/商品累計購入回数/媒体(商品単位)/媒体種別/媒体タグ/媒体設定の有無/指定キャンペーンでの購入数/媒体送付歴/顧客権利の未行使 | クーポンコード方式より、条件の幅が広い |
| 特典(14種) | 商品割引(率/固定額/商品指定固定額)/送料の付加・割引・全額無料/代引き手数料の付加・割引/同梱物の付加(商品・数量指定)/ポイント付与(%)/顧客権利の付与/特定商取引法の表示文言の設定/LPクロスセルの出し分け | 値引きだけでなく、同梱物・権利・表示文言まで販促として扱える |
| 媒体(キャンペーン)管理 | 媒体(広告・チラシ・LP)を登録し、受注に商品単位で媒体を紐づける | 広告ごとの受注・売上を、商品単位で追える |
| 同梱物・クロスセル | 条件に合致した受注に、同梱物を自動で付ける。LP上のクロスセル表示も販促設定で制御する | 同梱の指示が、自動で出荷側に流れる |
| 特商法文言の自動設定 | 販促内容に応じた特定商取引法の表示文言を、受注データ側に自動で載せる | 表示義務の抜けを、仕組みで防げる |
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| 販売商品/在庫商品の二層管理 | 「売る単位(販売商品)」と「持つ単位(在庫商品)」を分けて管理する | セット販売・同梱・増量を、在庫を壊さずに作れる |
| リアルタイム在庫引当 | 受注が入った時点で在庫を引き当てる。夜間バッチを待たない | 「買えたのに在庫がない」を減らせる |
| ロット・使用期限(FEFO) | ロット単位で在庫を持ち、引当終了日が早いロットから引き当てる(FEFO) | 健康食品・化粧品・食品の、期限切れロスを抑えられる |
| 安全在庫 | 商品ごとに安全在庫を設定し、引当可能数から除外する | 欠品と過剰在庫の境目を、数値で運用できる |
| 入荷前引当と入荷時の再引当 | 未入荷の予定在庫に対して先に引き当て、実際に入荷した時点で実在庫へ自動で振り替える | 予約販売・入荷待ちの受注を、そのまま流せる |
| 引当のシフト(優先度変更) | すでに引き当てた在庫を、別の受注へ付け替える | 急ぎ・重要顧客への融通が、画面操作でできる |
| 入荷・入庫・出庫 | 入荷予定/入庫/出庫を別々の業務として管理し、倉庫作業と在庫数を突き合わせる | 倉庫の実務単位で、データが残る |
| 販売倉庫 | 複数倉庫を持ち、倉庫単位で在庫・出荷を管理する | 拠点分散・3PL併用に対応できる |
| 配送リードタイム・お届け日算出 | 配送先とリードタイムから、出荷予定日・お届け日を自動算出する。日数などの条件は設定として持つので、変更にプログラム改修は要らない | 「いつ届くか」を、受注の時点で顧客に返せる |
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| 出荷管理 | 受注から出荷データを作成し、出荷指示・実績を管理する | 受注と出荷が、別台帳にならない |
| 配送方法・便種の自動判定 | 商品のサイズ・数量から、配送方法(便種)をシステムが自動で決める。判定に使う閾値は設定値として持つので、コード改修なしで変更できる | 送料の最適化を運用側で回せる。「小さい荷物を大きい便で送ってしまう」が減る |
| 倉庫ごとの取扱便種 | 販売倉庫ごとに「扱える便種・運送会社・発店コード・締め時間」を定義する。希望の配送方法をその倉庫が扱えない場合は、出荷側でチェックが働く | 倉庫ごとに使える配送会社が違っても運用できる。物流会社の切替・追加が設定で済む |
| 出荷データの出力・取込 | 倉庫/配送業者向けのファイル出力と、結果ファイルの取込 | 既存の倉庫会社と、ファイル連携で繋がる |
| 配送ストップ依頼 | 出荷済み・出荷直前の荷物に対する、配送ストップ依頼書を出力する | クレーム・住所不備への一次対応が、定型化される |
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| クレジットカード | カード決済に連携し、受注時のオーソリ(与信)を行う。3Dセキュアにも対応 | カード決済の与信タイミングを、業務に合わせて設計できる |
| Amazon Pay | Amazon Pay での購入・オーソリに対応(ECサイト側の導線を含む) | 会員登録での離脱を減らせる |
| 代金引換 | 代金引換に対応。代引き手数料の付加・割引も、販促で制御できる | 代引き手数料を、販促の武器にできる |
| 後払い | 後払いの発行(請求書)と支払(入金)を、別の業務として管理する。再発行のCSV出力にも対応 | 後払い比率の高い健康食品・化粧品の実務に合う |
| ポイント併用決済 | 購入時にポイントを充当して支払える。コールセンター側でも、請求内容の確認画面で「付与ポイント/利用可能ポイント/利用ポイント数」を見ながら充当できる | ポイントを「使わせる」導線を、ECとコールセンターの両方に持てる |
| 債権管理 | 受注とは別に債権を持ち、入金の取込と債権への反映を管理する。受注確定と同時に債権が自動生成される | 未回収がどこにいくらあるかを、即答できる |
| 督促 | 未入金の債権に対する督促を管理する | 回収業務が、システム上の業務として残る |
| 決済手段の追加が「アプリ追加」で済む | 決済手段はそれぞれ独立したアプリとして実装されている。新しい決済代行会社を使う場合は、その手段のアプリを1つ足せばよく、受注・債権・出荷といった中核の業務アプリには手を入れない | 決済代行会社の乗り換え・追加が、基幹システムの作り直しにならない。手数料交渉で不利にならず、新しい決済手段も試しやすい |
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| 返品受付 | 返品を独立した業務データとして受け付け、在庫・債権へ波及させる | 返品の取りこぼしがなくなる |
| 返金(振込・振替) | 返金の振込・次回注文への振替に対応。振込データの出力まで行える | 返金作業が、経理任せにならない |
| 返品に連動した実績の巻き戻し | 返品に応じて、購入回数・定期回数・ポイントなどの集計が再計算される | 「返品したのにランクが上がったまま」が起きない |
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| 商品LP・ステップフォーム | 単品LPからの直接購入。1ページ完結型とステップ型の両方に対応 | 広告から購入までの距離を、最短にできる |
| LPのフォームを1か所で管理 | LPに置くのは読み込みタグと商品指定のみ。入力フォーム本体(入力チェック・Amazon Pay連携・注文送信・郵便番号検索・3Dセキュア)は提供側が1か所で管理し、全LPへ自動反映される。LPのデザイン・コンテンツ・商品プリセットは事業者側で自由に作成・編集できる | LPを何本作っても、決済と入力チェックの品質が1か所で担保される。フォームに修正が入っても、LP側を個別に直さなくてよい。広告LPを量産する事業者ほど効く |
| カート・購入 | カート、会員/非会員購入、購入確認、完了。決済失敗時の導線も用意 | 一般的なECの購入体験を満たす |
| 会員登録・後追い会員登録 | 購入時の新規登録に加え、購入後に会員化する「後追い登録」に対応 | 単品購入者を会員化して、リピートに繋げられる |
| マイページ | 注文履歴・定期契約・ポイント・お届け先・カード情報・プロフィール・パスワード・メールアドレスの各変更 | 問合せ件数を減らせる |
| 会員専用キャンペーン | 会員だけが見られるキャンペーンページ | 会員化のインセンティブを作れる |
| 問合せフォーム | ECからの問合せが、管理画面の問合せ管理に入る | Web問合せと電話問合せが、同じ台帳に載る |
| パスワード再設定・メール確認 | パスワード再設定、メールアドレス変更時の確認メールのフロー | セキュリティ要件を満たす基本導線 |
| 3Dセキュア(EMV 3-D Secure) | カード決済時に3Dセキュア認証を実施する。認証可否の確認 → カード会社側の追加認証画面の表示 → 認証結果の受取まで。新規購入だけでなく、マイページでのカード情報変更・注文内容変更・定期内容変更にも適用している | カード会社の要件を満たす。不正利用によるチャージバック負担を抑えられる |
| 計測タグ | GA4のデータレイヤー、購入完了画面への埋込タグに対応 | 広告代理店の計測要件に応えられる |
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| RFM分析 | 顧客のRFM(最終注文日・累計購入回数・累計購入金額)と、顧客×商品別のRFM | セグメント配信の土台が、システム内にある |
| 定期・購買実績の集計 | 顧客別/商品別の累計定期購入回数、定期契約の状態、キャンペーン別の購入数量・回数 | 施策の条件として、そのまま使える |
| 集計は「随時」実行 | 集計は夜間バッチではなく、元データが変わった時点で更新される | 「昨日の数字」ではなく、現在の数字で判断・施策実行できる |
| ハッシュタグ集計 | 顧客・商品・媒体・問合せのタグ利用数を集計し、入力時のサジェストに使う | タグ運用が破綻しない |
| 外部サービス連携(MA/CRMなど) | 外部サービスへ渡すデータを「連携用の集計」として定義し、元データが変わったタイミングで自動生成する。連携先の仕様に合わせた項目やタイミングの調整は連携定義の側で行い、受注・顧客といった業務アプリ本体には手を入れない | 使うMA/CRMを後から変えても、基幹側の作り直しにならない。ツール選定を業務都合で決められる |
| 帳票・BI | 業務データは分析用データベースにも反映されており、BIツールから必要な帳票・ダッシュボードを追加定義できる。単票形式の帳票は管理画面から直接出力できる | 「欲しい集計表が出てくるまで数か月」がなくなる。現場が自分で帳票を育てられる |
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| ユーザ・権限(ロール) | 管理ユーザとロール(権限)の管理。権限の一括登録・出力にも対応。ロールには適用開始日時があり、いつからの権限かが残る | 委託先・派遣を含む、多人数の運用に耐える |
| アプリ単位のアクセス制御 | ロールに「利用可能アプリ」を設定すると、ログインしたアカウントに応じてアプリメニューが出し分けられる。メニューに出ないだけでなく、URLを直接叩いても権限のないアプリには入れない | 「見せない」が仕組みで担保される。委託先には受注だけ触らせる、といった運用ができる |
| 画面要素単位の権限制御 | 権限の詳細設定により、ボタン・入力項目のレベルまで活性/非活性・表示/非表示を制御できる。設定はデータとして持つのでプログラム改修は不要。業務ステータスに応じて項目を読取専用・非表示にする制御も併用できる(対象画面から順次適用) | 「この人には確定ボタンを押させない」を、画面を作り分けずに実現できる。内部統制・職務分掌の要求に応えられる |
| ブラック住所 | 出荷しない住所を登録し、受注時にチェックする | 悪質注文・転売への対策になる |
| 郵便番号マスタ | 郵便番号から住所を補完する。マスタは画面から更新できる | 入力ミス・宛先不明を減らせる |
| 設定値の一元管理 | 業務ごとの設定値(選択肢・しきい値)をCSVで一括投入し、世代管理する | 設定変更の履歴が残り、いつからの設定かが分かる |
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| すべての業務操作がAPI | 画面でできることは、すべてAPIでもできる。ECサイトも管理画面も、同じ業務APIを呼んでいる。画面は業務ロジックを持たない | 外部システムやAIエージェントから、業務そのものを実行できる。「画面を人が触る」以外の運用が選べる |
| UIの見せ方は後から変えられる | 業務ルール(遷移条件・チェック・計算)はすべてサーバ側にあり、画面はAPIを呼ぶ薄い層。「同じ業務を、別のボタン名・別の導線で見せる」ことが、業務改修を伴わずにできる | 指摘されたUIを、基幹に触れずに直せる。個社ごとの画面カスタマイズが安全 |
| 時間軸バージョニング | 「いつ時点の業務ルールで動かすか」を指定して実行できる(将来日付のルールでの事前確認を含む) | 料金改定・キャンペーン切替を、本番を止めずに事前検証できる |
| バッチレス運用 | 在庫引当・販促判定・集計が、夜間バッチではなくその都度動く | 締め処理待ちがない。24時間、同じ精度で運用できる |
| 業務ルールの部品化 | 入力チェックと計算が、それぞれ独立した部品になっている。追加は部品を足すだけ | 個社要件の追加が、全体改修にならない。改修コストが読める |
| アプリの増減で拡張する | 外部との接点は「アプリを足す/外す」で対応する設計。決済会社の追加、外部サービス連携の追加、配送状況データの取込は、いずれもこの形。中核の受注・在庫・債権には触らない | 事業の変化(決済会社の変更、物流会社の追加、MAの乗り換え)が、システム刷新の理由にならない |
| 変更履歴・監査証跡 | データの変更履歴とメモを、項目単位・値つきで保持する。人の操作とシステムの後続処理を、操作者を区別して同じ履歴に記録する | 「誰がいつ何を変えたか」に答えられる(監査・クレーム対応)。非同期処理が何をしたかも履歴で追えるので、障害時に説明できる |
| クラウドネイティブなスケール | サーバーレス構成のため、負荷に応じて自動で伸縮する | 広告出稿時のアクセス集中に、サーバー増強なしで耐える |
| 重複配送を前提にした設計 | アプリ間の連携は「同じ通知が二度来ても壊れない」前提で作られている | 障害後の再送で、データが二重にならない |
| 機能 | できること | 事業者にとっての意味 |
|---|---|---|
| 使うアプリを選んで導入する | 36の業務アプリから、事業に必要なものだけを選んで導入する。使わないアプリは載せない | 使わない機能に払わない。事業の規模・業態に合わせて、導入範囲を決められる |
| 選ばなかったアプリは画面にも出ない | ロールの「利用可能アプリ」設定により、導入していないアプリはメニューに現れない(URLの直接指定も遮断) | 導入範囲が、利用者にそのまま見える。「使えない機能が並んでいる」状態にならない |
| 使わないアプリはインフラ費用も発生しない | サーバーレス構成のため、載せていないアプリは動かず、その分の実行費用も発生しない | ライセンス料だけでなく、運用コストも利用範囲に比例する |
| 後から足せる(段階導入) | アプリ間はイベントとデータ変換の定義で繋がっているため、追加は「アプリを載せて連携定義を足す」形。既存アプリの改修を伴わない | 「まず受注・顧客・債権から」→「翌年ポイントと定期」といった段階導入ができる。基幹刷新を一括でやらなくてよい |
| 導入範囲の目安が根拠で示せる | どのアプリが必須でどれが任意かは、稼働中の連携定義から機械的に確認できる | 「うちはこの範囲でいい」を、最初の商談で確定できる |
※ 本一覧は2026年8月5日時点の実装に基づきます。項目の粒度は中分類までで、画面単位・API単位の明細は含みません。
※ 導入範囲・料金は選択するアプリによって変わります。詳細はお問い合わせください。