การเลือกผู้ให้บริการเรียกเก็บเงินก็เป็นการตัดสินใจเกี่ยวกับโครงสร้างพื้นฐานที่สำคัญที่สุดอย่างหนึ่งของธุรกิจที่กำลังเติบโต ซึ่งหากตัดสินใจได้ถูกต้อง คุณก็จะมีระบบที่พร้อมขยายการรองรับไปพร้อมกับโมเดลค่าบริการของคุณ จัดการการปฏิบัติตามข้อกำหนดทั่วโลกโดยอัตโนมัติ และช่วยให้มีรายรับหมุนเวียนอย่างน่าเชื่อถือ แต่หากตัดสินใจผิด คุณก็จะต้องเสียเวลาหลายเดือนในการแก้ไขงานและมีรายรับรั่วไหลได้

เราจะให้ Stripe Billing ไว้เป็นจุดอ้างอิงตลอดคู่มือนี้ ให้ถือเป็นตัวอย่างที่เป็นรูปธรรมว่า แพลตฟอร์มการเรียกเก็บเงินที่ครบครันจะมีลักษณะอย่างไรเมื่อใช้งานจริง

เทมเพลตนี้จะช่วยให้คุณจัดการคำขอข้อเสนอโครงการ (RFP) สำหรับผู้ให้บริการเรียกเก็บเงินได้อย่างเป็นระบบแบบครบวงจร ตั้งแต่กฎการบริหารจัดการเบื้องต้นไปจนถึงข้อกำหนดอย่างละเอียด รายการเชิงพาณิชย์ และการให้คะแนนในการประเมิน โดยเป็นการต่อยอดฟังก์ชันต่างๆ ที่สำคัญสูงสุดต่อธุรกิจที่มีการชำระเงินตามรอบบิลในปี 2026 ได้แก่ ค่าบริการตามการใช้งานและแบบมีหลายแอตทริบิวต์ การกู้คืนการชำระเงินที่ขับเคลื่อนโดยแมชชีนเลิร์นนิง (ML) การวิเคราะห์รายรับแบบเรียลไทม์ การปฏิบัติตามข้อกำหนดด้านภาษีทั่วโลก และข้อกำหนดใหม่ๆ เช่น การค้าแบบใช้เอเจนต์และผลิตภัณฑ์ทางการเงินที่ผสานรวมในตัว

คุณไม่จำเป็นต้องยึดตามเทมเพลต RFP นี้เสมอไป เทมเพลตนี้เป็นเพียงคำแนะนำที่คุณสามารถ (และควร) ปรับเปลี่ยนไปตามความต้องการของคุณโดยเฉพาะ แต่ละส่วนก็จะมีคำแนะนำเพื่อช่วยคุณเขียนคำถามต่างๆ ที่จะให้คำตอบที่เป็นประโยชน์ ไม่ใช่แค่คำโปรยทางการตลาดเท่านั้น ให้กรอกรายละเอียดเกี่ยวกับโปรเจ็กต์ของคุณในช่องว่าง ให้พยายามลงรายละเอียดในจุดที่สำคัญที่สุด และตัดข้อมูลที่ไม่เกี่ยวข้องออกไป หากใช้อย่างเหมาะสม เทมเพลต RFP นี้จะช่วยคุณประหยัดเวลา ทราบผู้ให้บริการที่เหมาะสม และมีข้อมูลประกอบการตัดสินใจขั้นสุดท้ายได้ดีขึ้น

สารบัญ

• หน้าปก
  
• ส่วน A: คำแนะนำด้านการบริหารจัดการ
  
• ส่วน B: ภาพรวมและขอบเขตในการทำงาน
  
• ส่วน C: คำแนะนำเกี่ยวกับข้อเสนอ
  
• ส่วน D: ขั้นตอนการประเมินผล
  
• ส่วน E: ข้อกำหนดหลัก
  
• ส่วน F: การนำไปใช้และการสนับสนุน
  
• ส่วน G: รายการเชิงพาณิชย์
  
• ส่วน H: โปรไฟล์ผู้ให้บริการ
  
• ส่วน I: บุคคลอ้างอิง
  
• ส่วน J: ภาคผนวก
  

หน้าปก

หน้าปกมีไว้เพื่อบอกผู้ให้บริการทราบว่าตนกำลังดูอะไรอยู่และกำลังพูดคุยกับใคร ให้ใส่หัวเรื่อง RFP, ชื่อบริษัทของคุณ, ประกาศแจ้งการรักษาความลับสั้นๆ และรายละเอียดการติดต่อของบุคคลที่จัดการขั้นตอนนี้ วันที่ก็สำคัญเช่นกัน ให้ระบุวันที่ออกและวันครบกำหนดไว้ตั้งแต่แรกเพื่อไม่ให้ใครอ้างได้ว่ามองไม่เห็น ให้จัดทำหน้าปกให้กระชับ โดยควรเน้นไปที่การให้ข้อมูลเบื้องต้น ไม่ใช่การเน้นแสดงฝีมือของทีมออกแบบ

สิ่งที่ควรใส่ไว้ในส่วนนี้มีดังนี้

• หัวเรื่อง: RFP สำหรับ [โปรเจ็กต์/บริการ/ผลิตภัณฑ์]
  
• องค์กรที่ออก: [บริษัทของคุณ]
  
• ประกาศแจ้งการรักษาความลับ: (ถ้อยคำสั้นๆ ที่เป็นการผูกมัดตาม NDA)
  
• บุคคลติดต่อ: [ชื่อ ตำแหน่ง อีเมล หมายเลขโทรศัพท์]
  
• วันที่ออกและวันครบกำหนด
  

คุณอาจต้องการออกแบบเอกสาร RFP ให้สื่อถึงแบรนด์ของคุณ ในกรณีนั้น โครงร่างในแต่ละส่วนอาจเป็นรากฐานที่ดีได้ ด้านล่างนี้ เราได้เพิ่มสำเนาตัวอย่างที่คุณใช้ได้เอาไว้ให้

วันที่สำคัญๆ

รูปแบบของข้อมูลที่ส่ง
คุณจะต้องส่งคำตอบทั้งหมดแบบอิเล็กทรอนิกส์ทางอีเมลในรูปแบบ PDF เทมเพลตค่าบริการและการให้คะแนน (มีให้แยกต่างหากเป็น Excel) จะต้องแนบมาด้วยโดยคงรูปแบบเดิมไว้

แบบแผนในการตั้งชื่อไฟล์
[ชื่อผู้ให้บริการ]–[ชื่อโปรเจ็กต์]–RFP–Response–[วันที่].pdf

วัตถุประสงค์ของ RFP นี้
[บริษัทของคุณ] กำลังมองหาพาร์ทเนอร์ด้านการเรียกเก็บเงินที่สามารถรองรับธุรกรรมแบบหลายสกุลเงินที่ปลอดภัย ผสานการทำงานกับระบบภายในได้ง่ายผ่าน API ที่ทันสมัย และมีความน่าเชื่อถือสูง การตรวจจับการฉ้อโกงแบบเชิงรุก และความโปร่งใสของข้อมูลในภูมิภาคต่างๆ

เอกสารนี้จะสรุปข้อกำหนด เกณฑ์การประเมิน และขั้นตอนการส่งข้อเสนอ

ประกาศแจ้งการรักษาความลับสั้นๆ
RFP นี้มีข้อมูลที่เป็นความลับและเป็นกรรมสิทธิ์ของ [บริษัทของคุณ] โดยมีไว้เพื่อใช้ในการจัดเตรียมคำตอบเท่านั้น ห้ามแจกจ่าย RFP นี้ให้กับผู้ใดที่ไม่ใช่ผู้ที่เกี่ยวข้องโดยตรงในการจัดเตรียมข้อเสนอ การยอมรับ RFP นี้จะถือว่า ผู้รับตกลงที่จะปกป้องข้อมูลนี้ด้วยความรอบคอบแบบเดียวกับที่ปกป้องข้อมูลที่เป็นความลับของตนเองเป็นอย่างน้อย

ส่วน A: คำแนะนำด้านการบริหารจัดการ

ส่วนนี้จะเป็นตัวกำหนดกฎเบื้องต้น ก่อนที่ผู้ให้บริการจะใช้เวลาตอบสนอง ก็ต้องทราบก่อนว่าขั้นตอนนี้ทำงานอย่างไร สิ่งที่จะพบ รวมถึงลำดับเวลาของขั้นตอนนี้ ให้ระบุให้ชัดเจน เพราะหากมีความคลุมเครือก็จะทำให้เกิดปัญหาตามมาได้

ข้อมูลที่ต้องระบุมีดังนี้

• ภาระหน้าที่ในการรักษาความลับและการไม่เปิดเผยข้อมูล
  
• การจำกัดความรับผิด
  
• ลำดับเวลาของ RFP พร้อมวันสำคัญต่างๆ
  
• รูปแบบของข้อมูลที่ส่งและแบบแผนในการตั้งชื่อไฟล์
  
• บุคคลติดต่อและกฎการสื่อสาร
  
• แบบฟอร์มตอบรับผู้ให้บริการ
  

ลักษณะตัวอย่างเป็นดังนี้

A.1 คำชี้แจงในการรักษาความลับและการไม่เปิดเผยข้อมูล

ข้อมูลทั้งหมดใน RFP นี้ถือเป็นความลับและมีไว้เพื่อช่วยผู้ให้บริการในการจัดเตรียมคำตอบเท่านั้น ผู้ให้บริการจะต้องไม่เปิดเผย ทำซ้ำ หรือแจกจ่าย RFP นี้หรือส่วนหนึ่งส่วนใดของ RFP นี้ให้กับบุคคลที่สามโดยไม่ได้รับความยินยอมอย่างเป็นลายลักษณ์อักษรล่วงหน้าจาก[บริษัทของคุณ] หากผู้ให้บริการใส่ข้อมูลที่เป็นกรรมสิทธิ์ไว้ในข้อเสนอ ควรมีข้อความกำกับข้อมูลนั้นๆ ไว้อย่างชัดเจน ซึ่ง[บริษัทของคุณ]ก็จะปฏิบัติตามนั้น

A.2 การจำกัดความรับผิดทางการเงิน

RFP นี้ไม่ใช่ข้อเสนอในการทำสัญญา [บริษัทของคุณ]ไม่มีภาระหน้าที่ในการเข้าทำสัญญาหรือชดเชยค่าใช้จ่ายต่างๆ ที่เกิดขึ้นในการจัดเตรียมคำตอบ ผู้ให้บริการจะต้องรับผิดชอบต่อค่าใช้จ่ายของตนเองแต่เพียงผู้เดียวตลอดขั้นตอนนี้

A.3 ลำดับเวลาของ RFP

A.4 แนวทางการส่งข้อมูล

• ต้องส่งข้อเสนอทั้งหมดทางอีเมลไปที่ [ที่อยู่อีเมลในการติดต่อ]
  
• ผู้ให้บริการต้องแจ้งว่าได้รับแล้วภายใน 3 วันทำการนับจากวันที่ออก
  
• ต้องส่งคำถามอย่างเป็นลายลักษณ์อักษรภายในวันที่ซึ่งระบุไว้ในข้อ A.3
  
• การสื่อสารทั้งหมดต้องผ่านผู้จัดการ RFP ที่กำหนด โดยไม่อนุญาตให้ติดต่อโดยตรงกับพนักงานจาก [บริษัทของคุณ] คนอื่นๆ ในระหว่างระยะเวลาการประเมิน และอาจส่งผลให้ถูกตัดสิทธิ์ได้
  

