A merchant tries an app, produces a useful weekly report and compliments the result. Three weeks later, the account has not completed another report. The demo worked. The recurring product has not yet found a place in the merchant’s work.
The missing piece may be a routine rather than another feature. A useful software habit connects a real recurring trigger to a manageable action and a result the customer values again. Return visits, notification clicks and long sessions are weaker evidence when they do not complete that useful cycle.
This chapter of The AI Software Factory examines recurrence after first value. The term habit describes a proposed dependable working routine here; it does not assume that every product needs daily attention or that repeat engagement proves customer benefit.
Start with the natural cadence of the job
A weekly purchasing decision, a monthly reconciliation and a one-time migration have different rhythms. Designing all three around daily logins creates unnecessary work and misleading measures.
Ask when the underlying need returns and what creates it. A new source report, a closing deadline, a changed inventory position or a scheduled meeting may be the trigger. The product should fit that event rather than manufacture one to increase engagement.
For a hypothetical merchant diagnosis app, a weekly source export may make a weekly routine plausible. If the merchant only makes purchasing decisions monthly, weekly reminders could create noise without value. Discovery should establish the cadence with actual users before the product treats it as a fact.
Some good products are deliberately episodic. A retirement export, a security incident tool or a project migration may be used rarely and still justify its price. Evaluate recurrence only where the promised job recurs.
Write the recurring loop in plain language
Describe the loop without product jargon: the relevant report arrives; the merchant submits it; the app identifies exceptions; the merchant reviews and records a decision; the next report reveals what changed.
Each link should have a reason to exist. The trigger should correspond to new information. The action should be feasible in the customer’s context. The result should support the same useful job promised in the offer.
Look for a broken link before adding reminders. The customer may lack fresh data, find upload tedious, distrust the result or not know what to do afterward. A notification solves only a missing prompt, and sometimes not even that.
The loop also identifies what can be safely automated. Fetching an authorized report may reduce routine effort. Automatically changing listings is a different authority question. Safe writes should govern consequential actions rather than letting a retention goal expand permissions.
Measure repeated value rather than repeated presence
A session count records presence. A repeated accepted report records more of the intended work. Define the recurring value event with the same care used for first value.
For a proposed app, record completed cycles with valid source data and an accepted result. Distinguish reruns correcting the same failed job from new useful cycles. Otherwise, a confusing product can appear highly engaging because customers keep retrying it.
Choose an observation window appropriate to the task. A monthly workflow cannot be judged by seven-day return behavior alone. Record which accounts had a real opportunity to repeat the job before labeling them inactive.
Include customer outcomes and burden in the review. A recurring cycle that saves processing time but creates growing review effort may not be sustainable. The metric should not reward the app for demanding more attention than the work requires.
Preserve the setup that makes repetition easier
Customers should not have to rebuild a valid mapping or re-enter stable preferences every cycle. Preserve useful setup with clear account boundaries and ways to change it when the source changes.
A saved mapping should also record enough context to detect incompatibility. If a source column now means something different, blindly reusing the old mapping can produce a fast incorrect result. Convenience must remain connected to validation.
Show what was retained. A customer returning after several weeks should understand which source, account and report settings the next run will use. A visible summary is more useful than hidden defaults that only become apparent after processing.
Privacy design addresses retained data and deletion. Recurring convenience does not justify keeping every input indefinitely. Decide which configuration must persist, which evidence helps comparisons and which raw material can expire.
Let the customer choose the trigger
A notification works best when it arrives where the customer expects to act. Ask about channel, timing and cadence rather than assuming a daily email fits every workflow.
Offer a simple way to pause or change reminders. A merchant on holiday or between reporting periods should not have to cancel the whole product to stop irrelevant prompts. Respect quiet periods and account role boundaries.
Explain the trigger in useful terms. “Your weekly source is ready for review” tells the customer why the app is contacting them. “You have not logged in recently” describes the app’s interest in engagement, not the customer’s job.
Do not send sensitive details through a channel whose recipients or visibility are uncertain. A reminder can state that a report is ready without including private financial rows. The notification’s data boundary should match the product’s broader promise.
Make the return path easy to recognize
A returning user needs orientation, not the entire first-time tutorial again. Show the current cycle, last accepted result and the next meaningful step. Avoid leaving them at a generic dashboard where they must remember the workflow.
If the source or product changed, explain the relevant difference. A new required field deserves a short update and a correction path. A hidden change that makes the old routine fail creates frustration precisely when the product needs to establish dependable repetition.
Preserve interrupted work where appropriate. The customer may begin review, answer an urgent call and return later. A saved state with a clear freshness boundary can support the routine without applying a decision prematurely.
The shortest return path still needs material review. A one-click repeat action should not reuse a stale approval for different amounts or recipients. Convenience applies to preparation; consequential commitment must remain tied to the current payload.
Give feedback that helps the next decision
Recurring software can show changes across cycles: newly flagged items, resolved discrepancies or persistent exceptions. That feedback makes the present result easier to interpret and gives the customer a reason to continue the useful routine.
Explain the comparison basis. If the source date range or account scope changed, the difference may not represent a real trend. A visually dramatic chart can mislead when it compares unlike periods.
Keep unresolved issues visible without turning them into shame. A customer may reasonably defer a recommendation because of information the app lacks. Allow the reason to be recorded so the same suggestion does not return as if no decision occurred.
For a hypothetical merchant app, “Deferred because supplier minimum is too high” can guide the next cycle. The record should support the merchant’s work, not imply that following every model suggestion is the desired engagement behavior.
Avoid manipulative recurrence
Artificial streaks, alarming messages and difficult cancellation can produce activity while weakening the customer relationship. A routine should help people complete work they already value, with control over when and how to participate.
Distinguish a real consequence from manufactured urgency. A closing deadline may matter. A warning that an account will lose an arbitrary streak is a different kind of pressure. Use the product’s actual task context to explain timing.
Make declining a recommendation and pausing a routine legitimate choices. If the interface treats every dismissal as failure, the customer may learn to ignore the system or click through without meaningful judgment.
Trust in software links predictable behavior to recourse. Retention built through surprise charges, hidden renewal terms or exit friction is not evidence that customers continue receiving useful value.
Investigate inactivity without assuming the cause
An inactive account may have solved its problem, changed jobs, lacked new data, encountered a failure or chosen a better alternative. A generic reactivation message does not distinguish these cases.
Look at the last completed state and, where appropriate, ask a narrow question. Did the customer have another relevant job? Could they obtain the input? Was the prior result useful? Keep the request respectful and avoid exposing private activity to the wrong account member.
A customer who completed one successful migration and left may be a satisfied episodic buyer. A weekly user who stopped after repeated unexplained errors suggests a different problem. The product’s intended cadence gives the investigation context.
Record uncertainty when the reason is unknown. Do not convert silence into a convenient narrative about price or feature demand. An honest unknown can guide a bounded follow-up rather than justify a large redesign.
Separate customer retention from revenue retention
An account can remain subscribed without using the product. Another can use it regularly while paying less after reducing scope. These patterns have different implications for customer value and economics.
Track useful recurrence alongside commercial behavior. A growing recurring-revenue total does not establish that each cohort receives value or that delivery costs remain sustainable. The pricing and contribution chapters examine those financial boundaries.
Be clear about the metric definition. Does an account count as retained because it pays, because it completes a useful job or because it has not canceled? Each can answer a legitimate question, but none should be silently substituted for another.
A proposed retention review can compare paid status, accepted cycles and attributable support burden. It should also preserve refunds and downgraded accounts so a favorable total does not conceal customers whose experience deteriorated.
Test one recurrence mechanism at a time
A saved mapping, a better return screen and a reminder schedule can each affect repeat use. Changing all three at once may improve the product while leaving the team uncertain which mechanism mattered.
Choose a bounded hypothesis. For example: customers with ready source data fail to repeat because they must recreate setup; preserving validated mappings should increase accepted second cycles without increasing mapping errors.
Use independent acceptance criteria and protected cases. A saved mapping must detect a changed source schema. A reminder must respect a pause. A return shortcut must not bypass current approval. Commercial engagement should not override these requirements.
The OpenAI evaluation guidance recommends task-specific cases including realistic, edge and adversarial conditions. That principle supports checking the AI result inside a recurring workflow; it does not supply measured evidence about customer habit formation.
Allow the routine to evolve
A customer’s work changes. Team roles, source formats, frequency and decision authority may differ after several months. A dependable routine needs ways to update these settings without losing context.
Show who owns the recurring schedule and where results go. If that person leaves, the account should be able to transfer responsibility through an authorized process. Sending sensitive reports indefinitely to an obsolete recipient is both a workflow failure and a data concern.
Review automatic sources when access changes. A job that repeatedly fails because a connection was revoked should become visibly paused, not continue silently consuming retries. Explain what an authorized person can do to restore it.
Treat renewed consent or authority as a meaningful boundary when needed. The fact that the account once used a routine does not authorize every later expansion of data use or external action.
Recognize when habit is the wrong objective
A product may create more value by removing itself from the customer’s attention. An authorized background check can notify only when a meaningful exception appears. Frequent logins would then be evidence of unnecessary friction rather than success.
Define the desirable relationship explicitly. Does the customer need a weekly review, an occasional exception alert or one completed project? Choose measures that fit that relationship.
A background product still needs evidence that it operates correctly. Customers should be able to inspect last successful checks, current scope and unresolved failures. Silence should mean no relevant exception only when the system can support that interpretation.
Avoid converting every useful app into a community, daily destination or content feed. Those features create additional obligations. Add them only when they serve the customer’s recurring job and can be delivered within the product’s economics.
Keep shared routines from becoming duplicate work
A team account can create a special recurrence problem: two people receive the same prompt, both prepare a report and each assumes the other will make the decision. More activity then produces less clarity.
Give the cycle an owner and a visible state. A teammate should be able to see that a report is being prepared, awaiting review or accepted. Collaboration should preserve the account boundary and avoid revealing private work to someone whose role does not allow it.
If ownership is transferred, record the handoff and the current decision status. A transfer should not imply that the new owner approved a recommendation or accepted a charge. It changes responsibility for the next step, not the evidence of a prior action.
A proposed team test would have two users return during the same cycle. The desired result is one understandable workflow with clear participation, rather than duplicate external writes or competing final reports.
Close a cycle without erasing its lessons
The routine needs a clear end. After the customer accepts, rejects or defers the result, show that state and what the next cycle will do. Leaving every old report marked “pending” creates an accumulating obligation that customers may eventually avoid.
Preserve the decision and relevant evidence according to the stated retention policy. A closed cycle can still inform comparisons and support, but it should not repeatedly demand attention unless new information changes the situation.
If the app reopens an issue, explain why. A changed supplier lead time or newly inconsistent source can justify renewed review. An unchanged recommendation returning merely because a timer fired makes the routine feel insensitive to the customer’s prior work.
What Would We Do at Salars?
For a proposed merchant diagnosis app, we would first verify the decision cadence with intended users. A weekly routine would be a hypothesis based on the merchant’s actual report and purchasing schedule, not a default chosen to increase visits.
We would define an accepted repeat cycle, preserve validated setup and show meaningful changes from the prior report. The customer would control reminder timing and could record a deferral without being pressured to accept the recommendation.
A proposed experiment would examine whether retaining the mapping improves second-cycle completion while preserving detection of changed source fields. It would include an interrupted review, an expired integration and a paused reminder as protected cases. No measured retention result is claimed here.
We would review paid status separately from useful recurrence and support work. If customers paid but did not obtain ongoing value, the response would be to investigate the relationship, not celebrate the revenue alone. If the job proved episodic, we would reconsider the recurring offer.
A good routine earns its return through the next useful result. The broader AI collection explores the authority, evidence and economics that make such repetition sustainable.
Sources
- OpenAI: Evaluation best practices — task-specific and edge-case evaluation guidance for the AI component; not evidence of retention effects or a recommendation to depend on the retiring hosted Evals platform.
Loading comments…