Career Details, hello.ignoramus.work

Career details

Initial validation, Channel Manager MVP

Channel Manager: MVP & Market Validation

2022.10–present, Vendit, PM

Problem: An operator's top priority is minimizing vacancy, so they list the same rooms across many OTAs and sell beyond actual inventory. The more channels they add, the higher the operational complexity and management fatigue. The earlier approach synced reservations by reading the SMS and email operators received, but when a channel changed its format or data was missing, reservations were hard to identify.
Bet: Instead of scraping volatile SMS and email, I judged that using RPA to read the OTA screens operators already managed on their own PCs would make reservation sync more stable.
Action: I expanded the integrated channels and sync window step by step, shipped a sell-stop MVP to prevent overbooking, then introduced inventory adjustment.
Result: Early demand was confirmed, but as channels grew, we ran into stability issues driven by changes in the external integration environment. Since a channel's inventory and rates tie directly to an operator's revenue and reviews, I reconfirmed this is a market where consistency and stability are the baseline, more than feature breadth. We kept only reservation sync on the unstable product and, using the failure as a springboard, kicked off the Channel Manager rebuild.

Follow-up redesign, Channel Manager rebuild

Channel Manager: Integration Redesign & Launch

2022.10–present, Vendit, PM

Problem: Reading OTA screens to collect reservations carried heavy external dependencies on screen changes, login/auth changes, security policies, and product identification, so it could not stay stable. The risk that an unstable product and low trust would eat into other business opportunities was high, so we stopped expansion and cut features. Still, a significant share of existing customers wanted inventory adjustment, reconfirming that even though the solution had failed, the market problem was real.
Bet: I judged that if we first secured stable integration technology and redesigned the structure to absorb domestic and global OTA/PMS specs, expansion beyond Korea to global markets would be possible.
Action: Centered on unifying reservation, inventory, and rate sync, I implemented the rate-sync spec and built the product to high consistency, with a structure extensible to Korean-motel-specific check-in/out control and day-use booking.
Result: After a closed beta validated stability, it launched as a paid product and moved to a subscription model, with official domestic/global integrations and a multilingual environment in place, and it has operated stably since launch.

Scope-reduction decision, Concierge pruning

Vendit Concierge: Scope Diagnosis & Pruning

2022.10–present, Vendit, PM

Problem: When I joined, even stores that had already completed card-merchant registration had to go through a separate payment integration once more to use the service, a structural problem. On top of that, room-service features beyond the payment piece, which still needed validation, were piling on with no prioritization, and the launch kept slipping.
Bet: I judged that shipping the high-margin upsell features with early marketing demand first, like early/late checkout, and deferring the rest would let us read the market faster.
Action: With scope that discussion could not narrow, I sorted the overgrown spec by priority, cut it substantially, and shipped only the core early/late-checkout payment module first as an MVP, aiming to ship fast and realign from results.
Result: Early/late checkout proved margin, but since using it required payment integration, it was hard to spread quickly. Judging it was not worth restructuring around, I kept only the core, stopped further work, and reallocated resources to Channel Manager.

Internal-ops automation, rental daily report/chatbot

Rental-Site Daily Report & Chatbot Automation

2021.10–2022.08, Salda, PM

Problem: Headquarters, sites, and field managers each counted the same metrics differently. Manually compiling and verifying each rental site's vacancy, contract, deposit, and rent status took about an hour a day per site, and the mismatched definitions even bottlenecked product development.
Bet: Before producing more numbers, I judged that daily-report automation and a chatbot would only earn trust once HQ, sites, and managers agreed on a single shared definition of each metric.
Action: I led communication with external stakeholders to agree on metric and terminology standards, and built a process to share and confirm the finalized decisions with decision-makers. On top of that I built a per-site daily-report dashboard that managed, verified, and exported contracts, vacancies, deposits, and rent, and integrated a chatbot handling rent, vacancy, contract extension/termination, complaints, and parking registration.
Result: Per-site daily reporting dropped from about an hour a day to five minutes, and the chatbot cut inbound calls by about 30% on average. The product-development bottleneck caused by mismatched metrics was cleared along with it.

Renewal management, internal operating system

Contract Renewal Management Process

2019.12–2021.10, OKPOS, PM

Problem: There was no way to see which of some 40,000 VAN dealerships was due for renewal and when, so each rep leaned on spreadsheets every management cycle, pulling the target list by hand. The bigger problem: data reliability varied by who pulled it and progress was hard to track, making consistent renewal management impossible.
Bet: I judged that a system auto-creating renewal tasks per rep from 30 days before expiry, with alerts and automatic regional assignment, would prevent avoidable churn and let us track renewal progress.
Action: I built a workflow that auto-generated renewal tasks from each contract's end date and auto-assigned a regional rep. It judged keep/churn/grace status from each store's performance, forced handling within the renewal window, connected to the e-contract system to unify the process, and tracked progress on a dashboard.
Result: It built an environment to manage churn risk proactively before expiry, eliminated the renewal-management gaps left by having no system, and established a process trackable by month and by person.

Card merchant application automation

Card Merchant Application Automation

2019.12–2021.10, OKPOS, PM

Problem: Card merchant applications were handled over 1:1 KakaoTalk between the support team and store owners. Required documents differed by industry, business type, and individual vs. corporate, so staff had to walk each applicant through the paperwork every time, and when applications piled up or a rep changed, progress was hard to track.
Bet: I judged that switching to a structure where owners enter the documents fit for their own store and the support team only reviews would streamline the work and digitize intake from the first step, leaving no gaps.
Action: I built a web form for owners to apply directly and branched required documents into checklists by industry, business type, and individual/corporate. Each application was auto-assigned to a rep, and status and lead time from document review to registration were tracked on a dashboard.
Result: The step where reps walked owners through documents disappeared, shifting to review-centered handling; the whole apply, revise, register flow was systematized, cutting document gaps and reducing merchant-application lead time from 3–5 days to 1–2 days on average.

Remote installation operating standard

Remote Installation: Transition to an Operating Standard

2014.12–2019.03, Spoqa, Partner Support Team

Problem: Spoqa made on-site installation the default for every product in the name of training quality, capping one person at 2–5 stores a day. As adoption grew, installations backed up and the staffing burden rose, yet there was a contradiction: remote was allowed for islands and mountain areas on travel-distance grounds, while city stores were held to on-site only.
Bet: I saw resistance to remote as a mere assumption born from never having tried it, and judged that proving installation and training quality and throughput with data could make remote the default.
Action: I ran a 4-week remote-installation experiment in the Busan and South Gyeongsang region to gather quality and throughput data, then made the internal case.
Result: Per-person daily installs rose from 2–5 to as many as 20, building a base to absorb demand spikes without delay, and it became the trigger for remote installation to become Spoqa's standard process.