Career details
Selected detailed career statements
The full resume is on Resume. This page keeps only a few representative projects in reverse chronological order,
summarized faithfully from the original Problem / Bet / Action / Result career material.
- Problem
- The Channel Manager MVP validated demand for crawling-based reservation sync and overbooking prevention, but it had limits as a stable service. Login changes, security protocols, and product identification issues created reliability and business risks.
- Bet
- Based on operators’ pain and the business learning from the MVP, I believed the product could still be attractive if rebuilt around official OTA/PMS integration technology and the specs of domestic and global OTA/PMS partners.
- Action
- I reset the planning and structure for global OTA/PMS expansion, designed channel-specific processes and rate sync specs, and moved urgent setup/edit work toward self-onboarding. I also designed internal/external notifications and ways to make fast corrections possible.
- Result
- Closed beta stability validation was completed, with official launch and subscription conversion planned. The unstable reservation/inventory/rate sync structure was improved into an integrated structure, reducing operational risk and preparing for official domestic/global OTA integrations, multilingual readiness, and an installation-free service environment.
- Problem
- Hospitality operators sell rooms across multiple OTAs to reduce vacancies, but manually managing inventory, rates, and reservations is complex and stressful. The previous SMS/email parsing approach was vulnerable to OTA message format changes and missing data, causing reservation identification failures and trust issues.
- Bet
- Instead of extracting data from fragile messages, I believed reservation integration would be more stable if the product used RPA to read the OTA web information that operators already saw on their PCs.
- Action
- The OTA channel scope and sync period were expanded step by step: 15 channels, from 1 day to 30 days and then 180 days. To prevent side effects such as missing reservations, we released a sell-stop MVP and validated demand qualitatively and quantitatively through customer satisfaction and inbound demand. Quantity adjustment and paid conversion were also tested later.
- Result
- Reservation sync success reached 97%, and early demand was confirmed through pension customer acquisition and more than 300 inbound leads per month. However, security, CAPTCHA, platform responses, and increasing delays created a gap with consistency expectations. Inventory/sales-status functions were limited, reservation sync remained, and the work transitioned into Channel Manager 2.0.
- Problem
- Merchant applications were handled through KakaoTalk conversations between the support team and store owners. Missing documents and photos, delayed applications, weak handover during vacations or departures, contract delays, and support fatigue repeated.
- Bet
- I believed speed, accuracy, and collaboration would improve if application types and required documents were structured into a web flow connected to back-office handling.
- Action
- I planned and built a web application form connected to the internal back office and T-board DB. Document checklists were split by individual/corporate applicant and business type, and when a KakaoTalk link was sent, back-office record creation and owner assignment followed automatically.
- Result
- Application completion time was reduced from 3–5 days to 1–2 days. Document-missing bottlenecks for contract/support teams decreased, and the flow from submission to registration became automated.
- Problem
- Nationwide store installation was based on on-site visits. One person could install only 2–5 stores per day, creating delays, churn risk, and team overload.
- Bet
- I believed resistance to remote installation came more from customer expectations and internal assumptions than from the actual need for in-person installation.
- Action
- I shared the need for remote conversion internally and ran a 4-week experiment at the Busan branch to collect quality and throughput data.
- Result
- Per-person installation throughput increased from 2–5 stores per day to as many as 20. Remote installation became Spoqa’s standard process, and the project led to Spoqa Mate recognition.