ผมไม่ได้เริ่มจากการอยากสร้าง SaaS แต่เริ่มจากปัญหาการทำงาน

เมื่อเห็นว่า HostDrift มีทั้ง CRM, CDP, Consent, Quotation และ Inventory หลายคนอาจคิดว่าผมเริ่มต้นจากการวางแผนจะสร้าง SaaS หลายระบบให้ครบชุด แต่จุดเริ่มต้นของผมไม่ได้เป็นแบบนั้น สิ่งที่มาก่อนชื่อผลิตภัณฑ์และรายการฟีเจอร์ คือคำถามจากการทำงานจริงว่า ทำไมบางเรื่องที่ควรทำได้ง่ายยังต้องใช้หลายขั้นตอน ทำไมคนทำงานต้องคอยจำรายละเอียดแทนระบบ และเราจะออกแบบวิธีทำงานให้ต่อเนื่องกว่านี้ได้อย่างไร

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

แยกให้ออกระหว่างสิ่งที่อยากได้กับปัญหาที่ต้องแก้

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

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

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

ก่อนวาดหน้าจอ ต้องมองเห็นงานตั้งแต่ต้นจนจบ

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

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

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

เริ่มจากงานหนึ่งเรื่องที่เดินได้ครบวงจร

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

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

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

ความเรียบง่ายบนหน้าจอ ต้องมาจากความชัดเจนเบื้องหลัง

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

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

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

ประสบการณ์ช่วยตั้งต้น แต่ไม่ใช่คำตอบแทนผู้ใช้ทุกคน

ประสบการณ์ด้าน CRM, Digital Marketing, Customer Data และ Business Operations ช่วยให้ผมมองเห็นโจทย์และตั้งคำถามได้เร็วขึ้น แต่ผมไม่อยากใช้ประสบการณ์ของตัวเองเป็นข้อสรุปว่าทุกทีมต้องทำงานเหมือนกัน วิธีที่เหมาะกับทีมหนึ่งอาจไม่เหมาะกับอีกทีม แม้อยู่ในธุรกิจประเภทเดียวกันก็ตาม

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

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

บางครั้งคำตอบก็ยังไม่ใช่การสร้างซอฟต์แวร์ใหม่

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

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

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

สิ่งที่อยากให้ HostDrift สะท้อน

ไม่ว่าจะเป็น CRM, CDP, Consent, Quotation หรือ Inventory คำถามที่ผมอยากใช้กับทุกระบบยังเป็นคำถามเดียวกันว่า คนทำงานกำลังติดอะไร และระบบจะช่วยให้เขาทำงานนั้นต่อได้ดีขึ้นอย่างไร แต่ละ Platform อาจรับผิดชอบคนละเรื่อง ทว่าผมอยากให้มีแนวคิดร่วมกันคือหน้าที่ชัดเจน ใช้งานเข้าใจง่าย และพัฒนาจากความต้องการที่มีเหตุผลรองรับ

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

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