A.5 เอกสารที่ต้องใช้ในการส่งข้อมูล

ผู้ให้บริการแต่ละรายต้องใส่เนื้อหาต่อไปนี้ไว้ในข้อมูลที่ส่งมา

A.6 ภาพรวมในการประเมิน

[บริษัทของคุณ] จะประเมินข้อเสนอเกี่ยวกับฟังก์ชันการเรียกเก็บเงิน สถาปัตยกรรมทางเทคนิค ความครอบคลุมด้านการปฏิบัติตามข้อกำหนดทั่วโลก ประสิทธิภาพในการกู้คืนการชำระเงิน ความเชี่ยวชาญในการรายงานรายรับ แนวทางการปรับใช้ และเสถียรภาพของผู้ให้บริการ โดยจะให้ความสำคัญกับผู้ให้บริการที่แสดงให้เห็นถึงการเพิ่มประสิทธิภาพด้วยแมชชีนเลิร์นนิง การวิเคราะห์แบบเรียลไทม์ ประสิทธิภาพที่เหนือชั้นของ API และความพร้อมสำหรับขั้นตอนการเรียกเก็บเงินแบบใช้เอเจนต์และที่เริ่มต้นโดย AI

A.7 การรับทราบจากผู้ให้บริการ

ผู้ให้บริการต้องกรอกและส่งแบบตอบรับด้านล่างภายใน 3 วันทำการหลังจากได้รับ RFP นี้

เราได้รับ RFP ที่มีชื่อว่า "[ชื่อ RFP]" แล้ว และยืนยันว่าเราตั้งใจที่จะ ☐ ส่ง / ☐ ไม่ส่งคำตอบ

ชื่อบริษัท: ________________________

ตัวแทนที่ได้รับอนุญาต: ________________________

ตำแหน่ง: ________________________

วันที่: ________

ส่วน B: ภาพรวมและขอบเขตในการทำงาน

ภาพรวมที่คลุมเครือจะให้ข้อเสนอแบบกว้างๆ โปรดให้ข้อมูลที่เกี่ยวข้องแก่ผู้ให้บริการเพื่อสามารถตอบกลับได้แบบตรงจุด เช่น โมเดลธุรกิจ ความซับซ้อนของค่าบริการ ตลาดที่คุณให้บริการอยู่ และปัญหาแบบเจาะจงที่คุณกำลังหาทางแก้อยู่ คุณอาจเลือกใส่รายละเอียดเพิ่มเติมเพื่อปรับแต่งภาพรวมได้ เช่น สำนักงานใหญ่และตลาดที่สำคัญ รายรับประจำปีโดยประมาณหรือปริมาณการเรียกเก็บเงิน และทีมภายในองค์กรที่เกี่ยวข้อง (เช่น การเงิน, วิศวกรรม, การปฏิบัติตามข้อกำหนด, RevOps, ความสำเร็จของลูกค้า)

ลักษณะตัวอย่างเป็นดังนี้

B.1 ประวัติความเป็นมาของบริษัท

[บริษัทของคุณ] เป็นบริษัทเทคโนโลยี[ระดับโลก/ระดับภูมิภาค]ที่ดำเนินงานใน[ใส่ตลาด] โดยให้บริการแก่[ใส่ประเภทลูกค้า]ด้วย[ใส่คำอธิบายผลิตภัณฑ์หรือบริการ] การดำเนินการเรียกเก็บเงินของเราครอบคลุมตลาด [X] แห่ง และรองรับ[อธิบายโมเดลค่าบริการ เช่น แพ็กเกจตามการใช้งาน การชำระเงินตามรอบบิล และแบบไฮบริด]

• ขณะนี้เราออกใบแจ้งหนี้ให้กับลูกค้า [ปริมาณโดยประมาณ] ต่อเดือนใน [X] สกุลเงิน เรากำลังมองหาพาร์ทเนอร์ด้านการเรียกเก็บเงินที่มีแพลตฟอร์มที่ขยายการรองรับไปพร้อมกับธุรกิจของเราได้ จัดการกับตรรกะค่าบริการที่ซับซ้อนได้โดยไม่ต้องดำเนินการแบบเฉพาะตัว และปฏิบัติตามข้อกำหนดด้านภาษีและระเบียบข้อบังคับต่างๆ ของแต่ละตลาดที่เราดำเนินงานอยู่
  

B.2 วัตถุประสงค์ของโปรเจ็กต์

RFP นี้มีไว้เพื่อระบุแพลตฟอร์มการเรียกเก็บเงินที่รองรับการเติบโตในขั้นต่อไปของเราได้ ระบบในปัจจุบันของเรา[อธิบายปัญหา (เช่น ไม่สามารถจัดการกับค่าบริการตามการใช้งานได้ ขาดการปฏิบัติตามข้อกำหนดด้านภาษีทั่วโลก ไม่ผสานการทำงานเข้ากับระบบ ERP ของเรา ไม่สามารถรองรับการเปลี่ยนแปลงการชำระเงินตามรอบบิลที่เริ่มโดย AI ได้)]

พาร์ทเนอร์ที่เหมาะสมของเราจะมีคุณสมบัติดังนี้

• การรองรับโมเดลค่าบริการที่ยืดหยุ่น ได้แก่ ตามการใช้งาน อัตราคงที่ แบบแบ่งระดับ หลายแอตทริบิวต์ และไฮบริดในแพลตฟอร์มเดียว
  
• การคำนวณภาษีทั่วโลกแบบอัตโนมัติและการปฏิบัติตามข้อกำหนดเกี่ยวกับใบแจ้งหนี้ เช่น ภาษีการขาย ภาษีมูลค่าเพิ่ม และรูปแบบเฉพาะประเทศ
  
• อัตราการกู้คืนการชำระเงินระดับแนวหน้าของอุตสาหกรรม ซึ่งขับเคลื่อนโดยตรรกะการลองซ้ำด้วยแมชชีนเลิร์นนิงและการจัดการการติดตามหนี้อัจฉริยะ
  
• ทั้งทีมด้านเทคนิคและไม่ใช่ด้านเทคนิคสามารถเข้าถึงการวิเคราะห์การชำระเงินตามรอบบิลและรายรับแบบเรียลไทม์ได้
  
• การผสานการทำงานกับ CRM, ERP, คลังข้อมูล และระบบบัญชีของเราได้อย่างง่ายดายผ่าน API ที่มีการจัดทำเอกสารเป็นอย่างดี
  
• ความพร้อมสำหรับการค้าแบบใช้เอเจนต์ ซึ่งก็คือระบบของผู้ให้บริการที่รองรับการชำระเงินตามรอบบิลที่เริ่มต้นโดยเอเจนต์ AI หรือขั้นตอนการทำงานอัตโนมัติ
  

B.3 ขอบเขตในการทำงาน

งานหลักที่ต้องส่งมอบ:

• การจัดการวงจรการชำระเงินตามรอบบิลแบบครบวงจร เช่น การทดลองใช้ การอัปเกรด การดาวน์เกรด การหยุดชั่วคราว และการยกเลิก
  
• การรองรับโมเดลค่าบริการที่หลากหลาย เช่น การเรียกเก็บเงินตามการใช้งานที่มีการรวมข้อมูลแบบละเอียด ค่าบริการแบบแบ่งระดับ ค่าบริการแบบหลายแอตทริบิวต์ (เช่น สิทธิ์ใช้งานพร้อมการใช้งาน) และแพ็กเกจแบบผ่อนชำระ
  
• การคำนวณภาษีอัตโนมัติและการออกใบแจ้งหนี้ฉบับแปลในทุกตลาดที่ [บริษัทของคุณ] ดำเนินงานอยู่
  
• การผสานการทำงานกับ [CRM, ERP, คลังข้อมูล และระบบบัญชี]ผ่าน API ที่มีการกำหนดเวอร์ชันและจัดทำเป็นเอกสาร
  
• การรับรู้รายรับที่เป็นไปตามมาตรฐาน ASC 606 และ IFRS 15 เช่น การรายงานแบบลำดับขั้น (Waterfall) และการจัดการรายรับแบบรับล่วงหน้า
  
• การกู้คืนการชำระเงินที่ขับเคลื่อนด้วยแมชชีนเลิร์นนิง พร้อมการกำหนดเวลาลองซ้ำแบบอัจฉริยะ การรองรับโทเค็นเครือข่าย ระบบอัปเดตข้อมูลบัตรอัตโนมัติ และลำดับการติดตามหนี้ที่กำหนดค่าได้
  
• แดชบอร์ดแบบเรียลไทม์ที่ครอบคลุม MRR, ARR, การเลิกใช้บริการ, คอนเวอร์ชันจากการทดลองใช้ และประสิทธิภาพในการกู้คืน
  
• พอร์ทัลแบบบริการตนเองของลูกค้าสำหรับการชำระเงินตามรอบบิลและการจัดการการชำระเงิน
  

งานที่ส่งมอบหรือไม่ก็ได้:

• การคาดการณ์รายรับและการให้คะแนนการเลิกใช้บริการเชิงคาดการณ์ที่ขับเคลื่อนด้วย AI
  
• การรองรับโครงสร้างบัญชีแบบหลายหน่วยงานหรือแบบมีลำดับชั้น
  
• ฟังก์ชันการเรียกเก็บเงินแบบผสานรวมในตัวสำหรับแพลตฟอร์ม SaaS ที่ขายต่อให้กับลูกค้าของตนเอง
  
• การรองรับการค้าแบบใช้เอเจนต์ (API และรูปแบบการตรวจสอบสิทธิ์ที่อนุญาตให้เอเจนต์ AI เริ่มต้น แก้ไข และยกเลิกการชำระเงินตามรอบบิลในนามของลูกค้าได้)
  
• ผลิตภัณฑ์ทางการเงินแบบผสานรวมในตัว (การรองรับผลิตภัณฑ์ในการออกบัตร การเงิน หรือการให้กู้ยืมที่ผสานการทำงานกับการเรียกเก็บเงิน)
  

B.4 งานที่อยู่นอกขอบเขต

กำหนดรายการยกเว้น เพื่อไม่ให้ผู้ให้บริการคิดค่าบริการหรือรับผิดชอบต่อรายการดังกล่าว ตัวอย่างบางส่วนมีดังนี้

• โครงสร้างพื้นฐานในการประมวลผลการชำระเงินหลัก (จัดการแยกต่างหากโดย Stripe)
  
• การตรวจจับการฉ้อโกงนอกเหนือจากมาตรการควบคุมระดับการเรียกเก็บเงินแบบมาตรฐาน
  
• * ฟังก์ชัน ERP บัญชีแยกประเภททั่วไปอย่างเต็มรูปแบบ*
  

B.5 ผลลัพธ์ที่ต้องการ

• อัตราการกู้คืนการชำระเงินสูงกว่า [X]% ภายใน 6 เดือนนับตั้งแต่การเปิดตัว
  
• การคำนวณภาษีอัตโนมัติที่ครอบคลุมตลาด [X] แห่งเมื่อเปิดตัว
  
• เวลาในการออกใบแจ้งหนี้สำหรับโมเดลค่าบริการใหม่ลดลงจาก [สถานะปัจจุบัน] เป็น [เป้าหมาย]
  
• การรายงานรายรับที่เป็นไปตามมาตรฐาน ASC 606 อย่างเต็มรูปแบบโดยไม่ต้องกระทบยอดด้วยตนเอง
  
• เวลาหน่วงในการตอบสนองของ API ต่ำกว่า 300 มิลลิวินาทีที่ p99 สำหรับการดำเนินการเรียกเก็บเงินทั้งหมด
  

