SNS向けのサービスは、商品の画面では作れません

商品の登録画面からSNS向けのサービスを作ろうとして通らない場合、原因はそこです。SNS向けのサービスは商品ではありません。別の記録として、別の画面で作ります。アカウントを並べるときの知識は、ほとんど持ち込めません。

先に、根本的に違う四点を挙げます。

• 枠がありません。一つのサービスは一つの価格で、しかも千件あたりの価格です。
• 保証時間の欄がありません。全部の注文が同じ長さで、出品側では変えられません。
• 審査の列がありません。作成を押した瞬間に公開の対象になります。
• 掲載上限に数えられません。商品には等級ごとの上限がありますが、こちらは対象外です。

画面の場所

出品者の管理画面の左側に SMM Panel という組があり、その中の Services が該当の画面です。パスは /supplier/smm-services です。見出しは SMM Services、その下に「手動と取り込み済みのサービスを管理します」という説明が出ます。右側の Create Service を押すと、Create Manual Service という題の入力窓が開きます。

この組にある残りの二つ、SMM Providers と Import Services は別の話です。上流のパネルから丸ごと取り込む経路で、この記事が扱うのは一件ずつ自分で書く手動の経路のほうです。

なお、この画面の項目名は表示言語の設定によって日本語になったり英語のまま出たりします。以下では画面に出る英語の文字列を先に書き、その意味を添えます。

必須は六項目です

• Service Name(サービス名)。二百字まで。入力例として「Instagram Followers (Premium)」が出ます。この棚では、ここは題名ではなく仕様書として使われています。実際に並んでいるものは、対象の地域、一日あたりの速度、開始までの遅れ、補充の条件まで名前の中に入っています。
• Service Type(受け取り方)。三択で、それぞれ買い手に何を入力させるかが画面に説明として出ます。Default はリンクと数量、Custom Comments はリンクとコメント本文、Subscriptions はユーザー名と最小最大と遅延の設定です。
• Platform(対象のサービス)。選択式で、買い手が見ている一覧と同じ集合から作られています。
• Category(分類)。自由入力か、自分がすでに作った分類から選びます。ここが店頭でのまとまりになるので、同じ対象で他に出しているものと言葉を揃えてください。
• Price per 1000(千件あたりの価格)。一件あたりではありません。棚の全部がこの単位で並ぶので、買い手は他の何社かと並べてこの数字を直接読みます。
• Min Purchase Quantity(最小数量)と Max Quantity(最大数量)。どちらも整数です。手動で作る場合、最大は必須です。上流の業者に繋いだ自動のサービスに限って、最大を空にできます。

任意のものとして、二千字までの説明、アイコンの指定と色、そして表示順があります。表示順は数字が小さいほど上に出ます。

三つのチェックボックスが、この棚で唯一の構造化された約束です

価格の下に Refill Available(補充あり)、Cancel Allowed(取り消し可)、Drip-feed Supported(分割投入対応)が並びます。小さな項目に見えますが、この棚で買い手が絞り込みや比較に使える構造化された情報は、実質これだけです。そして思っているより希少です。

二〇二六年九月一日時点で公開中の三万百十九件を数えました。

• 補充あり 二千六百六十八件。およそ十一件に一件です。
• 取り消し可 一万二千七百七十二件、分割投入 一万一千五百七十八件。どちらもおよそ四割です。

補充の希少さは対象ごとにさらに極端です。二十件以上を持つ対象が三十三ありますが、そのうち十二の対象では、補充ありの出品が一件もありません。つまりそこに一件出すだけで、その対象で唯一の選択肢になります。

ただし守れない約束にチェックを入れないでください。補充と取り消しは、買い手が問い合わせを出す二大理由です。そしてSNS向けの注文には、納品された時点から三日の窓が付きます。この長さは出品側では縮められず、伸ばすこともできません。

Product Type の欄が出ないのは、正常です

