※ 引述《mrbigmouth (大嘴先生)》之铭言：
: ※ 引述《song7775 (凛透)》之铭言：
: : 想建议把商业季度跟产品上架的时间进行分离
: : 目前因为没跟到第一批次的上架时间导致有产品推不上去
: : 而要等一个星期这段时间内感觉有点亏
: : 能否改成商业季度只是单纯进行营利的结算
: : 产品想上架就上架 固定存在一个礼拜后下架呢?
: : 商业季度跟产品上架的时间是否有一定得绑在一起的必要?
: 这边我要讲解一下现行的推荐票制度，
: 现在每个人每个商业季度总共有几张推荐票，
: 是由“这个季度将会有多少商品上架”来计算的，
: 每上架十个商品，所有使用者就会多一张推荐票，但最少也会有一张。
: 当季度一张推荐票能够产生多少营利额也是在此时算出。
: 现在每个人每季度能用推荐票产生多少营利额是固定值14万，
: 那如果当季度有10张推荐票可用，那每张推荐票就可产生1万4千的营利额。
: 因此，如果想要改为产品能随时上架的机制，
: 你可能要推出配套的可用推荐票数目跟推荐票营利额计算方式。
那不更动计算方式 改变计算用数据取样时间点
流程改成这样不知道如何：
1.开服新创时间 经理人可设定商品 但不会立刻上架
2.设定第一波第一季商品上架设定截止时间(例如开服后48小时)
时间到 这段时间内设定的商品统一上架
3.以前项上架数量计算第一季每人推荐票数并发放
4.第一波上架后到第一季结束前个经理人可以自由上架商品
但不影响第一季推荐票数
5.第一季结算 全商品下架
6.第二季开始 以第一季结算时全商品总数计算第二季推荐票数并发放
7.到第二季结束前个经理人可以自由上架商品 但不影响第二季推荐票数
之后季度重复5.6.7.流程直到重开机

越来越复杂= =

就是用前一季算票数好处是自由 坏处是你季中上架别人可能没票投了

程式上没有问题 只是用前一季算票数实在有点怪啊推荐票数跟当季产品设量有关是有必要的 产品越多就能让人投更多票 跟上季产品数量有关到底是为什么啦！？

不然废推荐票改每季定额奖励金弄成像广告系统..(铜臭味)

虽然不太确定 但其实会想要有即时上架功能应该是为了因应经理人忘记上产品(本次的问题则是系统帮忙新创，大量公司于半夜甚至清晨才创立成功，产品换季时间又刚好是当天早上九点半，导致不少经理人是不方便上架产品的)姑且不论新创成立产品换季这样巧合地促使上架产品困难化剩下会需要产品上架即时化的理由应该只有新创当下无经理无法上架产品，导致下个季度确定经理人时产品已无法设定。若要解决此问题则可考虑新创公司默认经理人为董事长或缩短经理人票选的周期(改为每日更迭)。如此因可有效解决不便上架产品的问题(较即时上架产品功能减少开发困难，并可回避推荐票票数难以设定的问题)因可有效解决(x) 应可有效解决(o)

不求可观营利 只是无产品就毫无营利啊

我的意思是指新创比起老公司有一定劣势存在是可理解的，无产品可营利、股票价值较低(新创合资平均)之类的，而这个劣势存在的理由是你这家公司本来就比其他人晚创。想回避的话就开服当下你跟着创立就好，如果没人要跟导致新创失败，这也是一种人气对比输了的结果。所以其实未必需要去更动现有推荐票模式去使其变得更复杂，不过如果最后有人做了即时上架系统并表决成功那也是OK。只是一种成本的考量，现在要投票的更动这么多，错综复杂的情况下(各项更动之间的影响不好预期)，即时上架功能相较之下其实没有这么迫切这样。