ทุกงานที่ต้องทำ อยู่ใน inbox เดียว
CKN Portal คือชั้นที่คนทำงานใช้งานจริง: work inbox เดียว, notification, การมอบหมายงาน, escalation และ approval ครบในที่เดียว ไม่ว่างานจะมาจากระบบไหน คนก็เห็นและจัดการจากหน้าจอเดียว โดยเจ้าของงานตัวจริงยังเป็นผู้ตัดสินสถานะงานเสมอ
งานของฉัน เรียงตามความเร่งด่วน
งานจากทุกระบบมารวมใน inbox เดียว พร้อมระดับความสำคัญและเวลาที่เหลือ
วัดการตอบสนองของทีม
งานค้าง เวลารับเรื่อง เวลาปิดงาน และการ escalate ในช่วงเวลาที่เลือก
สิ่งที่ CKN Portal ทำได้
Work inbox เดียวทั้งองค์กร
งานที่ต้องให้คนตัดสินใจจากทุกบริการมารวมกันที่เดียว แต่ละรายการมีที่มา ความเร่งด่วน และเวลาที่เหลือ ให้ทีมจัดลำดับได้ทันที
- รับงานเข้าด้วย API ครั้งเดียว ส่งซ้ำก็ไม่เกิดงานซ้ำ
- จัดหมวดงานพร้อมระดับความเร่งด่วนและเวลาตอบรับ/แก้ไขที่ตั้งไว้
- งานที่ต้นทางเงียบไปนานเกินกำหนดจะแสดงว่า stale ไม่แสดงว่าเป็นข้อมูลล่าสุด
- หน้าจอ inbox ของตัวเองและของทีมแยกกัน
รับทราบ มอบหมาย และติดตาม
การรับทราบ ความเป็นเจ้าของงาน และการติดตามเป็นคนละเรื่องกัน ระบบบันทึกแยกกันตามจริง ไม่บังคับให้เป็น status เดียว
- ทุกคนที่รับทราบถูกบันทึกครั้งเดียวต่อคน
- มีผู้รับผิดชอบที่เปิดอยู่ได้ครั้งละหนึ่งคน พร้อมเหตุผลการโอนทุกครั้ง
- ผู้ติดตามได้รับแจ้ง แต่ไม่ถูก escalate ถึง
- ผู้ใช้ปิดแจ้งเตือนของงานได้ โดยงานยังเปิดอยู่
Escalation ที่ไม่เงียบหาย
กำหนดแยกกันว่างานรอรับทราบได้นานเท่าไร และรอแก้ไขได้นานเท่าไร เมื่อเกินเวลา ระบบโอนงานให้บทบาทเป้าหมายตามนโยบาย
- รอบตรวจซ้ำสองรอบ ได้ escalation ครั้งเดียว การโอนครั้งเดียว และแจ้งเตือนครั้งเดียว
- จำกัดจำนวนครั้ง เมื่อครบจะบันทึก expectation breach แทนที่จะปิดงาน
- ถ้าบทบาทเป้าหมายไม่มีคนอยู่ จะเกิด routing exception ให้เห็นและแก้ได้
- escalation ไม่อนุมัติหรือปิดงานแทนใคร
Notification หลายช่องทาง
ตั้ง template, กฎการสมัครรับ และช่องทางตามหมวดงานและภาษาของผู้รับ ผู้ใช้เลือกช่องทางและเวลาที่ต้องการได้เอง
- IN_APP, EMAIL, SMS, PUSH และ WEBHOOK พร้อม template ตามช่องทางและภาษา
- Quiet hours และ digest ตามเขตเวลาของผู้ใช้ งานระดับ CRITICAL ไม่ถูกเลื่อนหรือรวม
- Digest แสดงทุกรายการแยกกัน ไม่ใช่แค่ตัวเลขจำนวน
- บันทึกทุกความพยายามส่งและผลลัพธ์ เป็นหลักฐานย้อนหลัง
Approval workflow แบบหลายขั้น
ออกแบบนโยบายอนุมัติเป็น revision ที่มีขั้นตอนเรียงลำดับ แต่ละขั้นระบุสิทธิ์ที่ต้องมี เมื่อเปิดคำขอ ระบบ freeze revision ที่ใช้อยู่ ทำให้กฎไม่เปลี่ยนกลางทาง
- โหมด SERIAL หรือ PARALLEL ตามที่นโยบายกำหนด
- แยกหน้าที่ได้: ผู้ขอไม่อนุมัติคำขอของตัวเอง และการมอบอำนาจไม่ข้ามกฎนี้
- ปฏิเสธผู้อนุมัติที่ไม่มีสิทธิ์ด้วยรหัสที่ระบุสิทธิ์ที่ขาด
- คำขอที่หมดอายุไม่ถือว่าอนุมัติ และเก็บการตัดสินใจก่อนหน้าไว้ครบ
หลักฐาน การวัดผล และการควบคุม
ทุกการกระทำมีร่องรอยตรวจสอบได้ และฝ่ายปฏิบัติการเห็นว่าองค์กรตอบสนองต่องานได้ตามที่คาดไว้หรือไม่
- Audit timeline, dashboard การมีส่วนร่วม และตัวสำรวจ breach
- ตรวจ expectation ตามรอบ และบันทึกเมื่อไม่เป็นไปตามคาด
- แยกข้อมูลระหว่าง tenant และมี test ยืนยัน
- ลบข้อมูลตามรอบ retention ที่กำหนด
สร้างและทดสอบที่ขนาดนี้
ตัวเลขด้านล่างคือขอบเขตของสิ่งที่สร้างไว้และค่าเริ่มต้นตามสเปก ไม่ใช่ผลวัดความเร็วหรือจำนวนผู้ใช้ในการใช้งานจริง
ตัวเลขจากชุดทดสอบและ benchmark ภายในของ CKN ผลจริงขึ้นกับเครื่องและปริมาณข้อมูลของแต่ละระบบ
ธุรกิจของคุณได้อะไร
ไม่มีงานตกหล่นเพราะไม่มีใครเห็น
งานที่ไม่มีคนรับทราบจะถูกส่งต่อให้คนถัดไปตามนโยบาย และถ้าส่งต่อไม่ได้ ระบบแสดงเป็น exception ให้เห็น ไม่ปล่อยเงียบ ลดความเสี่ยงที่งานสำคัญค้างโดยไม่มีใครรู้
ลดต้นทุนการประสานงาน
แทนที่จะให้แต่ละระบบสร้างหน้าจอแจ้งเตือนและอนุมัติของตัวเอง ทุกระบบใช้ inbox และ approval ชุดเดียวกัน ทีมเรียนรู้ครั้งเดียว และไม่ต้องดูแลหลายที่
ควบคุมได้และตรวจสอบได้
การอนุมัติแยกหน้าที่ตามสิทธิ์จริง ใช้กฎที่ freeze ไว้ตอนเปิดคำขอ และเจ้าของงานเป็นผู้ยืนยันผลสุดท้ายเสมอ ทุกการตัดสินใจและการส่ง notification มีหลักฐานให้ตรวจย้อนหลัง
ตัวอย่าง: รับงานเข้า inbox
ใครใช้บริการนี้
- บริการ business ทุกตัวที่ต้องส่งงานให้คนตัดสินใจ
- Integration ซึ่งเรียก Portal แทนผู้ใช้และสั่ง worker ตามรอบ
- Identity สำหรับการเข้าสู่ระบบและตรวจสิทธิ์ผู้อนุมัติ
- Solution รายอุตสาหกรรม ผ่านจุดเรียกของ Integration
POST https://portal.example.com/work/work-item/ingest
Authorization: Bearer <service-token>
X-CKN-Delegated-Context: <signed-delegation>
X-CKN-Tenant-Id: <tenant-id>
X-CKN-Operation-Code: PORTAL.WORK.WORK_ITEM.INGEST
Idempotency-Key: <unique-key>
Content-Type: application/json
{ "sourceService": "<source-service>", "sourceDocumentType": "<document-type>",
"sourceDocumentId": "<document-uuid>", "sourceDocumentRevision": 1,
"raisedAt": "2026-08-16T03:00:00.000Z",
"subjectSummary": "Invoice INV-1 failed three-way match" }
201 { "success": true, "data": { "workItemNo": "WI-2026-000001",
"status": "OPEN", "severity": "HIGH" }, "replayed": false }