入力窓には手動と自動を選ぶ欄がありますが、受け取り方を Subscriptions にしたときにだけ現れます。それ以外では表示されず、記録は手動として作られます。自分の手か自分の仕組みで納品するなら、それが望ましい状態です。

自動を選ぶと、上流の業者とその業者側のサービス番号を指定する必要が出ます。その場合、最大数量はあなたの入力ではなく業者側の設定から来ます。

作成を押したあとに起きることと、起きないこと

ボタンは Create Service です。下書きの状態も、保留の状態も、審査の段階もありません。記録は有効な状態で作られ、すぐ公開の対象になります。

ただし一つだけ見落としやすい条件があります。あなたの店舗が有効で、一覧に載る設定になっている必要があります。店舗が一覧に出ない設定のままだと、サービスは自分の管理画面には見えて、公開の場所にはどこにも出ません。

保証時間の欄が無いのは、設定するものが無いからです。SNS向けの注文は、どの出品でも同じ長さの窓が付きます。アカウントの商品は逆で、出品ごとに自分で設定します。両方売っている場合、片方の感覚をもう片方に持ち込まないでください。

そして掲載枠の上限にも数えられません。上限に達したときのエラー文の中に、SNS向けのサービスは対象外だと直接書いてあります。百件並べても、商品の枠は一つも減りません。

手動は稀で、そしてそれが機会でもあります

午後を投じる前に、正直な数字を出します。公開中の三万百十九件のうち、手動で作られたものは三十件です。残りの三万八十九件は業者からの取り込みです。注文の側も同じ傾向で、このサイトの全期間で完了した注文のうち、手動で作られたサービスから出たものは三件、取り込まれたサービスからは四千七百五十五件でした。

読み方は二つあり、どちらも正しいです。手動はこの棚を作った方法ではないので、量で自然に流れてくる注文は期待できません。ただし取り込みの棚は他の全員も持っている棚です。公開中のサービスを出しているのは十一社しかなく、対象ごとに見ると最大の一社がおよそ二割から六割を占めています。つまり同じ対象の中で、同じ上流の在庫が何度も並んでいます。取り込みの棚に無いものを名指しで一件書くことが、この棚で唯一、商品として差がつく方法です。

公開される場所と、APIの既定値が隠すもの

公開の一覧はSNS向けサービスの下にあり、対象ごとのページがInstagramのページのような形で並びます。あなたのサービスも他社のものと同じ並びに入り、順番は出品した順ではなく店頭側の並べ方で決まります。

ここで、自分か開発者が公開のAPIから棚を読む場合、結果を根本から変えてしまう引数が一つあります。サービスの取得は、既定では一社分の断片しか返しません。merge=all を付けない場合に返るのは、システム上の代表となる出品者のぶんだけです。

実際に測ると、その既定の断片は三万百十九件のうち七百八十六件、およそ三十八件に一件で、三十五ある対象のうち十四しか含みません。

この引数を落とした連携は、棚が小さいと結論し、多くの対象が存在しないと結論し、拾った価格帯が代表的だと結論します。三つとも外れます。サイト自身のページはこの引数を付けています。作るものも付けてください。なお受け付けられるのは all という文字列そのものだけです。

押す前の確認

1. この棚の書き方に合わせて名前を付ける。対象、届くもの、必要なら地域、速度、補充の条件。
2. 価格を千件あたりで入れ、自分の原価ではなく同じ対象の他の出品と並べて確認する。
3. 最小と最大を正直に入れる。どちらも購入の時点で効く上限と下限です。
4. チェックは守れるものだけ入れる。補充は希少で、そのぶん実際の義務でもあります。
5. 店舗が有効で一覧に載る設定になっているか確認する。ここが外れていると、どこにも出ません。

アカウントの商品も並べる場合、規則はほとんど別物です。商品の設定の記事にまとめました。注文をAPIで捌く側は手動注文のAPIの記事にあります。