1.愛櫻花申述重點似乎是「系統回饋不明確、也不夠迅速」，因為主訴者守在電腦前數小時，完全不知道是否完成報名難怪感覺沮喪。如果猜的不錯，主辦單位可針對這項意見提供解決方案的行動，而不是一再的說明及解釋。最遺憾的是：今年已成定局，沒辦法挽救了！就這一點來說，主辦單位也有機會向報名失敗的跑友們致意。

2.報名及繳費系統設計各有特徵。國際馬拉松大多是兩段式作業：第一段報名成功及確認錄取、第二段再進行繳費！但是2012太魯閣馬報名系統創意：繳費為憑，搞得雞飛狗跳！其實路跑協會憑藉會員制，資料庫中累計世界級的會員名單為資產。其他社團如果效法，可能抱怨連連而且天下大亂，不像路跑協會依然屹立不搖、穩如泰山。

3.2013京都馬我為團隊14位跑友線上報名，一成功馬上接到回饋：確認並祝賀報名成玏，同時告知何時正式宣告是否錄取！反觀國內報名網，比較少注意訊息回饋。但是該系統進行繳費時就慘了：第一位刷卡成功，系統會直接跳到訂旅館及國際旅行社訊息，無法繼續進行繳費。e-Mail反應及抱怨即時接獲訊息：該系統設計是以「個人報名為主」，因此我必須退出作業系統重行進入才行。

4.總之：即時回饋最重要！人機介面憑直覺，跑馬報名及繳費都會碰到不同的作業設計。同一主辦單位今年與明年報名不見得一樣。系統大多以服務個人為設計，要即時回饋個人訊息。如果貪圖方便請友人集中報名繳費，反而佈滿荊棘。以刷卡為例：一筆一次手續費，我協調團隊一次刷卡對方也不會同意，奈何！

TangST 兄的回應及說法我個人能理解但不能同意

先說明一下我個人是資訊業從業人員, 對 web base 系統開發有 12 年的資歷, 您提到廠商「依以前經驗評估可接受一定流量的報名(同時1200)筆」這個說法, 坦白講以業內人士來說這相當可疑, concurrent 1200 u 這不是一般系統能扛得住的量, 要能扛得住同時 1200 人上線這不但系統硬體要夠力, 頻寬要夠寬, 甚至軟體寫得好壞, 調校得是否恰當都很重要, 一般小型券商的系統搞不好都扛不住同時 1200 u, 報名單位用什麼樣的配備能扛得住??

我在網路上看到另有一說是 1200 筆/小時, 每小時 1200 筆跟同時 1200 人上線兩者之間不可以道理計, 每小時 1200 筆交易找部破爛 pc 當 server 都扛得住, 同時 1200 人上線則是另一回事

承包商不願或無法出具壓力測試報告通常十之八九都有問題, 出個壓力測試報告有何難哉, 弄個工具花個幾個小時時間跑一下數據就出來了, 不提供通常是為什麼這不言而喻

系統設計必有其先天的容量限制, 就算客戶不問, 系統廠商也必需同時應該去測, 否則怎麼會知道可以作多少生意, 同時在即將達到系統最大負荷量前應該要有一些像是限流機制之類的防止措施自動啟動, 這才是正常的作法, 這次的問題則是直接掛點, 您覺得這正常嗎

我再舉一例, 台鐵訂票系統每到春節或連續假期必定塞爆, 使用者罵聲連連, 但是台鐵訂位系統就算塞爆, 最多是慢, 但是絕不會出現像這次的系統錯誤訊息, 這才是一個正常的系統在超量負荷下應有的反應, 而不是像此次的報名系統那個狀況

當然您所提及多少經費取得多少資源的說法這很合理, 也可以被理解及同意, 但是這次的問題其實並不是錢少資源少的問題, 問題處理原則不外乎 "事前預防, 事後處理", 承辦單位事前預防顯有疏失, 但是事後處理失當才是被罵的原因, 且不論回應速度如何, 光是一個朝令系改(先取消半馬, 又宣佈 11/30 24:00 前報名不限額, 但是同時報名系統顯示已額滿不接受報名, 又再改可報半馬同時調整人數上限 ....), 就讓跑友無所適從, 你覺得光在網路上發個抱歉聲明, 能息眾跑友之怒嗎??

信也發出去了，一點回應也沒有，時間一分一秒過去，今天就是第三天，超過期限再告知不也是被取消資格(因為沒匯款)，真的很無奈，我對這種處理方式很不滿意。