The sale is complete, but the customer's work has just begun. They need to open the file, understand the instructions, receive the promised item, or recover when something goes wrong.
A product's lifecycle is everything that happens from its first release through updates, support, and eventual retirement. AI can help organize those tasks. The business still needs to decide what it promises, who owns the work, and how it knows a change reached the customer correctly.
Your work product is a lifecycle plan for one product: its release record, support route, update process, and retirement approach. Cedar Desk Studio remains fictional. The Job Log Starter Kit is still a draft prototype, and the BOX-12 listing remains a proposed commerce example. No product has been sold or released through this exercise.
Write the promise before you write the policy
Start with what the customer receives. Is it a one-time download, a physical item, an ongoing service, or access to software? What formats, features, and support are included? What additional accounts or subscriptions does the buyer need?
Make those statements consistent across the product page, checkout, receipt, file instructions, and support answers. A promise of lifetime updates creates a different obligation from a clearly described current-version download. Do not let generated copy casually add unlimited support, guaranteed compatibility, or perpetual access.
For the proposed Job Log kit, a draft promise could be:
A static CSV job-log template, a fictional worked example, and a user guide. It records responsibility and next actions but does not send reminders or synchronize with other systems.
Commercial price, support availability, update entitlement, and refund terms still require a real business decision before sale. The teaching prototype does not establish them.
Keep a release record someone can inspect
Give each release an identifier and preserve what it actually contains. A release record should include the files, source and rights records, known limitations, checks performed, approval, and publication or delivery evidence.
| Record field | Prototype example |
|---|---|
| Product | Job Log Starter Kit |
| Version | 0.1 draft |
| Files | User guide, blank CSV, example CSV |
| File checks | Structure and sample-rule checks recorded separately |
| Customer usability evaluation | Not performed |
| Compatibility evaluation | Not performed in customer software |
| Commercial approval | Not recorded |
| Released to buyers | No |
This prevents a draft from becoming “version 1.0, tested and ready” merely because someone renamed a folder. A hash can help establish that two copies have the same bytes; it does not establish that the product is correct or usable.
For products with an AI feature inside them, record the model and relevant configuration too. A provider change may alter answers, costs, or behavior even when your interface looks unchanged. Evaluate the tasks and failures that matter before broadening use of a changed configuration.
Design support for the question behind the ticket
Use the answer, handoff, and recovery principles from Part 5. A support record should identify the customer's product version, relevant environment, stated problem, what has been tried, and the next owner.
For a static template, the most useful question may be “Which application did you import it into?” For a missing physical order, it may be the verified order and shipment record. Do not request a full customer database when a redacted example row will answer the question.
Give the customer an actual route to help and state its staffed availability accurately. A chatbot can collect context, but it should not pretend that a specialist accepted the case or invent a resolution time.
Use AI to draft a reply from the relevant version's documentation. An answer based on a later release may tell the customer to use a feature they do not have. If the source is unclear, preserve the uncertainty and route the issue rather than repeating the same confident advice.
Classify the issue before choosing the remedy
A useful product-support queue distinguishes at least these situations:
| Issue | First question to resolve |
|---|---|
| Download or delivery failure | Was the correct product delivered and can the buyer access it? |
| Import or compatibility problem | Is the customer's environment supported, and what actually happened? |
| Unclear instructions | Which task or step could the customer not complete? |
| Defect | Does the delivered product fail its stated specification? |
| Missing expected feature | Was the feature promised, misunderstood, or never included? |
| Cancellation or refund request | What was sold, what terms and applicable rules govern it, and who can decide? |
Do not automatically answer every digital refund request with “downloads are nonrefundable.” The applicable obligations depend on the offer, facts, location, and platform rules. Likewise, a manager's approval process must not become a way to ignore required customer remedies. Obtain the relevant current guidance when establishing the real policy.
For covered US merchandise orders, the FTC describes shipment promises and required handling when the seller cannot ship on time, including customer delay choices and cancellation or refund requirements. Check the full rules for the actual situation. See the FTC merchandise order guide.
Keep proposed remedies separate from authorization and execution. “Refund requested,” “refund approved,” and “refund completed” require different evidence. A support summary should not collapse them into one field.
Update the product without damaging customer work
Suppose Cedar proposes adding a priority field in version 0.2 of the Job Log kit. This change has not been made to the supplied prototype. Before release, consider what happens to someone's existing version 0.1 file.
The update should preserve existing rows and identifiers. It should not silently label old work “high priority” or overwrite the customer's notes. A proposed migration can add the new field as blank and explain how the user may assign it under their own process.
Keep a copy of the original file and test the proposed migration on constructed data. Check row counts, identifiers, dates, and values before and after. Include empty files, unexpected columns, and invalid rows. If the input cannot be interpreted safely, report the issue instead of guessing.
Use a clear change note: what changed, who needs the update, what the user must do, and known limitations. Distinguish a correction to misleading instructions from a new optional feature. A material error may require a direct correction to affected buyers, not just a new file on a page they never revisit.
Investigate a defect from evidence
Consider a simulated report: a buyer says dates changed during CSV import. That report does not yet prove the file contains bad dates or that a particular application is defective.
Collect the affected version, a minimized sample, the import settings, and the resulting values. Compare the original text with the imported data. Possible causes include automatic date conversion, ambiguous display formatting, or an error in the source file. Keep them as hypotheses until the evidence distinguishes them.
Prepare a product-support investigation from these records.
Separate the user's report, verified observations, and cause hypotheses.
Identify the smallest additional example or check needed.
Draft a clear next step using the documentation for the affected version.
Do not invent compatibility, reproduce a result that was not observed,
claim an update was delivered, approve a refund, or mark the case resolved.
List whether the proposed repair also requires an instruction change,
customer notification, or a focused regression check.
After a real repair, test the affected task and nearby behavior that the change could disturb. Preserve the results and the restart decision. Fixing the current download does not establish that an earlier buyer received the correction.
Make maintenance part of the economics
A product with low delivery cost can still have meaningful support and maintenance costs. Track support time, refunds, failed deliveries, changes in external tools, and the work required to keep instructions current.
For the kit's planning example, a $4 support allowance at an assumed $30 hourly labor cost represents eight minutes per sale. If a real pilot later averages twenty minutes of support, that labor alone would cost $10 per sale under the same rate. The original economics would need revision.
These are hypothetical calculations, not observed support averages. They show why it is useful to measure support effort before expanding an offer. Reducing unnecessary confusion may improve both customer experience and contribution more than producing additional products.
For products that use AI continuously, include model usage, retrieval, hosting, evaluation, abuse prevention, and human escalation in the cost model. NIST's voluntary AI Risk Management Framework treats risk management as part of an AI system's ongoing design, use, and evaluation. It is a useful reference for assigning responsibility, not a certification of the product.
Plan for an orderly end
Products may become obsolete, uneconomical, unsupported, or inconsistent with a supplier's terms. Decide how you will stop new sales, preserve necessary purchase records, support existing commitments, and explain available alternatives.
For an online service, customers may need a way to export their data and a clear end date. For a downloadable file, explain which support or update commitments remain. For physical stock, distinguish discontinuation from a temporary shortage and keep existing order obligations visible.
Do not erase customer work or purchase evidence because an item disappears from the catalog. Apply the appropriate retention and deletion arrangements, and give affected customers the notice and options their situation requires.
End each lifecycle review with a concrete decision: maintain, repair, extend, limit new sales, or retire. Assign an owner and evidence for completion. A product remains useful when the business keeps its promises after the excitement of launch has passed.
Next: Part 7 covers Finance, beginning with costs, ROI, and cash payback.