アカウント名:
パスワード:
これをやってないということは注文を自動で短
こういう事件を見るたびに思うんですが、 短時間に通常でありえない注文があったら売り切れにしてしまう等の数量制限をかければ大事にはならないはずです。
これをやってないということは注文を自動で短時間に大量に処理できるという「オンラインでの自動注文」の恩恵を最大限に受けている訳だから、表示の確認は最低限やっておく事だし誤表示の場合の損害は当然負うべきリスクだと思います。
言いたい事はだいたい同じようですが、ポイントは 身の丈に合った商売をやるべきだということと、 間に人間を挟む事を省略して儲けようとしているのだから それに替わるチェック機構は組み込むべきだ。の2点ですかね。
# ワンミスで切腹する可能性を減らすような機能追加なら # 売る側は恩恵を受けると思うんですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
数量制限 (スコア:4, 参考になる)
短時間に通常でありえない注文があったら売り切れにしてしまう等の 数量制限をかければ大事にはならないはずです。
これをやってないということは注文を自動で短
Re:数量制限 (スコア:0)
何らかのキャンペーンを張っていたり、話題先行の新製品など
どの程度売れるモノか、予想できない商品というのは結構多いのでは?
アプリ屋としては、通常考えて不要な機能は付けたくないでしょうし
ECサイドとしては、モノは売れるだけ売れたほうが良い訳で
その機能追加で恩恵を受ける人は存在しないのです。流通が確定的、例えば、在庫を確実に持っている場合はそうでしょう。
しかし、注文をある程度予測してメーカに発注する場合はソノ限りではありませんよね。
それと、会社組織を運営できるかどおかの瀬戸際でもあるA社に
ソレを強いるのは酷ではないでしょうかね?(笑
# ナニ事も、ワンミスで切腹しなきゃならんのですか?(爆
POSを導入した頃のコンビニでは
バーコードに登録されている価格と商品に貼られている値札に
誤差があったりしたものですが
ソノ手の間違いは一朝一夕のモノでは無いと思いますけど。
価格交渉を受付ず、注文が強制的にキャンセルとなったコトが問題の本質では?
注文は受け付けたが、価格に誤記があり、コレを訂正して幾らにしますが、如何でしょうか?
とか、
何らかの都合でiPodの生産、及び、入手が困難となった場合など、代替品でどうか、
とか、
そういう、人間的な対応をバッサリ斬り捨てたコトが問題なのでは?
# 最終的に、人間がコンピュータを操っていて
# プログラムとは、人間の意志であるコトを、忘れていませんか?
Re:数量制限 (スコア:1)
言いたい事はだいたい同じようですが、ポイントは
身の丈に合った商売をやるべきだということと、 間に人間を挟む事を省略して儲けようとしているのだから それに替わるチェック機構は組み込むべきだ。の2点ですかね。
# ワンミスで切腹する可能性を減らすような機能追加なら
# 売る側は恩恵を受けると思うんですが。
Re:数量制限 (スコア:1)
メーカーは、急にはたくさん作れないですから。
納期半年後でもお客さんは待つでしょうか?
それならそれで、注文殺到しているので納期が確約できません、という形でキャンセルするほうが親切と思います。
または24時間注文を受け付けられる体制を用意して、あくまでも、受注確定は人が責任もってやらないと。