ส่วน C: คำแนะนำเกี่ยวกับข้อเสนอ

หากคุณไม่ได้ระบุว่าอยากให้ข้อเสนออยู่ในรูปแบบใด คุณก็จะได้ข้อมูลแทบทุกรูปแบบ ตั้งแต่สไลด์ 5 หน้าไปจนถึงไฟล์ PDF 200 หน้า ส่วนนี้จะช่วยให้ข้อมูลที่คุณได้รับอยู่ในรูปแบบเดียวกัน เพื่อให้ใช้เปรียบเทียบผู้ให้บริการได้

ลักษณะตัวอย่างเป็นดังนี้

C.1 รูปแบบและโครงสร้างของข้อมูลที่ส่ง

ข้อเสนอแต่ละรายการต้องเป็นไปตามโครงสร้างนี้

• ข้อมูลสรุป (ไม่เกิน 3 หน้า)
  
• คำตอบสำหรับข้อกำหนดทั้งหมดในส่วน E โดยระบุหมายเลขให้ตรงกัน
  
• เทมเพลตค่าบริการฉบับสมบูรณ์ในรูปแบบ Excel
  
• โปรไฟล์ผู้ให้บริการและข้อมูลสรุปทางการเงิน
  
• ลูกค้าอ้างอิงอย่างน้อย 3 ราย
  
• เอกสารประกอบ เช่น ใบรับรองการปฏิบัติตามข้อกำหนด กรณีศึกษา และข้อความที่ตัดตอนมาจากเอกสาร API
  

ข้อมูลที่คลาดเคลื่อนอย่างมีนัยสำคัญ หรือขาดองค์ประกอบที่จำเป็นอาจถือว่าไม่เป็นไปตามข้อกำหนด

C.2 ข้อกำหนดในการจัดรูปแบบ

• คำตอบเชิงอธิบายในรูปแบบ PDF, เทมเพลตค่าบริการในรูปแบบไฟล์ Excel
  
• ขนาดฟอนต์ขั้นต่ำ 11 pt โดยเว้นระยะขอบ 1 นิ้ว และต้องระบุหมายเลขหน้า
  
• ตัวเลขทางการเงินทั้งหมดต้องเป็นสกุลเงิน USD เว้นแต่จะระบุไว้เป็นอย่างอื่น
  
• การตั้งชื่อไฟล์: [ชื่อผู้ให้บริการ]–Billing–RFP–[วันที่].pdf
  

C.3 คำแนะนำเกี่ยวกับเนื้อหาของข้อเสนอ

ข้อมูลสรุป

• อธิบายให้ชัดเจนว่า โซลูชันของคุณจะจัดการกับเป้าหมายของ [บริษัทของคุณ] อย่างไรในส่วน B
  
• ให้เริ่มด้วยผลลัพธ์ที่วัดผลได้ (เช่น อัตราการกู้คืน การปรับปรุงอัตราการอนุมัติ และลำดับเวลาการปรับใช้) ไม่ใช่คำอธิบายผลิตภัณฑ์
  
• ใส่วิสัยทัศน์ของคุณสำหรับการร่วมงานครั้งนี้ตลอดช่วงเวลา 3 ปี
  

ภาพรวมของโซลูชัน

• อธิบายวิธีที่แพลตฟอร์มของคุณจัดการกับสถานการณ์เกี่ยวกับค่าบริการที่ซับซ้อน เช่น การวัดปริมาณตามการใช้งาน ค่าบริการแบบหลายแอตทริบิวต์ การเปลี่ยนแพ็กเกจก่อนหมดรอบ และการจัดการการให้สิทธิ์
  
• ให้รายละเอียดเกี่ยวกับสถาปัตยกรรม API, ความพร้อมใช้งานของ SDK, ความน่าเชื่อถือของ Webhook และความเท่าเทียมระหว่างสภาพแวดล้อมแซนด์บ็อกซ์กับแบบใช้งานจริง
  
• อธิบายว่าฟังก์ชันแมชชีนเลิร์นนิงของคุณช่วยปรับปรุงการกู้คืนการชำระเงินและลดการเลิกใช้บริการได้อย่างไร
  

แผนการปรับใช้

• ระบุลำดับเวลาฉบับร่างของโปรเจ็กต์พร้อมช่วงเวลาสำคัญต่างๆ ได้แก่ การกำหนดค่า, การผสานการทำงาน, การทดสอบ, UAT และการเปิดตัว ให้ระบุความรับผิดชอบของผู้ให้บริการและลูกค้าในแต่ละช่วง
  

การรักษาความปลอดภัยและการปฏิบัติตามข้อกำหนด

• ยืนยันการปฏิบัติตามข้อกำหนด PCI DSS เวอร์ชัน 4.0 (มีผลบังคับใช้ในเดือนมีนาคมปี 2024) และวันที่ตรวจสอบล่าสุด
  
• อธิบายตัวเลือกถิ่นที่อยู่ของข้อมูลและมาตรการควบคุมความเป็นส่วนตัวสำหรับ GDPR และ CCPA
  
• ให้รายละเอียดเกี่ยวกับขั้นตอนการรับมือเหตุการณ์และลำดับเวลาในการแจ้งเตือนลูกค้าของคุณ
  

ฟังก์ชันของ API และฟังก์ชันสำหรับนักพัฒนา

• ระบุเกณฑ์มาตรฐานของเวลาหน่วง API (p50, p95 หรือ p99) ประวัติระยะเวลาให้บริการ และแนวทางของคุณในการกำหนดเวอร์ชันและความเข้ากันได้แบบย้อนหลัง
  
• ใส่ลิงก์ไปยังเอกสารประกอบสำหรับนักพัฒนาหรือสภาพแวดล้อมแซนด์บ็อกซ์ของคุณ
  

C.4 คำชี้แจงและคำถามต่างๆ

ต้องส่งคำถามอย่างเป็นลายลักษณ์อักษรภายใน[กำหนดเวลาของคำถาม]ไปยัง [อีเมลของผู้จัดการ RFP] โดยระบบจะส่งคำตอบให้กับผู้เข้าร่วมทุกรายพร้อมกัน ทั้งนี้ ไม่อนุญาตให้มีการพูดคุยอย่างไม่เป็นทางการกับพนักงานของ [บริษัทของคุณ] คนอื่นๆ ในระหว่างขั้นตอนนี้

C.5 ระยะเวลาที่ใช้ได้ของข้อเสนอ

ข้อเสนอจะต้องมีอายุ 90 วันนับจากวันกำหนดส่ง เว้นแต่จะมีการขยายเวลาโดยข้อตกลงร่วมกันอย่างเป็นลายลักษณ์อักษร

C.6 สิทธิ์ในการปฏิเสธหรือเจรจาต่อรอง

[บริษัทของคุณ] ขอสงวนสิทธิ์ในการปฏิเสธข้อเสนอใดๆ ขอคำชี้แจง หรือเจรจากับผู้ให้บริการตั้งแต่ 1 รายขึ้นไปพร้อมๆ กัน การเข้าร่วมไม่ได้ถือเป็นข้อผูกมัดในการซื้อ

ส่วน D: ขั้นตอนการประเมินผล

ความโปร่งใสในการให้คะแนนจะส่งเสริมผู้ให้บริการให้ตอบกลับด้วยหลักฐานแทนข้อมูลทางการตลาด ทุกเกณฑ์ด้านล่างนี้จะสอดคล้องกับคำถามที่เจาะจงในส่วน E เพื่อให้ผู้ให้บริการที่อ่านทราบได้แน่ชัดเลยว่าควรมุ่งเน้นที่เรื่องใด

ลักษณะตัวอย่างเป็นดังนี้

D.1 วิธีการประเมิน

ข้อเสนอทั้งหมดจะได้รับการตรวจสอบโดยทีมงานข้ามสายงาน เช่น การเงิน วิศวกรรม การปฏิบัติตามข้อกำหนด และ RevOps โดยการประเมินจะแบ่งเป็น 3 ขั้นตอนดังนี้

• การตรวจสอบการปฏิบัติตามข้อกำหนด: ยืนยันว่ามีเอกสารที่ได้รับมอบอำนาจครบถ้วน และเป็นไปตามข้อกำหนดในการจัดรูปแบบ
  
• การประเมินเชิงคุณภาพ: ให้คะแนนข้อมูลที่ส่งมาแต่ละรายการตามเกณฑ์ถ่วงน้ำหนักด้านล่างโดยใช้สเกล 1-5 โดยที่ 5 แสดงว่ายอดเยี่ยมมากและ 1 แสดงว่าไม่เป็นไปตามเกณฑ์พื้นฐาน
  
• การสาธิตและการตรวจสอบขั้นสุดท้าย: เชิญผู้ให้บริการที่ผ่านการคัดเลือกมาสาธิตการใช้แพลตฟอร์มแบบสด
  

D.2 เกณฑ์การประเมินและการถ่วงน้ำหนัก

ค่าถ่วงน้ำหนักข้างต้นสามารถปรับเปลี่ยนไปตามเรื่องที่โปรเจ็กต์ให้ความสำคัญได้ แต่ต้องรวมกันได้ 100%

D.3 ข้อกำหนดในการสาธิต

ผู้ให้บริการที่ผ่านการคัดเลือกจะสาธิตดังนี้

• ขั้นตอนการเรียกเก็บเงินแบบครบวงจรในแซนด์บ็อกซ์ที่ใช้งานจริง โดยมีการสร้างการชำระเงินตามรอบบิล การเปลี่ยนแพ็กเกจก่อนหมดรอบ และการจัดทำใบแจ้งหนี้ตามการใช้งาน
  
• การนำเข้าการวัดปริมาณการใช้งาน การรวมยอด และการเรียกเก็บเงินแบบเรียลไทม์
  
• การกำหนดค่าการติดตามหนี้ ตรรกะการลองซ้ำของแมชชีนเลิร์นนิง และแดชบอร์ดการรายงานการกู้คืน
  
• การพูดถึงเรื่องการเรียกใช้ API เช่น เวลาหน่วง การจัดการข้อผิดพลาด และการยืนยันการส่ง Webhook
  
• พอร์ทัลลูกค้าและฟังก์ชันแดชบอร์ดภายใน
  
• สถานการณ์จำลองของการค้าแบบใช้เอเจนต์ (กล่าวคือ เอเจนต์ AI หรือขั้นตอนอัตโนมัติเริ่มการดำเนินการชำระเงินตามรอบบิลผ่าน API)
  

ผู้ให้บริการต้องให้ข้อมูลประจำตัวชั่วคราวในการสาธิตที่ใช้ได้อย่างน้อย 10 วันทำการหลังจากวันที่ทำการสาธิต

D.4 การเจรจาต่อรองและเข้าทำสัญญา

[บริษัทของคุณ] ขอสงวนสิทธิ์ในการขอคำชี้แจง ขอข้อเสนอที่ดีที่สุดและเป็นที่สิ้นสุด และเจรจากับผู้ให้บริการตั้งแต่ 1 รายขึ้นไป ไม่มีสัญญาผูกมัดใดๆ จนกว่าทั้ง 2 ฝ่ายจะเข้าทำสัญญาร่วมกัน

⚑ หมายเหตุจากผู้ประเมิน—ลบออกก่อนส่งให้กับผู้ให้บริการ ⚑

• ให้คะแนนแบบของใครของมันก่อนหารือกันเป็นกลุ่ม โดยระบุเหตุผลประกอบทุกครั้งที่ให้คะแนนสูงกว่า 4 หรือต่ำกว่า 2 พร้อมแนบหลักฐานจากข้อมูลที่ส่งมาหรือการสาธิต
  
