From occasional use
to a working-week habit.
I'm Yun Sol. I created this case to show how I would grow sustained use and paid value for ChatGPT in Southeast Asia.
My proposed first betRecognise when a business operator may benefit from a recurring workflow. Proactively offer guided setup, explain why it appeared, and help them build a useful weekly habit.
The problem to investigate
Users differ in how confidently they define a task, organise context and build a process. Some may need a clearer route from a business question to a repeatable workflow.
My hypothesis
For users who need that help, structured onboarding offered at a relevant moment could improve completion, useful return and paid value.
The key unknown: which users benefit from guidance, and when does an offer help rather than interrupt?
Why I think this is worth testing now
Today's product: ChatGPT already has capabilities for analysing information and building workflows. Projects organise chats, files and instructions. Public product documentation
My framing: the growth question is who needs help reaching that value. Prompting confidence, technical knowledge and existing operating habits may change how much guidance a user needs.
First segment to test: operators returning to similar decisions with new data, while repeating setup or leaving important context unresolved. Users with an effective process may gain less.
The product choice: recognise that pattern before the user asks for a routine. Offer a reusable workflow after the current task, with a short explanation and a choice to continue. Start with context the product is permitted to use.
This is a problem hypothesis, not an interview finding. Research must check prediction quality, segment size and timing. The same approach could support sales, stock or customer reviews; start with one job to test it.
Make it concrete: Maya's Pilates studio.
Maya runs Daylight Pilates, a fictional independent studio in Singapore. She offers group classes with 120 places each week. Evening classes fill; mornings lag. She wants to use spare capacity without cutting prices.
Her recurring job: decide what to change in the class schedule.
Review bookings against available places. Check cancellations and repeat visits when those figures exist. Choose one change, record it, and check the next week's result.
This example shows the proposed method: clarify the business, use the right evidence, choose an action, then follow up. The wider opportunity extends beyond studios or bookings.
Morning classes have the most spare capacity.
| Class time | Bookings / places | Filled |
|---|---|---|
| Morning | 24 / 60 | 40% |
| Evening | 36 / 40 | 90% |
| Weekend | 12 / 20 | 60% |
Morning classes have 36 unfilled places. That is unused capacity, but the counts do not tell us whether timing, format or customer preference is the cause.
Do customers find the morning start too early? Check cancellations and ask recent attendees before changing the schedule.
If feedback points to timing, test one later start. Keep the price and capacity unchanged.
Bookings are not attendance, revenue or unique customers. No customer-retention finding is possible from these totals.
Previous week: “Here are our Pilates bookings. Morning classes have 60 places. Which classes need attention?”
New week: “Here are the new counts. Morning classes have 60 places. What should I check this time?”
Possible pattern: the same business decision, a new reporting week, and repeated setup. Maya has not asked for a workflow.
Would a reusable weekly review help?
You've brought new bookings to this chat more than once. A saved review could reduce setup next time.
Both routes are simulated. The shortcut uses fictional context; a real product would let confident users continue with their own setup.
When would this offer appear?
Initial rule to test: at least two similar business reviews with data from different periods, plus repeated setup or missing context. Repetition alone would not establish a need.
Timing: after the current answer, when the user can judge its value. Explain the signal, make guidance optional, and limit repeated offers after dismissal.
Context boundary: start within the current chat or a user-enabled Project. Wider history access and any ranking model would require product and privacy validation.
Simulation: the pattern above is prewritten. This demo does not monitor activity or run a prediction model. In production, the signals would generate a suggestion; creating or saving a workflow would still need the user's choice.
First, help me understand the decision.
Goal: fill quiet morning classes without discounts. Change the answers below to see how the review changes.
Daylight Pilates · Weekly bookings review
Change the result. Evening stays at 36; weekend stays at 12. The unit and reporting week stay the same.
A better result. Not proof of the cause.
Morning bookings rose from 24 to 30. Check what else changed before crediting the later start.
Your recorded action: ask customers, then test a later start.
Keep the test small. A second week can help you learn; it still will not prove causality.
Why this is a useful weekly job
A class place cannot be sold after the class ends. A weekly review can flag spare capacity while there is still time to act. It also keeps the next review tied to the owner's previous decision.
Why the context step matters
Bookings and attendance mean different things. A later start is useless if class times are fixed. The questions change the analysis and the action, not just the chart.
The opportunity is recognising likely need, presenting the offer well, and choosing the right moment. Existing capabilities do the work. A predicted pattern starts a suggestion, not an automatic workflow.
Prove the habit. Then test how far it travels.
Test who benefits, whether the offer arrives at a useful moment, and whether the structure earns repeat value. A successful studio example alone would not settle those questions.
Current ChatGPT experience
The same signal-eligible users, with the currently verified product flow.
A proactive offer, with optional guidance
After repeated work suggests a need, explain the offer. Let users choose guidance, approve context and return to the task.
More users complete useful work in at least two later weeks.
Define useful completion for the selected job before launch. For Maya, that means a checked comparison and a next decision. Count all assigned eligible users.
How I would run the experiment
Eligible users: signed-in business operators in the initial Singapore pilot whose permitted task history meets a pre-set pattern rule. Research validates need; a user does not have to request a routine. Do not infer technical ability from language or demographics.
Validate prediction first: use consented examples and owner feedback to check whether the signals identify a useful opportunity. Include people incorrectly flagged and people who need help but were missed. Agree an acceptable precision bar before rollout.
Assignment: randomise once by account before the offer. Keep accounts from the same business together where identifiable. Keep acquisition and reminders the same. Include users who decline guidance in the assigned-group result.
Before launch: verify today's journey. Agree baseline segments, sample size, targets and a quality rubric with Data Science. Match observation windows across groups.
Diagnose the journey: measure helpful-offer feedback, dismissal, setup abandonment and correction effort. Acceptance alone does not establish that the predicted need was right. Check useful return and unwanted interruptions.
Read the result: report cohort dates, group sizes, absolute changes and confidence intervals. Pre-specify segment comparisons. A before-and-after improvement alone does not establish impact.
Test transfer: if the first segment works, test another workflow and local market adaptation. Analyse each cohort separately. One successful niche does not validate the whole audience.
Limits: the first experiment tests the combined prediction rule, offer and guided journey. It cannot isolate their individual effects. Follow-up tests should vary one factor at a time.
Check the signals
Observe 6–8 operators. Identify recurring jobs, setup friction and examples where a proactive offer would be unwanted.
Test the prediction and journey
After validating the trigger, run a randomised pilot. Measure useful completion, later return and unwanted interruptions.
Check value and transfer
Read mature cohorts. If the signal holds, test another workflow and refine timing. Begin Philippines discovery before a wider rollout.
What changes in the Philippines?
For the extension, test a fictional business where customers enquire before booking. The review follows enquiries, confirmations and paid bookings. More enquiries alone would not count as business value.
This workflow is a local hypothesis, not a description of every Philippine business. Observe 6–8 operators. Check their channels, language preference, device use and willingness to pay before adapting the journey.
PHP billing and GCash support already exist for eligible paid plans. I would investigate actual checkout friction before proposing another payment option.
Less effort. More useful return. Paid value.
Less setup.
A clearer next decision.
More useful work
across weeks.
Paid value that lasts
and covers its costs.
The expected growth path is easier activation, useful repeat work, and retained paid value. Measure it by segment, task and market. These are proposed pilot targets to agree before testing—not forecasts or validated results.
| Outcome | Metric and proposed bar |
|---|---|
| Easier activation | At least 25% less median time to a useful task than control. Include setup and correction time; check completion and abandonment too. |
| More useful repeat use | At least +5 percentage points in users completing useful tasks in two later weeks, days 8–28. All assigned users in the denominator. |
| Output worth trusting | At least 90% of sampled outputs meet a pre-set quality rubric for the selected job. Check context, missing data and unsupported claims. |
| Sustainable paid value | Positive incremental paid conversion by day 60, with no material deterioration in day-90 paid retention. Check added service costs before expanding. |
A target alone is not enough. Confirm the effect and its uncertainty against the randomised control. The numerical bars are my initial judgement; internal baselines may change them.
What success means for Maya
Immediate value: less time assembling the review, fewer repeated explanations, and a next action that fits her constraints.
Business measures: attendance against available places, cancellation rate, and repeat booking within a defined window. Add aggregate revenue per class if the data supports it.
Evidence still needed: the demo only compares class totals. It cannot identify unique customers, explain customer behaviour or prove higher revenue. Those questions need defined, permissioned data and a longer test.
Useful return and quality clear the agreed bars. Paid value supports a limited expansion. Broader scaling needs evidence from another workflow and market.
Setup improves but return does not, or one job works while another fails. Find which context, value or local condition explains the difference.
The tasks rarely repeat, errors erase the benefit, or added usage does not create enough value to justify its cost.
Help the right users reach recurring value.
Recognise a likely need before the user asks for a workflow. Offer help at a useful moment. Prove that the journey earns completion, return and paid value, then test how it travels across workflows and SEA markets.
I bring more than five years working on complex consumer live products in SEA. In gaming, I have taken products from 0 to 1, led go-to-market work including acquisition, operated live products, and iterated on incremental improvements. I have also owned product P&Ls.
Across SEA and selected APAC markets, I have worked through local customer needs and operating challenges. I combine that experience with hands-on AI adoption: working with specialists and engineers to define useful output, human review and a practical adoption path.
Sources, assumptions & limits
Public-source review: 7 October 2026. No customer interviews have been conducted for this case.
The role covers activation, repeat usage, monetisation and regional experiments. OpenAI role description
Projects already retain context for ongoing work. ChatGPT accepts context and follow-up questions. Projects documentation · Using ChatGPT
Local billing and Philippine GCash support are documented. Billing documentation
Some occasional users may need more help defining their goal and supplying context. This is a hypothesis, not a measured flaw in ChatGPT's current behaviour.
Maya, Daylight Pilates, class figures and responses are fictional. The prototype uses fixed writing and deterministic calculations. It has no live AI or integration.
The pilot targets are proposed success criteria, not predicted uplift. Test useful return before adding reminders or upgrade prompts.
The true friction, task frequency, local demand, current product experiments, willingness to pay and internal economics. Verify whether this guided journey already exists.
Career examples are based on my own accounts. No unverified historical retention uplift, campaign budget or attribution claim is used.
Before production: verify today's journey, privacy and retention controls, plan access and event definitions. Context must remain reviewable and removable. The demo uses aggregate figures and clears state when the page reloads.