How to Configure and Use the MyCover.me Warranty Policy Engine

Before you configure a policy

Start with the warranty promise your business has actually approved and can fulfill. MyCover.me structures that promise and applies it consistently; it does not create warranty terms, certify legal compliance, or become the coverage issuer.

Confirm the issuer, covered products, duration, effective date, covered problems, exclusions, required evidence, transfer rules, and available remedies with the people responsible for legal, product, and support operations.

• Use plain language that matches the warranty document buyers receive before or at purchase.
• Keep manufacturer, merchant, retailer, and third-party coverage as separate entitlements when different issuers are responsible.
• Do not require registration or a QR scan to start coverage unless the real, legally reviewed policy explicitly and lawfully requires it.
• Decide which exceptions always need a person, including statutory rights, goodwill, safety concerns, recalls, and disputed proof of purchase.

1. Create the policy as a draft

1. 1
   Open Warranty policies

   In the MyCover.me Console, open Products, choose Warranty policies, and select New policy.

2. 2
   Set the policy identity

   Enter a durable policy name, effective date, coverage duration in days, and a change reason that another operator can understand later.

3. 3
   Describe the promise

   Add one plain-language covered item per line, then record exclusions separately. The wording should match your approved customer-facing terms.

4. 4
   Save without affecting buyers

   Saving keeps the version in Draft. Drafts are safe to revise and are not used to issue coverage or evaluate a claim.

2. Configure applicability, evidence, and limits

Configure only rules your team can verify from reliable data. A precise rule with no trustworthy input creates manual work rather than useful automation.

• Product applicability: select the exact tenant catalog products covered by this policy. Leave the scope broad only when the policy genuinely applies to every product in the program.
• Purchase channel: choose online store, retail store, dealer, marketplace, or other channels when the warranty differs by channel.
• Issue categories: identify covered and excluded problem categories. The same category cannot be both covered and excluded.
• Buyer and product evidence: require original-purchaser verification, serial/device ID, verified order or proof of purchase, photo, or video only when the policy and operational process need it.
• Claim and replacement limits: set a number only when the written terms support the limit and your service history can count it reliably.
• Goodwill review days: optionally flag recently expired cases for human review. This does not extend coverage or promise service.

3. Review and publish an immutable version

Select Review changes to compare the draft field by field. Confirm the effective date, duration, covered and excluded issues, evidence requirements, limits, matching catalog products, and the number of existing products that will remain on the previous version.

The server blocks missing or archived catalog references and reports overlapping active policy scopes. An overlap needs a separate acknowledgement and an explicit policy choice during manual issuance; it is never silently resolved by the interface.

Publishing makes that exact version available for matching purchases from its effective date. Published versions cannot be edited. To change the program, create the next draft from the current version, record why it changed, review the difference, and publish the successor.

4. Issue coverage from the sale—not from registration

When an eligible order or product is imported, MyCover.me selects the published policy version applicable to the purchase date, product, and channel. It then creates a separate coverage entitlement with its issuer, start and end dates, source, and verification provenance.

The buyer can remain unclaimed. A later QR scan, order recovery, receipt review, or merchant-assisted link connects ownership to the existing product and coverage record; it does not restart the warranty clock.

5. Evaluate a warranty claim inside Support

1. 1
   Open the product-aware case

   Review the buyer, exact product, purchase, coverage issuer, verification level, prior service history, conversation, and submitted evidence.

2. 2
   Run the warranty evaluation

   Use the Warranty evaluation action only when coverage eligibility matters. A general support request does not need to become a warranty claim.

3. 3
   Read every check

   Review PASS, FAIL, MISSING, and NOT APPLICABLE results for the pinned policy version rather than relying on a single badge. The coverage window is checked against the original Support submission date, not the day an agent clicks Evaluate.

4. 4
   Request only missing evidence

   If a serial, receipt, photo, or video is missing, ask for that specific item. When it arrives, select Re-evaluate current evidence.

5. 5
   Record the human resolution

   An authorized agent chooses and confirms the actual outcome, including troubleshooting, repair, replacement, refund, store credit, goodwill service, rejection with a documented reason, or no action.

How to interpret the result

• Eligible: all required deterministic checks passed. An authorized agent still confirms and records the operational remedy.
• Needs review: at least one fact failed, is missing, conflicts with the pinned policy, or requires human judgment. It is not an automatic denial.
• Not applicable: the rule was not configured for this policy and should not influence the result.
• Expired but in goodwill window: coverage remains expired; the case is highlighted for an optional human goodwill decision.

A practical operating checklist

• Have an owner review drafts before publication and restrict publishing permission to appropriate workspace roles.
• Test representative products, purchase channels, issue categories, missing evidence, expired coverage, and historical claim limits before using a policy broadly.
• Review Needs review cases for patterns that indicate unclear terms, bad commerce mappings, unnecessary evidence, or a product-quality problem.
• Preserve buyer communication and the final resolution in the product service timeline.
• Review policies when products, channels, warranty promises, regulations, or support remedies change—without moving existing entitlements to a new version silently.
• Retire a family to stop future use, archive it only when an Owner needs to remove it from the active library, and restore it if future issuance should resume. None of these actions rewrites existing entitlements.