• ให้ตั้งข้อสงสัยต่อคำกล่าวอ้างเกี่ยวกับฟังก์ชันแบบ "Standard" (มาตรฐาน) และขอให้ส่งเอกสารหรือจัดการสาธิตแบบสด
  
• ให้ความสำคัญของผู้ให้บริการที่มีการบันทึกผลการกู้คืนด้วยแมชชีนเลิร์นนิงไว้ เวลาหน่วง API ต่ำกว่า 300 มิลลิวินาทีที่ p99 และสภาพแวดล้อมแซนด์บ็อกซ์ที่เทียบเท่ากับการใช้งานจริง
  
• กำหนดให้เกณฑ์ของการค้าแบบใช้เอเจนต์มีค่าถ่วงน้ำหนักมากขึ้น หากแผนงานของคุณครอบคลุมเส้นทางของลูกค้าที่ขับเคลื่อนด้วย AI หรือการจัดการการชำระเงินตามรอบบิลแบบอัตโนมัติ
  
• ระบุสัญญาณเตือนต่างๆ เช่น ค่าบริการที่คลุมเครือ ปัญหาด้านการปฏิบัติตามข้อกำหนดในตลาดสำคัญๆ ของคุณ แซนด์บ็อกซ์ที่ขาดหายไป และไม่มีการเผยแพร่ SLA ของ API
  

ส่วน E: ข้อกำหนดหลัก

ส่วนนี้สำคัญที่สุด ต้องให้คำตอบที่เป็นข้อเท็จจริงและมีหลักฐานประกอบ ผู้ให้บริการที่ควรได้รับการพิจารณาจะต้องมีตัวชี้วัดจากการใช้งานจริง เอกสารที่เผยแพร่แล้ว และตัวอย่างจากลูกค้าจริงมาแสดงให้เห็น ไม่ได้มีแค่การกล่าวอ้างลอยๆ โดยในข้อกำหนดแต่ละรายการ ผู้ให้บริการจะต้องระบุสถานะอย่างใดอย่างหนึ่ง ได้แก่ Standard (มาตรฐาน: มีการใช้งานจริงในปัจจุบัน), Configurable (กำหนดค่าได้: ต้องตั้งค่า), Custom (กำหนดเอง: ต้องมีการพัฒนา) หรือ N/A (ไม่มีข้อมูล)

ลักษณะตัวอย่างเป็นดังนี้

E.1 การขายและรับคำสั่งซื้อ

สำหรับทีมขาย

สำหรับขั้นตอนการชำระเงิน

ประสบการณ์การชำระเงินที่ทำให้เสียลูกค้าไปในขั้นตอนการชำระเงินถือเป็นปัญหาด้านการเรียกเก็บเงิน ไม่ใช่แค่ปัญหาด้าน UX คุณควรให้ผู้ให้บริการระบุข้อมูลเกี่ยวกับการเพิ่มคอนเวอร์ชันอย่างเป็นลายลักษณ์อักษรจากสภาพแวดล้อมที่ใช้งานจริง ไม่ใช่ตัวเลขโดยประมาณ

สำหรับแพลตฟอร์ม SaaS

สำหรับการปฏิบัติตามข้อกำหนดทั่วโลก

การปฏิบัติตามข้อกำหนดทั่วโลกเป็นข้อกำหนดในการดำเนินงานที่ต้องทำอยู่ตลอด มาตรฐานในการปฏิบัติตามข้อกำหนดต่างๆ จะเปลี่ยนแปลงไป กล่าวคือ PCI DSS เวอร์ชัน 4.0 มีผลบังคับใช้เมื่อเดือนมีนาคมปี 2024 และเขตอำนาจศาลต่างๆ ตั้งแต่อินเดียไปจนถึงเยอรมนีและบราซิลก็กำหนดภาระหน้าที่ในการเรียกเก็บเงินแบบเฉพาะเจาะจง ผู้ให้บริการจึงต้องติดตามและปฏิบัติตามมาตรฐานเหล่านี้โดยอัตโนมัติโดยไม่ต้องรอให้คุณขอ

E.2 การจัดการวงจรการเรียกเก็บเงินและการชำระเงินตามรอบบิล

ความยืดหยุ่นของโมเดลค่าบริการ

หากแพลตฟอร์มการเรียกเก็บเงินจัดการแค่การชำระเงินตามรอบบิลแบบอัตราคงที่ จะถือเป็นการจำกัดกลยุทธ์ในการบุกตลาดไปเรียบร้อยแล้ว ค่าบริการตามการใช้งานและแบบหลายแอตทริบิวต์เป็นโมเดลมาตรฐานของธุรกิจด้าน SaaS และโครงสร้างพื้นฐาน ผู้ให้บริการของคุณจะต้องรองรับโมเดลเหล่านี้อยู่แล้ว ไม่ใช่มาหาทางรับมือเอาทีหลัง

ระบบอัตโนมัติ

ประโยชน์ด้านการดำเนินงานของแพลตฟอร์มการเรียกเก็บเงินจะแปรผันตรงกับขั้นตอนที่กลายเป็นแบบอัตโนมัติ การให้เจ้าหน้าที่เข้ามาดูแลขั้นตอนการเรียกเก็บเงินจะนำมาซึ่งข้อผิดพลาด ความล่าช้า และค่าใช้จ่ายที่ไม่ควรเกิดขึ้น

ความสะดวกในการใช้งาน

E.3 การเรียกเก็บเงินและการลดค่าใช้จ่าย

วิธีการชำระเงินและประสิทธิภาพในการอนุมัติ

การมีวิธีการชำระเงินที่ครอบคลุมและอัตราการอนุมัติล้วนเป็นตัวขับเคลื่อนรายรับโดยตรง ไม่ใช่ประเด็นที่มีความสำคัญรองลงมา อัตราการอนุมัติที่เพิ่มขึ้นมาเพียง 1% ในพอร์ตการเรียกเก็บเงินตามแบบแผนล่วงหน้าก็คือเงินที่จับต้องได้จริง ข้อแตกต่างระหว่างผู้ให้บริการมักจะอยู่ที่ขนาดเครือข่าย โดยตรรกะการลองซ้ำที่ใช้แมชชีนเลิร์นนิงจะได้ผลดีก็ต่อเมื่อโมเดลได้รับการฝึกฝนกับสัญญาณต่างๆ มามากพอที่จะรู้ว่าต้องปรับพารามิเตอร์ใดบ้างสำหรับสถาบันผู้ออกบัตร ประเภทบัตร และรหัสข้อบกพร่องนั้นๆ ตัวอย่างเช่น Adaptive Acceptance ของ Stripe จะใช้ข้อมูลจากธุรกิจหลายล้านแห่งเพื่อปรับแต่งการลองซ้ำแบบเรียลไทม์ ซึ่งจะเป็นเกณฑ์มาตรฐานที่จะใช้เปรียบเทียบกับผู้ให้บริการรายอื่นๆ ให้กำหนดให้ระบุเกณฑ์มาตรฐานของอัตราการอนุมัติที่บันทึกได้จากสภาพแวดล้อมที่ใช้งานจริง และให้ผู้ให้บริการอธิบายว่าตนมีการอนุมัติถึงอัตราดังกล่าวได้อย่างไร

การเพิ่มประสิทธิภาพค่าใช้จ่าย

E.4 การรักษาลูกค้าและการกู้คืนรายรับ

การลดการเลิกใช้บริการโดยไม่ได้ตั้งใจ

การชำระเงินไม่สำเร็จเป็นปัจจัยหนึ่งที่สำคัญที่สุดซึ่งส่งผลให้เกิดการเลิกใช้บริการโดยไม่สมัครใจสำหรับธุรกิจต่างๆ ที่มีการชำระเงินตามรอบบิล วิธีที่ผู้ให้บริการใช้กู้คืนการชำระเงินจึงเป็นเรื่องหลักที่ควรตรวจสอบพอๆ กับการรองรับโมเดลค่าบริการ โดย Smart Retries ของ Stripe (ซึ่งรวมอยู่ใน Stripe Billing โดยไม่มีค่าใช้จ่ายเพิ่มเติม) ใช้แมชชีนเลิร์นนิงเพื่อระบุเวลาในการลองซ้ำที่เหมาะสมที่สุดของลูกค้าแต่ละรายแทนที่จะกำหนดเวลาตายตัว โทเค็นเครือข่ายจะช่วยลดการปฏิเสธให้เหลือน้อยลงไปอีกโดยอัปเดตข้อมูลประจำตัวของบัตรแบบอัตโนมัติเมื่อรายละเอียดเบื้องหลังเปลี่ยนแปลงไปโดยที่ลูกค้าไม่ต้องดำเนินการใดๆ ทั้งนี้ เมื่อคุณประเมินผู้ให้บริการรายอื่นในเรื่องนี้ ให้ใช้ประสิทธิภาพการกู้คืนของ Stripe เป็นเกณฑ์พื้นฐาน โดยต้องใช้ข้อมูลอัตราการกู้คืนในการใช้งานจริง สอบถามวิธีฝึกฝนตรรกะการลองซ้ำ และให้มองว่าคำตอบที่กำกวมเป็นสัญญาณให้หลีกเลี่ยงผู้ให้บริการรายนั้นๆ

การลดอัตราการเลิกใช้บริการโดยสมัครใจ

E.5 การค้าแบบใช้เอเจนต์และฟังก์ชันทางการเงินที่ผสานรวมในตัว

เอเจนต์ AI และเวิร์กโฟลว์แบบอัตโนมัติเริ่มเป็นจุดเริ่มต้นในการทำธุรกรรมเชิงพาณิชย์มากขึ้นเรื่อยๆ โดยสามารถกำหนดเวลาในการเปลี่ยนแปลงการชำระเงินตามรอบบิล ตอบสนองต่อคำขอจากลูกค้า และจัดการเหตุการณ์การเรียกเก็บเงินโดยไม่ต้องมีคนคอยจัดการ โครงสร้างพื้นฐานในการเรียกเก็บเงินที่สร้างขึ้นในปี 2026 จะต้องคำนึงถึงเรื่องนี้ ผู้ให้บริการที่ไม่ได้คิดถึงเรื่องการเรียกเก็บเงินแบบใช้เอเจนต์ก็จะเกิดปัญหาคอขวดในการผสานการทำงานเมื่อขยับขยายการให้บริการลูกค้าด้วย AI

การค้าแบบใช้เอเจนต์

การค้าแบบใช้เอเจนต์ คือ หมายถึงเอเจนต์ AI หรือระบบอัตโนมัติต่างๆ ที่เริ่มต้น แก้ไข หรือยกเลิกการชำระเงินตามรอบบิลและการดำเนินการเรียกเก็บเงินในนามของลูกค้า ซึ่งจำเป็นต้องใช้ API และรูปแบบการตรวจสอบสิทธิ์ที่ทำขึ้นมาเพื่อรองรับการโต้ตอบระหว่างเครื่อง (machine-to-machine) โดยเฉพาะ ไม่ใช่การปรับเปลี่ยนขั้นตอนที่มีไว้สำหรับบุคคล

ผลิตภัณฑ์ทางการเงินแบบผสานรวมในตัว

