Answer a consumer claim under Latvian consumer law

When to use

A consumer (a private person) has put a written claim to the company about goods or services bought in Latvia, or the company has received a referral from PTAC or an ADR body. Not for a business customer dispute — that runs on contract terms, use ops.customer-complaint. Not for a payment card chargeback the bank opened — answer the bank's process, and use this playbook only for the parallel claim. A claim that also alleges a safety defect goes to management.decision-record first — the product question outranks the individual claim.

Before you start

• The claim is in writing and dated; if it arrived by phone, ask for it in writing — the deadline runs from
• The order record is findable: invoice, delivery date, what was bought, which channel.
• The agent has read access to the legal-corpus module and to prior answers for the same product line.

What a run requires2

The trail8 steps

1. S1

   Log the claim and start the clockagent

   Record receipt date, channel, claimant, product, demand. Create the deadline as a task (bc tasks add).

   Done when the claim record exists and the deadline date is visible on it.

   ⛔ The deadline runs from receipt by the company, not from when someone first read the mailbox.

2. S2

   Collect the factsagent

   bc mail search the whole correspondence with this customer; pull the invoice, delivery confirmation, warranty terms shown at sale, and photos or evidence attached.

   Done when a one-page fact sheet lists what was bought, when, what the customer says, and what the company's own records say — with links.

3. S3

   Check the rulesagent

   In the legal-corpus module, classify the claim: statutory warranty claim for a defect, right of withdrawal (distance sale — ⚠ verify the withdrawal window and its exceptions in the Latvian transposition of Directive 2011/83/EU), service-quality complaint, or goodwill request with no statutory basis. Note what the law allows and what the company has done for comparable claims before.

   Done when the fact sheet names the applicable basis and the possible outcomes: repair, replacement, price reduction, refund — and which the customer may choose. ⚠ verify the exact remedies and who chooses, per the Consumer Rights Protection Law and Civillikums.

4. S4

   Decideownerneeds approval · owner

   Approval · S4 · owner — the run stops until a named person records the decision

   Present the fact sheet, the legal basis, the cost of each outcome, and a recommendation.

   Done when the owner has chosen: accept in full, offer a partial remedy, or reject with reasons.

5. S5

   Draft the answeragent

   Use the template from the legal-corpus module; state the facts, the decision, the reasoning, what the customer should do next, and how to escalate (PTAC contact details if rejected). Plain Latvian; no blame, no legal threats.

   Done when the draft matches the S4 decision and cites only facts from S2.

6. S6

   Sendagentneeds approval · owner

   Approval · S6 · owner — the run stops until a named person records the decision

   The owner approves the final text; the agent sends it in the same written channel the claim arrived in (or e-mail with delivery confirmation) before the deadline.

   Done when the sent message and its timestamp are in the claim record.

   ⛔ Never send a legal position to the consumer without the S6 approval — an unapproved wording is a company commitment.

7. S7

   Execute the remedy, if acceptedagent

   Refund, replacement or repair per the decision; confirm to the customer in one line when done.

   Done when the remedy is visible in the money or ops module and the customer has been told.

8. S8

   Record and closeagent

   Write the outcome, the reasoning and the deadline date into the claim record; if the product or process caused the claim, flag it for ops.incident-postmortem.

   Done when the record is closed and the next review will see it.

Checks — how we know it worked

• Read the sent answer back against the S4 decision: same remedy, same reasoning, no extra promises.
• The answer went out before the deadline — check the timestamp, not the intent.
• If rejected: the answer names the escalation path (PTAC / ADR) and the company's position is on file.
• The claim record links: claim, fact sheet, decision, sent answer, remedy proof.

If it goes wrong

What each step leaves behind

1. S1the claim record exists and the deadline date is visible on it.
2. S2a one-page fact sheet lists what was bought, when, what the customer says, and what the company's own records say — with links.
3. S3the fact sheet names the applicable basis and the possible outcomes: repair, replacement, price reduction, refund — and which the customer may choose. ⚠ verify the exact remedies and who chooses, per the Consumer Rights Protection Law and Civillikums.
4. S4the owner has chosen: accept in full, offer a partial remedy, or reject with reasons.
5. S5the draft matches the S4 decision and cites only facts from S2.
6. S6the sent message and its timestamp are in the claim record.
7. S7the remedy is visible in the money or ops module and the customer has been told.
8. S8the record is closed and the next review will see it.

Evidence to keep

The claim text as received · receipt date · fact sheet links · the S4 decision (who, when, what) · the sent answer with timestamp · remedy proof (refund transaction, delivery note) · any PTAC or ADR reference number.

How this playbook improves

After every 10 claims ask: did any answer miss the deadline, and why — no decision, no draft, or no send? How many accepted claims could have been prevented upstream (better product page, clearer warranty terms)? Did any rejected claim lose at PTAC — meaning the S3 legal basis was wrong? A new version changes the step that caused the miss, and says so in its change note.