Apex Automation – Internal Rate Card & Billing Strategy

เนื้อหานี้ออกแบบให้ วิศวกร, PM, Pre-sales และ Team Leads เข้าใจว่า

1. เราตั้ง Rate Card ทำไม

2. ควรคิดงานแบบไหน

3. ทำไมต้องควบคุม man-days

4. ทำไมงาน Apex ถึงต้อง “ทำเร็วและเป็นมาตรฐานสูง”

5. และสิ่งที่ทุกคนต้องระวัง / ต้องสื่อสารกับลูกค้า

เหมาะสำหรับใช้ใน internal wiki, onboarding handbook หรือ training document

1. Why Rate Card Exists (ทำไมต้องมี Rate Card)

Rate Card คือ โครงสร้างราคามาตรฐาน ของ Apex Automation สำหรับงานแบบ project-based และ engineering man-days

อ้างอิง Business Segment Profiles (Apex = Delivery Engine)

Rate Card จำเป็นเพราะว่า:

1) เพื่อให้ราคาในตลาดสม่ำเสมอ

ลูกค้าต้องได้รับราคาใกล้เคียงกัน ไม่ขึ้นอยู่กับว่าเป็นนักขายหรือ PM คนไหนเสนอราคา

2) เพื่อให้วิศวกรเข้าใจ “คุณค่าของเวลา (Engineering Time Value)”

1 man-day = ค่าใช้จ่ายจริงของบริษัท + ความเชี่ยวชาญของทีม + ค่า R&D & Solution Kit ของ Appomax

3) เพื่อป้องกันการ undercharge งานหนัก

บางครั้งงานดู “ง่าย” แต่จริงมี hidden complexity → Rate Card ช่วยให้เราตั้งราคาถูกต้อง

4) เพื่อ align กับ Tech Company model ของ StarSeed

• Appomax = SaaS & IP
• Apex = Implementation Engine
• สิ่งนี้ต้องแยกชัดเจนเพื่อ valuation & IPO readiness

2. Rate Card Structure

Engineering Levels

PM Levels

3. Billing Strategy (กลยุทธ์การคิดเงินลูกค้า)

Apex ใช้ สองโมเดลหลัก:

4. How Engineers Should Think About Time (Mindset)

Not “how long does it take me?”

But: “How long SHOULD this take, based on standards?”

เพราะ Apex ไม่ใช่ automation house แบบดั้งเดิม

เราเป็น Digital Industrial Tech Company → engineer ต้องคิดแบบ scalable

ตัวอย่าง mindset ที่ถูกต้อง

• ทำงานแบบ template-first

• ทำงานแบบ reusable

• อย่าทำซ้ำ ถ้าอะไรทำซ้ำ → ต้อง standardize

• Reuse UI components, scripts, queries, tag models

• ทำ architecture ก่อนเริ่มงานเสมอ

• อย่าทำ custom ถ้าไม่จำเป็น

• ใช้ Solution Kit ของ Appomax เพื่อเร่งการทำงาน

5. Key Internal Policies for Billing

นโยบายนี้เน้น

1. ความยืดหยุ่น,
2. การควบคุมงาน,
3. ความโปร่งใส,
4. การตัดสินใจผ่าน PM,
5. การตั้งราคาโดยสะท้อนความเสี่ยงของ scope creep

Policy 1 — Scope Creep → Don’t Accept Immediately

(Not “charge more immediately”, but “STOP and REVIEW first”)

เมื่อลูกค้าขออะไรเพิ่ม ให้ทุกคนใช้หลักการ:

Step 1 — Engineer ต้องปฏิเสธอย่างสุภาพทันที

ตัวอย่าง script:

• “ขออนุญาตให้ PM ตรวจสอบก่อนนะครับ เพราะอาจเกี่ยวกับ scope และ timeline เดิม”
• ห้ามรับทำทันที
• ห้ามสัญญากับลูกค้า
• ห้ามให้ timeline เอง

Step 2 — PM ต้อง Determine:

Is it (A) Scope creep? or (B) Change that takes similar effort?**

A) True Scope Creep = งานเพิ่มจริง มี effort เพิ่ม

• ต้องประเมิน effort → ทำ Change Request → ส่งอนุมัติลูกค้า

B) Similar Effort Change = งานขยับขยาย แต่ไม่เพิ่มจำนวนวัน เช่น

• เปลี่ยน UI component แต่ไม่ได้เพิ่ม logic
• เปลี่ยนชื่อ tag เปลี่ยน flow แต่ใช้ logic เดิม

PM สามารถอนุมัติภายในได้ ไม่ต้องทำ CR แต่ต้อง adjust plan & document

Step 3 — Approval Required Before Any Engineer Touches Work

• ไม่ว่าเป็น Type A หรือ Type B
• ต้องมี PM Approval ก่อนลงมือทำ 100%

Policy 2 — Engineers never accept any new task without PM review

เหตุผล:

• Engineering time = company money

• Early-stage startups can lose a whole year from one uncontrolled project

• PM คือ owner ของ timeline และ budget

Internal rule: “No PM approval = No Work”

Policy 3 — Rate Must Reflect Risk & Expected Scope Flexibility

ราคาที่เสนอให้ลูกค้าต้องสะท้อนระดับความเสี่ยงของแต่ละประเภทงาน:

Low Risk (Spec ชัด / ไม่ค่อยเปลี่ยน)

• → Rate สามารถลดลงได้เพื่อความ competitive
• → ใช้ได้ในกรณี BD negotiation
• → ความเสี่ยงต่ำ
• → บริหารง่าย
• → สามารถ fixed price ได้

Medium Risk (ขอบเขตนิยามได้ แต่มีแนวโน้มเปลี่ยน)

• → Rate ปกติ (mid range)
• → ต้องเขียน assumption ชัดเจนใน proposal

High Risk (ยังไม่แน่ใจ / ลูกค้าปรับ requirement บ่อย)

• → Rate ควรสูงขึ้น
• → ใช้ time & material (T&M)
• → CR มีโอกาสเกิดบ่อย → ต้องปิดด้วย process

สรุป: Rate = Function of Risk. ไม่ใช่แค่ต้นทุนวิศวกร

Policy 4 — Flexibility is Required, But Always Through PM Governance

เราต้อง flexible เพื่อให้ลูกค้ารู้สึกว่า Apex คือ partner ที่ช่วยได้

แต่ flexible คือ “controlled flexibility”, ไม่ใช่ “free unlimited change”.

Framework:

Policy 5 — BD Negotiation Flow

เมื่อราคาต้องแข่งขันมาก:

Lower rate สามารถทำได้ แต่ต้องแลกกับสิ่งใดสิ่งหนึ่ง:

Option A — ลูกค้าต้องลด scope variation

• → Lock requirement
• → Lock UI, naming, model
• → ไม่แก้ไปแก้มา
• → ไม่มี feature creep

Option B — ลูกค้ายอมรับ 100% ว่าไม่มี CR

→ ทำงานแบบ fixed price with limited changes

Option C — ทำ package แบบ standardized

เช่น

• MES Starter

• IIoT Starter

• UNS Starter

• Ignition Deployment Starter

Standard package = low risk = lower rate possible

6. What We Should Discuss Internally (Topics for Engineer Training)