ระบบการเรียกเก็บเงินที่เชื่อมต่อกับผลิตภัณฑ์ทางการเงินที่ใกล้เคียงกัน (เช่น การออกบัตร การเงิน การให้กู้ยืม) ช่วยเพิ่มคุณค่าให้กับแพลตฟอร์มและมาร์เก็ตเพลสต่างๆ หากคุณเสนอหรือวางแผนที่จะนำเสนอผลิตภัณฑ์ทางการเงินควบคู่ไปกับผลิตภัณฑ์หลัก ผู้ให้บริการเรียกเก็บเงินที่ผสานการทำงานกับผลิตภัณฑ์เหล่านี้ได้ก็จะมีความสำคัญ

E.6 การรายงาน การวิเคราะห์ และการรับรู้รายรับ

การรายงานผลการดำเนินงานทางธุรกิจ

ข้อมูลการเรียกเก็บเงิน คือ ข้อมูลรายรับ ผู้ให้บริการของคุณควรให้ทีมการเงิน, RevOps และผู้นำของคุณมองเห็นสิ่งที่เกิดขึ้นกับฐานผู้สมัครใช้บริการของคุณแบบเรียลไทม์ ไม่ใช่การส่งออกในรูปแบบ CSV ที่คุณกระทบยอดเองหลังจากนั้น

การรับรู้รายรับและการกระทบยอด

หากทีมของคุณจัดทำรายงานแบบลำดับขั้นเกี่ยวกับรายรับด้วยตนเองหรือกระทบยอดข้อมูลการเรียกเก็บเงินกับบัญชีแยกประเภททั่วไป นี่คือปัญหาที่ผู้ให้บริการรายถัดไปควรจะแก้ไขได้ การปฏิบัติตามมาตรฐาน ASC 606 และ IFRS 15 ควรมีให้ในตัวอยู่แล้ว ไม่ใช่เสริมเข้ามาหลังจากนั้น

การจัดการการโต้แย้งการชำระเงิน

E.7 ประสิทธิภาพของ API และประสบการณ์ของนักพัฒนา

แพลตฟอร์มการเรียกเก็บเงินที่คุณไม่สามารถผสานการทำงานอย่างน่าเชื่อถือได้ (หรือมีประสิทธิภาพลดลงเมื่อทำงานหนัก) ถือปัญหาร้ายแรง ให้ประเมินคุณภาพ API ให้เข้มงวดพอๆ กับการตรวจสอบฟังก์ชันต่างๆ ที่รองรับ ให้ขอข้อมูลประสิทธิภาพในการใช้งานจริง ไม่ใช่เกณฑ์มาตรฐานจากสภาพแวดล้อมขั้นทดสอบที่จำลองขึ้น

ประสิทธิภาพของ API

ประสบการณ์ของนักพัฒนา

การผสานการทำงาน

E.8 การรักษาความปลอดภัย การปฏิบัติตามข้อกำหนด และความเป็นส่วนตัวของข้อมูล

การปฏิบัติตามข้อกำหนดนั้นเปลี่ยนแปลงอยู่ตลอด PCI DSS เวอร์ชัน 4.0 มีผลบังคับใช้ในเดือนมีนาคม 2024 และวางข้อกำหนดใหม่ๆ เกี่ยวกับการตรวจสอบสิทธิ์ การติดตามตรวจสอบ และการวิเคราะห์ความเสี่ยงแบบมุ่งเป้า การบังคับใช้ GDPR ก็เข้มงวดขึ้นตั้งแต่ปี 2023 โดยหน่วยงานกำกับดูแลต่างๆ กำหนดค่าปรับสูงเป็นประวัติการณ์ในกรณีที่มีการละเมิดเรื่องการจัดการข้อมูล ผู้ให้บริการของคุณจึงต้องก้าวล้ำการเปลี่ยนแปลงอยู่เสมอ ไม่ใช่ก้าวตามการเปลี่ยนแปลง

E.9 การขยายการรองรับได้และความน่าเชื่อถือ

E.10 คำชี้แจงเกี่ยวกับการรับรองจากผู้ให้บริการ

ข้าพเจ้าขอรับรองว่า คำตอบทั้งหมดถูกต้อง ณ วันที่ส่ง และฟังก์ชันต่างๆ ที่ระบุไว้ว่าเป็นแบบ "Standard" (มาตรฐาน) หรือ "Configurable" (กำหนดค่าได้) พร้อมใช้งานในสภาพแวดล้อมแบบใช้งานจริงแล้วในปัจจุบัน คำกล่าวอ้างต่างๆ ที่ไม่มีเอกสารรองรับหรือไม่มีการสาธิตแบบสดจะไม่ได้รับการประเมิน

ตัวแทนที่ได้รับอนุญาต: ________________________
ตำแหน่ง: ________________________
วันที่: ________

⚑ หมายเหตุจากผู้ประเมิน — ลบออกก่อนส่งให้กับผู้ให้บริการ ⚑

• ต้องมีหลักฐานเชิงปริมาณทุกครั้งที่กล่าวอ้างถึงประสิทธิภาพ เช่น อัตราการกู้คืน อัตราการอนุมัติ เกณฑ์มาตรฐานของเวลาหน่วง API และตัวเลขระยะเวลาให้บริการ
  
• ตรวจสอบคำกล่าวอ้างด้านประสิทธิภาพของ API ในการสาธิตแบบแซนด์บ็อกซ์ โดยให้วัดเวลาหน่วงตามจริง ไม่ใช่ตัวเลขที่ผู้ให้บริการระบุมา
  
• ระบุผู้ให้บริการที่ไม่สามารถสาธิตสถานการณ์จำลองในการเรียกเก็บเงินแบบใช้เอเจนต์ในสภาพแวดล้อมแซนด์บ็อกซ์ได้
  
• หากไม่มีการรองรับ ASC 606 หรือไม่มีแซนด์บ็อกซ์ที่เทียบเท่าการใช้งานจริง ให้ถือว่าไม่มีสิทธิ์เป็นธุรกิจที่มีระบบการเรียกเก็บเงินเต็มรูปแบบ
  
• ตรวจสอบยืนยันการปฏิบัติตามข้อกำหนด PCI DSS เวอร์ชัน 4.0 โดยเฉพาะเมื่อเวอร์ชัน 3.2.1 สิ้นสุดลงในวันที่ 31 มีนาคม 2024
  

E.11 Stripe จัดการกับข้อกำหนดเหล่านี้อย่างไร

หากคุณกำลังประเมิน Stripe เพื่อใช้เป็นพาร์ทเนอร์การเรียกเก็บเงิน นี่คือข้อมูลเกี่ยวกับแพลตฟอร์มของเราตามข้อกำหนดในส่วน E โดยเราได้แบ่งฟังก์ชันออกเป็นประเด็นต่างๆ ที่การตัดสินใจเกี่ยวกับสถาปัตยกรรมพื้นฐานจะส่งผลต่อธุรกิจของคุณมากที่สุด

ความยืดหยุ่นของโมเดลค่าบริการและการชำระเงินตามรอบบิล

Stripe Billing รองรับโมเดลค่าบริการได้กว่า 15 แบบ (ได้แก่ อัตราคงที่ แบ่งระดับ ตามปริมาณ ตามระดับ ตามการใช้งาน แบบหลายแอตทริบิวต์ และแบบไฮบริด) โดยไม่ต้องปรับเปลี่ยนใดๆ เป็นพิเศษสำหรับตลาดแต่ละแห่งที่จะเข้าไปดำเนินงาน การเรียกเก็บเงินตามการใช้งาน (ที่มีการรองรับเหตุการณ์การใช้งานสูงสุด 100 ล้านเหตุการณ์ต่อเดือน) จะจัดการการวัดปริมาณของแอตทริบิวต์ที่คุณกำหนดไว้ ได้แก่ การเรียกใช้ API, การประมวลผล, ผลลัพธ์, สิทธิ์ใช้งาน หรือมิติข้อมูลที่กำหนดเอง เมื่อ Stripe เข้าซื้อกิจการ Metronome (ซึ่งปัจจุบันเป็นผลิตภัณฑ์ของ Stripe แล้ว) ก็ช่วยต่อยอดการดำเนินงานส่วนนี้ให้กับธุรกิจต่างๆ ที่ทำสัญญาระดับองค์กรที่ซับซ้อน ทั้งแบบชำระเงินล่วงหน้าและแบบชำระเงินภายหลัง การปรับเปลี่ยนก่อนหมดรอบ และการลดราคาแบบกำหนดเอง คุณสามารถเปิดตัวโมเดลค่าบริการแบบใหม่ได้เลยจากแดชบอร์ดโดยใช้ใบแสดงราคาแบบไม่ต้องเขียนโค้ด โดยมีการอัปเดตให้กับฐานผู้สมัครใช้บริการของคุณในทันที โปรดดูเอกสารฉบับเต็มที่ Stripe Billing และการเรียกเก็บเงินตามการใช้งาน

การกู้คืนการชำระเงิน

การชำระเงินไม่สำเร็จเป็นปัจจัยที่สำคัญที่สุดซึ่งส่งผลให้เกิดการเลิกใช้บริการโดยไม่สมัครใจสำหรับธุรกิจต่างๆ ที่มีการชำระเงินตามรอบบิล และประสิทธิภาพในการกู้คืนก็เป็นข้อแตกต่างที่เห็นได้ชัดที่สุดสำหรับแพลตฟอร์มการเรียกเก็บเงินต่างๆ โดย Smart Retries ของ Stripe ใช้แมชชีนเลิร์นนิงเพื่อระบุเวลาในการลองซ้ำที่เหมาะสมที่สุดของลูกค้าแต่ละราย โดยอาศัยข้อมูลจากทั่วเครือข่ายของ Stripe แทนที่จะยึดตามเวลาการลองซ้ำแบบตายตัว การรองรับโทเค็นเครือข่ายช่วยให้ Stripe อัปเดตโทเค็นโดยอัตโนมัติเมื่อรายละเอียดของบัตรลูกค้าเปลี่ยนแปลงไป ซึ่งจะช่วยลดการปฏิเสธโดยที่ลูกค้าไม่ต้องดำเนินการใดๆ ระบบอัปเดตข้อมูลบัตรอัตโนมัติรองรับ Visa, Mastercard, Amex และ Discover และทำงานอยู่เบื้องหลังให้กับการชำระเงินตามรอบบิลทุกรายการที่ใช้งานอยู่ ทั้งนี้ Smart Retries และการจัดการการติดตามหนี้จะรวมอยู่ใน Stripe Billing โดยไม่มีค่าใช้จ่ายเพิ่มเติม โปรดดูเอกสารประกอบเกี่ยวกับการกำหนดค่าการกู้คืนรายรับที่ Stripe Docs

ภาษีและการปฏิบัติตามข้อกำหนดทั่วโลก

Stripe Tax จะคำนวณภาษีการขาย ภาษีมูลค่าเพิ่ม และ GST ในกว่า 100 ประเทศและหมวดหมู่ผลิตภัณฑ์กว่า 600 รายการ โดยจะอัปเดตแบบเรียลไทม์เมื่ออัตราเปลี่ยนไปและมีประวัติที่แทบจะไม่หยุดทำงานเลย โดยครอบคลุมโมเดลแบบต่างๆ ทั้ง B2B, B2C, การชำระเงินตามรอบบิล และมาร์เก็ตเพลส คุณจึงขยายเข้าสู่ตลาดใหม่ๆ ได้โดยไม่ต้องสร้างตรรกะด้านภาษีขึ้นมาใหม่ทุกรอบ คุณสามารถเปิดการเก็บภาษีในเขตอำนาจศาลใหม่ได้ภายในไม่กี่วินาทีจากแดชบอร์ด (หรือใช้โค้ดเพียงบรรทัดเดียว) และ Stripe Tax ก็จะผสานการทำงานกับพาร์ทเนอร์ด้านการยื่นภาษีเพื่อจัดการเรื่องการนำส่งภาษีในกรณีที่รองรับ โปรดดูความครอบคลุมของเขตอำนาจศาลในปัจจุบันและเอกสารเรื่องการปฏิบัติตามข้อกำหนดที่ Stripe Tax

การรายงานและการรับรู้รายรับ

Stripe Revenue Recognition จะปรับการทำบัญชีแบบเกณฑ์คงค้างให้เป็นแบบอัตโนมัติตามมาตรฐาน ASC 606 และ IFRS 15 โดยจัดทำแผนภูมิแบบลำดับขั้น (Waterfall Chart) เกี่ยวกับรายรับ กำหนดการของรายรับแบบรับล่วงหน้า และรายการบัญชีจากข้อมูลการเรียกเก็บเงินของคุณโดยตรง (คุณไม่ต้องกระทบยอดเอง) จำนวนรายรับที่รับรู้และแบบรับล่วงหน้าทุกรายการสามารถตรวจสอบย้อนกลับไปยังลูกค้าและใบแจ้งหนี้ต้นทางได้ ซึ่งช่วยให้ตรวจสอบได้เร็วขึ้นมาก ในส่วนของทีมที่ต้องการสิทธิ์เข้าถึงข้อมูลการเรียกเก็บเงินผ่าน SQL แบบกำหนดเอง Stripe Sigma ก็มีสภาพแวดล้อมในการสืบค้นแบบอินเทอร์แอคทีฟในแดชบอร์ด โดย Stripe Data Pipeline จะซิงค์ข้อมูล Stripe ของคุณกับ Snowflake, BigQuery หรือ Redshift สำหรับการวิเคราะห์ในคลังสินค้า โดยมีสิทธิ์เข้าถึง Sigma รวมอยู่ด้วย โปรดดูรายละเอียดที่ Stripe Revenue Recognition และ Stripe Data Pipeline

API และประสบการณ์ของนักพัฒนา

RESTful API ของ Stripe มาพร้อม SDK ฝั่งเซิร์ฟเวอร์สำหรับ Node.js, Python, Ruby, Java, Go, PHP และ .NET รวมถึง SDK บนอุปกรณ์เคลื่อนที่สำหรับ iOS และ Android โดย API นี้มีการกำหนดเวอร์ชันตามวันที่เผยแพร่ และมีการแจ้งให้ทราบล่วงหน้าเกี่ยวกับการเลิกใช้งานในไฟล์ SDK README และบันทึกการเปลี่ยนแปลง โดยจะมีการขยายระยะเวลาการสนับสนุนเพิ่มให้อีก 1-2 ปีต่อเวอร์ชันภาษาหลังสิ้นสุดอายุการใช้งาน สภาพแวดล้อมแซนด์บ็อกซ์ของ Stripe (ซึ่งปัจจุบันเรียกว่าแซนด์บ็อกซ์) มีขั้นตอนการเรียกเก็บเงินทั้งหมดอย่างเต็มรูปแบบทัดเทียมกับการใช้งานจริง เช่น การวัดปริมาณการใช้งาน การจัดการการติดตามหนี้ และการรับรู้รายรับ โดยไม่มีข้อจำกัดในโหมดทดสอบเกี่ยวกับปริมาณคำขอ ระยะเวลาให้บริการเฉลี่ย 90 วันของ Stripe อยู่ที่ 99.999% โปรดดูข้อมูลอ้างอิงเกี่ยวกับ API, เอกสารประกอบ SDK และสิทธิ์การเข้าใช้แซนด์บ็อกซ์ที่ Stripe Docs

การค้าแบบใช้เอเจนต์

Stripe ได้พัฒนาการเรียกเก็บเงินแบบใช้เอเจนต์มาก่อนที่ผู้ให้บริการส่วนใหญ่จะมีชื่อเรียกการเรียกเก็บเงินประเภทนี้ด้วยซ้ำ โดย Agentic Commerce Protocol (ACP) (ซึ่งพัฒนาร่วมกับ OpenAI และอยู่ใน Instant Checkout ของ ChatGPT) เป็นมาตรฐานทั่วไปของเอเจนต์ AI ในการเริ่มต้นและทำธุรกรรมให้เสร็จสมบูรณ์ด้วยโปรแกรม โทเค็นการชำระเงินที่ใช้ร่วมกันของ Stripe ช่วยให้เอเจนต์สามารถดำเนินการในนามของผู้ซื้อโดยใช้ข้อมูลประจำตัวแบบจำกัดเวลาและกำหนดขอบเขตได้ ซึ่งจะไม่เปิดเผยรายละเอียดของบัตร โดยมีการบันทึกการตรวจสอบและเหตุการณ์ Webhook อย่างครบถ้วนในทุกการดำเนินการ ในส่วนของธุรกิจที่มีการชำระเงินตามรอบบิล การออกแบบ API ของ Stripe Billing จะรองรับขั้นตอนการทำงานระหว่างเครื่อง (machine-to-machine) โดยตรง ซึ่งเอเจนต์จะสร้าง แก้ไข และยกเลิกการชำระเงินตามรอบบิลได้โดยใช้คีย์ API แบบละเอียดที่มีข้อจำกัด และเอเจนต์แต่ละรายการจะได้สิทธิ์เท่าที่ต้องใช้เท่านั้น ชุดเครื่องมือเอเจนต์ของ Stripe และเซิร์ฟเวอร์ MCP ของ Stripe ช่วยให้นักพัฒนามีการผสานการทำงานล่วงหน้ากับเฟรมเวิร์กต่างๆ เช่น LangChain, Agents SDK ของ OpenAI และ CrewAI โปรดดูเอกสารประกอบที่การค้าแบบใช้เอเจนต์ของ Stripe และ MCP ของ Stripe

หากต้องการดูฟังก์ชันใดๆ เหล่านี้ในสภาพแวดล้อมแบบใช้งานจริง โปรดติดต่อฝ่ายขายของ Stripe เพื่อนัดหมายจัดการสาธิตแซนด์บ็อกซ์ หรือดูเอกสารประกอบทางเทคนิคฉบับเต็มที่ Stripe Docs

ส่วน F: การนำไปใช้และการสนับสนุน

แพลตฟอร์มการเรียกเก็บเงินที่เหนือชั้นก็อาจบกพร่องได้หากการนำไปใช้ไม่ราบรื่น ส่วนนี้จะเป็นการตรวจสอบว่า ผู้ให้บริการมีวิธีการ ทรัพยากร และโมเดลการสนับสนุนเพื่อให้คุณใช้งานจริงได้โดยไม่ทำให้การเรียกเก็บเงินหยุดชะงักและช่วยให้คุณทำงานหลังจากนั้นได้อย่างน่าเชื่อถือหรือไม่

ลักษณะตัวอย่างเป็นดังนี้

F.1 แนวทางและลำดับเวลาในการนำไปใช้

ผู้ให้บริการต้องอธิบายดังนี้

• เฟรมเวิร์กการจัดการโปรเจ็กต์ (แบบเอไจล์ ลำดับขั้น หรือไฮบริด) และวิธีติดตามและรายงานความคืบหน้าให้กับลูกค้า
  
• เวลาโดยทั่วไปในการเปิดตัวสำหรับลูกค้าที่มีขนาดและความซับซ้อนของค่าบริการที่เทียบเคียงกันได้
  
• วิธีระบุและบรรเทาความเสี่ยงในการผสานการทำงาน (โดยเฉพาะอย่างยิ่งกับระบบ CRM, ERP และคลังข้อมูล)
  
• กลยุทธ์การเรียกเก็บเงินแบบคู่ขนานหรือการเปลี่ยนระบบจะช่วยรักษาความต่อเนื่องของรายรับระหว่างการย้ายได้อย่างไร
  

F.2 การจัดหาทรัพยากรและการกำกับดูแล

ผู้ให้บริการควรระบุข้อมูลดังนี้

• แผนผังองค์กรหรือแผนภาพ RACI สำหรับทีมดำเนินการ
  
• การยืนยันว่าบทบาทสำคัญๆ เป็นบุคลากรภายในองค์กรเองหรือจ้างมาจากบริษัทอื่นอีกที
  
• ผู้จัดการบัญชีและผู้ออกแบบโซลูชันที่ได้รับการเสนอชื่อและมอบหมายให้ดูแลการติดต่อครั้งนี้
  
• ลำดับชั้นในการเดินเรื่องต่อและลำดับการตัดสินใจ
  

F.3 การฝึกอบรมและการถ่ายทอดความรู้

ผู้ให้บริการควรอธิบายดังนี้

• มีการฝึกอบรมสำหรับฝ่ายการเงิน, RevOps, วิศวกรรม และความสำเร็จของลูกค้า
  
• การจัดให้มีการฝึกอบรมตามความต้องการ เอกสารประกอบ และเส้นทางการรับรอง
  
• วิธีดูแลสื่อการฝึกอบรมให้เป็นปัจจุบันตามการเปิดตัวผลิตภัณฑ์ใหม่อยู่เสมอ
  

F.4 โมเดลการสนับสนุนและระดับการบริการ

ผู้ให้บริการต้องระบุดังนี้

• ระดับการสนับสนุนและบริการที่มีให้ในแต่ละระดับ
  
• ความพร้อมช่วยเหลือทุกวันตลอด 24 ชั่วโมงในกรณีที่เกิดปัญหาใหญ่ๆ ด้านการเรียกเก็บเงิน เพราะหากการเรียกเก็บเงินหยุดชะงัก รายรับก็ย่อมหยุดชะงักตามไปด้วย
  
• SLA เกี่ยวกับเวลาตอบสนองตามระดับความรุนแรง
  
• วิธีแจ้งลูกค้าแบบเรียลไทม์ระหว่างที่เกิดปัญหาขึ้น
  
• ประสิทธิภาพด้านระยะเวลาให้บริการที่ผ่านๆ มา โดยมีเป้าหมายขั้นต่ำอยู่ที่ 99.9% และควรอยู่ที่อย่างน้อย 99.99%
  

F.5 การบำรุงรักษาและการอัปเกรด

ผู้ให้บริการควรอธิบายดังนี้

• วิธีแจ้งการเปิดตัวผลิตภัณฑ์ (เช่น บันทึกประจำรุ่น บันทึกการเปลี่ยนแปลง ระยะเวลาแจ้งล่วงหน้า)
  
• นโยบายการกำหนดเวอร์ชันและการเลิกใช้งาน API (แจ้งล่วงหน้าอย่างน้อย 12 เดือนในกรณีของการเปลี่ยนแปลงที่ส่งผลต่อการดำเนินงาน)
  
• ดำเนินการอัปเกรดโดยที่การเรียกเก็บเงินไม่หยุดชะงักได้หรือไม่
  

F.6 การปรับปรุงอย่างต่อเนื่อง

อธิบายวิธีที่คุณใช้ข้อมูลวิเคราะห์ของแพลตฟอร์ม ข้อมูลเชิงลึกที่ขับเคลื่อนด้วยแมชชีนเลิร์นนิง และการติดตามตรวจสอบเชิงรุกเพื่อเพิ่มประสิทธิภาพในการเรียกเก็บเงินขึ้นเรื่อยๆ โปรดให้ตัวอย่างที่ชัดเจนเกี่ยวกับการปรับปรุงแบบวัดผลได้ที่ลูกค้าในปัจจุบันได้รับ เช่น อัตราการกู้คืนที่เพิ่มขึ้น อัตราการอนุมัติที่ดีขึ้น และจำนวนตั๋วขอรับการสนับสนุนเกี่ยวข้องกับการเรียกเก็บเงินที่ลดน้อยลง

F.7 การรับรองจากผู้ให้บริการ

ข้าพเจ้าขอรับรองว่า รายละเอียดการนำไปใช้และการสนับสนุนทั้งหมดที่ให้ไว้ที่นี่ถูกต้อง ณ วันที่ส่ง และสะท้อนถึงแนวทางปฏิบัติในการใช้งานจริงและระดับการบริการในปัจจุบัน

ตัวแทนที่ได้รับอนุญาต: ________________________
ตำแหน่ง: ________________________
วันที่: ________

⚑ หมายเหตุจากผู้ประเมิน — ลบออกก่อนส่งให้กับผู้ให้บริการ ⚑

• ตรวจสอบกรอบเวลาที่ตกลงกันไว้กับรายการที่เทียบเคียงกันได้ ให้ขอตัวอย่างแบบเจาะจงแทนการระบุเป็นช่วง
  
• ยืนยันว่ามีการสนับสนุนทุกวันตลอด 24 ชั่วโมงจริงๆ ให้ขอตัวอย่างเวลาที่ใช้รับมือกับเหตุการณ์ครั้งใหญ่ๆ ล่าสุด
  
• สอบถามว่าทีมดำเนินการเป็นทีมเดียวกับทีมที่ดูแลการสนับสนุนหลังเปิดตัวหรือไม่
  
• ต้องมีนโยบายการเลิกใช้งาน API แบบเป็นลายลักษณ์อักษรก่อนลงนามในสัญญา
  

ส่วน G: รายการเชิงพาณิชย์

ค่าบริการของแพลตฟอร์มการเรียกเก็บเงินอาจไม่ชัดเจน ส่วนนี้จะช่วยให้การนำเสนอค่าใช้จ่ายของผู้ให้บริการเป็นมาตรฐานเดียวกัน เพื่อให้คุณเปรียบเทียบได้อย่างถูกต้อง หากคุณไม่ได้กำหนดให้ชี้แจงแยกรายการตั้งแต่เนิ่นๆ คุณก็จะพบค่าธรรมเนียมแบบรวมชุดและข้อผูกมัดขั้นต่ำหลังจากลงนามในสัญญาแล้วเท่านั้น

ลักษณะตัวอย่างเป็นดังนี้

G.1 ภาพรวมเกี่ยวกับโครงสร้างค่าบริการ

ผู้ให้บริการต้องให้ข้อมูลดังนี้

• ค่าบริการแบบแยกรายการสำหรับทุกองค์ประกอบ เช่น ค่าธรรมเนียมแพลตฟอร์ม ค่าธรรมเนียมต่อธุรกรรม ค่าธรรมเนียมการใช้งาน และส่วนเสริม
  
• คำบรรยายที่อธิบายสมมติฐานต่างๆ ของค่าบริการ เช่น ระดับปริมาณ การใช้สกุลเงินต่างๆ ร่วมกัน และการประมาณการเหตุการณ์การเรียกเก็บเงิน
  
• การระบุข้อผูกมัดรายเดือนขั้นต่ำหรือค่าบริการที่เป็นเกณฑ์อย่างชัดเจน
  
• ตัวเลขทั้งหมดต้องเป็นสกุลเงิน USD (รวมถึงวิธีการแปลงสกุลเงิน หากเสนอราคาเป็นสกุลเงินอื่น)
  

G.2 องค์ประกอบของค่าบริการ

G.3 ระดับปริมาณ

จัดทำการวิเคราะห์ความไวที่แสดงให้เห็นว่าค่าบริการจะเปลี่ยนไปอย่างไรบ้างที่ปริมาณระดับต่างๆ ต่อไปนี้

G.4 ระยะเวลาและความยืดหยุ่นของสัญญา

• ระยะเวลาของสัญญาที่ใช้ได้และสิ่งจูงใจเกี่ยวกับค่าบริการที่เกี่ยวข้อง
  
• การระบุว่าค่าบริการจะลดลงโดยอัตโนมัติหรือไม่หากปริมาณลดลง
  
• ขั้นตอนการเจรจาใหม่สำหรับสัญญาแบบหลายปี
  
• ข้อกำหนดการใช้จ่ายขั้นต่ำ
  
• ข้อกำหนดในการสิ้นสุดสัญญาและข้อกำหนดการเคลื่อนย้ายข้อมูล (กล่าวคือ ระบบจะส่งคืนข้อมูลของคุณอย่างไร ในรูปแบบใด และมีลำดับเวลาเป็นแบบใด)
  

G.5 สมมติฐานและเงื่อนไขที่เกี่ยวข้อง

ให้ระบุสมมติฐานเชิงพาณิชย์ทั้งหมดที่คุณใช้ในการกำหนดค่าบริการ เช่น ปริมาณขั้นต่ำ ข้อกำหนดการผูกขาด วิธีการชำระเงินเฉพาะ และขอบเขตทางภูมิศาสตร์ สมมติฐานต่างๆ ที่ไม่ได้ระบุไว้แล้วมาพบหลังจากทำสัญญาไปแล้วอาจถือเป็นการนำเสนอข้อมูลที่ไม่ถูกต้องในส่วนที่เป็นสาระสำคัญได้

G.6 การรับรองของผู้ให้บริการ

ข้าพเจ้าขอรับรองว่า ข้อมูลค่าบริการและเชิงพาณิชย์ในข้อเสนอนี้ครบถ้วนและถูกต้อง ณ วันที่ส่ง และแสดงถึงส่วนลด ค่าธรรมเนียม และข้อกำหนดที่เกี่ยวข้องทั้งหมดแล้ว

ตัวแทนที่ได้รับอนุญาต: ________________________
วันที่: ________

⚑ หมายเหตุจากผู้ประเมิน — ลบออกก่อนส่งให้กับผู้ให้บริการ ⚑

• กระทบยอดตัวเลขทั้งหมดกับแผ่นค่าบริการ Excel โดยข้อมูลที่คลาดเคลื่อนจะเป็นสัญญาณเตือน
  
• ให้ระวังค่าธรรมเนียมแบบรวมชุดที่ทำให้ไม่เห็นต้นทุนต่อหน่วย โดยเฉพาะในการวัดปริมาณและการติดตามหนี้
  
• ประเมินข้อกำหนดในการเคลื่อนย้ายข้อมูลให้ดี เพราะการเปลี่ยนแปลงหรือยกเลิกการใช้บริการได้ยาก (Lock-in) มักอยู่ในระดับข้อมูล ไม่ใช่ระดับสัญญา
  
• ระบุผู้ให้บริการรายใดก็ตามที่ไม่สามารถวิเคราะห์ความไวต่อปริมาณ (Volume sensitivity) ได้
  

ส่วน H: โปรไฟล์ผู้ให้บริการ

แพลตฟอร์มการเรียกเก็บเงินจะเป็นพาร์ทเนอร์ด้านโครงสร้างพื้นฐานในระยะยาว คุณจึงต้องทำความรู้จักบริษัทที่อยู่เบื้องหลังผลิตภัณฑ์นั้นๆ ไม่ว่าจะเป็นสถานะทางการเงิน ความเชี่ยวชาญทางวิศวกรรม และแนวโน้มของบริษัท ไม่ได้ดูแค่ว่ารายการฟีเจอร์ในปัจจุบันดูใช้ได้หรือไม่

ลักษณะตัวอย่างเป็นดังนี้

H.1 ภาพรวมของบริษัท

ให้ข้อมูลสรุป 2-3 ย่อหน้า โดยระบุประวัติ ภารกิจ และตำแหน่งในตลาดของคุณ ให้เน้นย้ำถึงประสบการณ์ของคุณในการสนับสนุนการเรียกเก็บเงินระดับองค์กรในหลายๆ ตลาด และประวัติของคุณในการรักษาการปฏิบัติตามข้อกำหนดเมื่อระเบียบข้อบังคับต่างๆ เปลี่ยนแปลงไป

H.2 ผู้นำและบุคลากรคนสำคัญ

ระบุประวัติสั้นๆ (3-5 บรรทัด) ของผู้นำคนสำคัญที่มีส่วนร่วมในการติดต่อครั้งนี้ ให้อธิบายความเชี่ยวชาญด้านเทคนิคหรือการปฏิบัติตามข้อกำหนดและการรับรองต่างๆ ที่เกี่ยวข้อง

H.3 เสถียรภาพทางการเงิน

แสดงงบการเงินที่ตรวจสอบแล้วหรือหลักฐานแสดงความสามารถในการชำระหนี้ที่เทียบเท่า บริษัทเอกชนควรจัดทำหนังสือจาก CFO ที่รับรองสภาพคล่อง ให้อธิบายโครงสร้างการหาเงินทุนของคุณ (หากมี)

H.4 การรับรองและการปฏิบัติตามข้อกำหนด

H.5 แผนงานสำหรับผลิตภัณฑ์

จัดทำแผนงานระดับสูงที่ครอบคลุมการเปิดตัวต่างๆ ที่กำลังจะเกิดขึ้นในอีก 12-18 เดือนข้างหน้า ให้มุ่งเน้นการลงทุนตามแผนสำหรับฟีเจอร์ที่ขับเคลื่อนด้วยแมชชีนเลิร์นนิง การสนับสนุนการค้าแบบใช้เอเจนต์ ความครอบคลุมด้านการปฏิบัติตามข้อกำหนดทั่วโลก และประสิทธิภาพของ API ให้อธิบายว่าข้อเสนอแนะของลูกค้าส่งผลต่อการจัดลำดับความสำคัญของคุณอย่างไร

H.6 การเป็นพาร์ทเนอร์และระบบต่างๆ

ระบุรายชื่อพาร์ทเนอร์หลักๆ ด้านเทคโนโลยีและช่องทางที่เกี่ยวข้องกับการติดต่อครั้งนี้ ให้อธิบายว่าพาร์ทเนอร์เหล่านี้ช่วยเพิ่มความน่าเชื่อถือ ความครอบคลุมในการปฏิบัติตามข้อกำหนด หรือความเชี่ยวชาญในการผสานการทำงานอย่างไร

H.7 แนวทางปฏิบัติด้านสิ่งแวดล้อมและความยั่งยืน

อธิบายแนวทางปฏิบัติต่างๆ ที่ลดผลกระทบต่อสิ่งแวดล้อม (เช่น การใช้ใบเสร็จดิจิทัลเป็นค่าเริ่มต้น การออกใบแจ้งหนี้แบบไม่ใช้กระดาษ ข้อมูลเชิงลึกเกี่ยวกับผลกระทบต่อสิ่งแวดล้อมของวิธีการชำระเงิน) ให้อธิบายว่าการดำเนินงานของแพลตฟอร์มช่วยส่งเสริมความยั่งยืนอย่างไร

H.8 คำชี้แจงเกี่ยวกับความถูกต้องของผู้ให้บริการ

ข้าพเจ้าขอรับรองว่า ข้อมูลทั้งหมดในส่วน H นั้นถูกต้อง ณ วันที่ส่ง และ[ผู้ให้บริการ]มีความสามารถทางการเงิน เทคนิค และการดำเนินงานในการให้บริการต่างๆ ตามที่อธิบายไว้

ตัวแทนที่ได้รับอนุญาต: ________________________
วันที่: ________

ส่วน I: บุคคลอ้างอิง

บุคคลอ้างอิงจากลูกค้าที่เทียบเคียงได้จะให้ข้อมูลกับคุณได้มากกว่าการสาธิต โปรดให้ความสำคัญกับบุคคลอ้างอิงต่างๆ ที่มีลักษณะเหมือนธุรกิจของคุณและมีความซับซ้อนเรื่องค่าบริการ ขนาด และขอบเขตการกำกับดูแลที่คล้ายๆ กัน บุคคลอ้างอิงทั่วไปจากธุรกิจต่างประเภทหรือธุรกิจที่เล็กกว่ามากๆ จะใช้คาดการณ์ประสบการณ์ของคุณไม่ได้

ลักษณะตัวอย่างเป็นดังนี้

I.1 ข้อกำหนดของบุคคลอ้างอิง

ผู้ให้บริการต้องระบุลูกค้าอ้างอิงอย่างน้อย 3 รายที่เป็นไปตามเกณฑ์เหล่านี้

• ปริมาณการเรียกเก็บเงินที่เทียบเคียงได้กับ [บริษัทของคุณ]
  
• ความซับซ้อนของโมเดลค่าบริการที่คล้ายๆ กัน (ขอแนะนำให้ใช้ค่าบริการแบบตามการใช้งานหรือหลายแอตทริบิวต์)
  
• * ขอบเขตทางภูมิศาสตร์และการกำกับดูแลที่ทับซ้อนกัน*
  
• ลูกค้าที่ใช้งานอยู่ในขั้นตอนใช้งานจริงมาอย่างน้อย 12 เดือน
  

I.2 ตารางบุคคลอ้างอิง

I.3 การสรุปผลจากบุคคลอ้างอิง

สำหรับบุคคลอ้างอิงแต่ละราย ให้ระบุผลลัพธ์ที่วัดได้ เช่น การปรับปรุงการกู้คืนการชำระเงิน การเปลี่ยนแปลงของอัตราการอนุมัติ ลำดับเวลาในการปรับใช้ และการรับรู้รายรับโดยอัตโนมัติที่เกิดขึ้น ให้ใส่คำรับรองจากลูกค้า (หากมี)

I.4 การตรวจสอบความถูกต้องของบุคคลอ้างอิง

ข้าพเจ้าขอยืนยันว่า ลูกค้าแต่ละรายยินยอมให้ใช้เป็นบุคคลอ้างอิงและข้อมูลทั้งหมดที่ให้ไว้นั้นถูกต้อง

ตัวแทนที่ได้รับอนุญาต: ________________________
วันที่: ________

⚑ หมายเหตุจากผู้ประเมิน — ลบออกก่อนส่งให้กับผู้ให้บริการ

• *โทรศัพท์หาบุคคลอ้างอิงอย่างน้อย 2 คน เพราะข้อมูลสรุปที่เขียนมาจะผ่านการคัดสรรให้เหลือแต่ด้านดีๆ แล้ว
  
• ให้สอบถามอย่างเจาะจงถึงประสบการณ์การใช้งานและปัญหาที่เกิดขึ้น ไม่ใช่ถามถึงแพลตฟอร์มในช่วงที่ทำงานตามปกติเท่านั้น
  
• สอบถามบุคคลอ้างอิงว่า คำกล่าวอ้างเกี่ยวกับการกู้คืนด้วยแมชชีนเลิร์นนิงของผู้ให้บริการเกิดขึ้นในการใช้งานจริงหรือไม่
  
• ระบุบุคคลอ้างอิงที่เป็นแบบกว้างๆ ไม่สามารถตรวจสอบยืนยันได้ หรือไม่สอดคล้องกันอย่างชัดเจน
  

ส่วน J: ภาคผนวก

รายการตรวจสอบสำหรับข้อมูลที่ส่ง (สำหรับผู้ให้บริการ)

แนบเป็นหน้าแรกในชุดคำตอบของคุณ การส่งข้อมูลที่ไม่สมบูรณ์อาจถูกแยกออกจากการประเมิน

J.2 อภิธานศัพท์

J.3 เมทริกซ์การให้คะแนนการประเมิน (ใช้เป็นการภายใน)

สำหรับผู้ให้บริการแต่ละราย ให้คำนวณสิ่งต่อไปนี้

• การเรียกเก็บเงิน (25%)
  
• API (15%)
  
• การกู้คืน (15%)
  
• การปฏิบัติตามข้อกำหนด (15%)
  
• การรายงาน (10%)
  
• เอเจนต์ (5%)
  
• การสนับสนุน (5%)
  
• รายการเชิงพาณิชย์ (10%)
  
• ยอดรวมแบบถ่วงน้ำหนัก
  

J.4 รายการตรวจสอบแบบใช้อ้างอิงคร่าวๆ เกี่ยวกับข้อกำหนดในการเรียกเก็บเงิน

รายการตรวจสอบแบบรวบรัดสำหรับการประเมินตนเองของผู้ให้บริการก่อนส่ง

การขายและการรับคำสั่งซื้อ

• การผสานการทำงาน CRM ในการจัดทำใบเสนอราคา
  
• การแปลงใบเสนอราคาเป็นการชำระเงินตามรอบบิลและใบเสนอราคาเป็นใบแจ้งหนี้
  
• การเสนอราคาแบบหลายสกุลเงิน
  
• การชำระเงินผ่านเว็บ อุปกรณ์เคลื่อนที่ และที่จุดขาย
  
• ข้อมูลประจำตัวที่บันทึกไว้หรือข้อมูลที่เทียบเท่าบน Link สำหรับลูกค้าที่กลับมาใช้บริการ
  
• การตรวจจับการฉ้อโกงที่มีอัตราการปฏิเสธการชำระเงินผิดพลาดต่ำ
  
• 3DS2 พร้อมการจัดการการยกเว้นของ PSD2
  
• การรองรับ ACH, SEPA, การหักบัญชีที่ได้รับอนุมัติล่วงหน้า และการมอบอำนาจให้หักบัญชีแบบ Bacs
  
• การปฏิบัติตามการมอบอำนาจให้หักบัญชีของ RBI
  
• Kündigungsbutton ในเยอรมนีสำหรับการยกเลิกในคลิกเดียว
  
• เทมเพลตใบแจ้งหนี้ที่เป็นไปตามข้อกำหนดในท้องถิ่น รวมถึง Nota Fiscal ของบราซิล
  
• การคัดกรอง OFAC และการคว่ำบาตร
  

การจัดการการเรียกเก็บเงินและการชำระเงินตามรอบบิล

• ค่าบริการแบบอัตราคงที่ แบ่งระดับ ตามปริมาณ และตามระดับ
  
• การเรียกเก็บเงินตามการใช้งานพร้อมการรวมยอดที่กำหนดค่าได้
  
• ค่าบริการแบบหลายแอตทริบิวต์ (สิทธิ์ใช้งานและการใช้งาน)
  
• การจัดการการให้สิทธิ์สำหรับการควบคุมฟีเจอร์
  
• การทดลองใช้ฟรี การชำระเงินล่วงหน้า และการผ่อนชำระ
  
• การคำนวณภาษีอัตโนมัติสำหรับภาษีการขายและภาษีมูลค่าเพิ่ม
  
• ตรรกะการแบ่งชำระตามสัดส่วน
  
• การเปลี่ยนแปลงการชำระเงินตามรอบบิลจำนวนมากและบัญชีแบบมีลำดับชั้น
  
• พอร์ทัลแบบบริการตนเองของลูกค้า
  

การชำระเงิน การกู้คืน และการอนุมัติ

• บัตร กระเป๋าเงิน การหักบัญชีธนาคาร และการโอนเงินผ่านธนาคาร
  
• การรองรับโทเค็นเครือข่ายสำหรับการปรับปรุงการอนุมัติที่เกิดขึ้นประจำ
  
• การจัดการการติดตามหนี้ที่ขับเคลื่อนด้วยแมชชีนเลิร์นนิง พร้อมการลองซ้ำแบบไดนามิก (Adaptive Acceptance หรือเทียบเท่า)
  
• ระบบอัปเดตข้อมูลบัตรอัตโนมัติ
  
• การลองซ้ำเชิงคาดการณ์พร้อมอัตราการกู้คืนที่บันทึกไว้
  
• การรับชำระเงินภายในประเทศ
  
• ข้อมูลระดับ 2 หรือ 3 และการส่งผ่านรหัส AVS หรือรหัสไปรษณีย์
  
• การเพิ่มประสิทธิภาพค่าธรรมเนียมแลกเปลี่ยนเงินตราต่างประเทศ
  

ฟังก์ชันแบบใช้เอเจนต์และแบบผสานรวมในตัว

• การตรวจสอบสิทธิ์ API ระหว่างเครื่อง (Machine-to-machine) สำหรับการเรียกเก็บเงินที่เริ่มต้นโดยเอเจนต์
  
• สิทธิ์ API แบบละเอียดหรือขอบเขต OAuth
  
• กระบวนการตรวจสอบสำหรับการดำเนินการที่เริ่มต้นโดยเอเจนต์
  
• การออกบัตรและการผสานการทำงานด้านการเงิน
  
• ซื้อตอนนี้ จ่ายทีหลังหรือการจัดหาเงินทุนในขณะชำระเงิน
  

การรายงานและการรับรู้รายรับ

• แดชบอร์ดแบบเรียลไทม์สำหรับ MRR, ARR, การเลิกใช้บริการ และ NRR
  
• ประสิทธิภาพการกู้คืนและการรายงานการสกัดกั้น
  
• การเชื่อมต่อคลังข้อมูล
  
• การรับรู้รายรับตามมาตรฐาน ASC 606 และ IFRS 15
  
• กำหนดเวลาของแผนภูมิกำหนดการรายรับและรายรับแบบรับล่วงหน้า
  
• การผสานการทำงาน ERP และระบบบัญชี
  
• การคาดการณ์รายรับที่ขับเคลื่อนด้วย AI
  

API, การรักษาความปลอดภัย และทางเทคนิค

• เวลาหน่วง API ต่ำกว่า 300 มิลลิวินาทีที่ p99 โดยเป็นการบันทึกจากการใช้งานจริง
  
• SLA เวลาทำงานอยู่ที่อย่างน้อย 99.9% โดยมีข้อมูลย้อนหลัง
  
• แซนด์บ็อกซ์เต็มรูปแบบที่เทียบเท่ากับการใช้งานจริง
  
• API แบบกำหนดเวอร์ชัน โดยมีการแจ้งเลิกใช้งานล่วงหน้า 12 เดือน
  
• PCI DSS เวอร์ชัน 4.0 (มีนาคมปี 2024)
  
• SOC 2 ประเภท 2
  
• มาตรการควบคุมความเป็นส่วนตัวของข้อมูลตาม GDPR และ CCPA
  
• ตัวเลือกถิ่นที่อยู่ของข้อมูล
  

J.5 ใบรับรองข้อมูลที่ส่งของผู้ให้บริการ

ข้าพเจ้าขอรับรองว่า ข้อมูลที่ส่งนี้ครบถ้วนสมบูรณ์และข้อมูลทั้งหมดที่ให้ไว้นั้นถูกต้องเท่าที่ฉันทราบ ฉันรับทราบว่า [บริษัทของคุณ] ขอสงวนสิทธิ์ในการตรวจสอบยืนยันคำกล่าวอ้างๆ ที่เกิดขึ้นในคำตอบนี้

ชื่อบริษัท: ________________________
ตัวแทนที่ได้รับอนุญาต: ________________________
ตำแหน่ง: ________________________
ลายเซ็น: ________________________
วันที่: ________