Turn vet charges into ready-to-send pet insurance claims
Personal assistant that watches for vet expenses and does the insurance-claim legwork: detect the bank charge, find the matching invoice in Gmail, fill the insurer's PDF claim form, stage a ready-to-send Gmail draft, then track the insurer's replies (acknowledgement → info requests/suspensions → settlement) until the money lands. Task: Personal assistant that watches for vet expenses and does the insurance-claim legwork: detect the bank charge, find the matching invoice in Gmail, fill the insurer's PDF claim form, stage a ready-to-send Gmail draft, then track the insurer's replies (acknowledgement → info requests/suspensions → settlement) until the money lands. Also captures tasks/reminders from email onto a local dashboard. Built for one household (two dogs, two insurers). Three promises it never breaks: Never sends email. Gmail drafts only — Justin reviews and hits send himself. Never stores bank logins. Transactions arrive via manual NetBank CSV upload — the dashboard, or a document sent to the Telegram bot (/upload-tx to import a just-sent file; a caption-less document is also picked up directly when the gateway's dispatch hooks fire). Never guesses required claim fields. Anything it can't derive from a document (the claimed condition, an ambiguous pet) is flagged and asked — on Telegram and the dashboard — not inferred. The goal Vet visits generate a paper chase: a card charge, an emailed invoice (sometimes weeks later, sometimes forwarded by a spouse, sometimes a photo scan), a 4-row insurer claim form, and a reply thread that decides whether money comes back. OpenClaw's job is to make Justin's part of that chase three taps: pick a condition, review a draft, hit send. Everything mechanical — finding, matching, extracting, filling, tracking — is automated, and everything the software isn't sure about is surfaced as an explicit question rather than a silent guess. The process, end to end The whole pipeline runs on a 15-minute tick inside one FastAPI process (ADR-0006). The tick is driven by the gateway's cron since 2026-08-04 (POST /internal/tick); APScheduler is still in the code behind SCHEDULER_ENABLED for one week's rollback, and off in the deployed config. A failure on one claim flags that claim and moves on — a tick is never lost to one bad email (visible failures are a hard rule). Settlement checking asks two separate questions, because they have different answers and different audiences. An approval letter states its own full breakdown — amount claimed, fixed excess, non-claimable amount, age contribution (a rate and a dollar figure), percentage excess, amount paid — so Check A re-adds those figures and confirms they reach the amount Petcover says they paid. That is arithmetic on numbers they printed, not a model of their policy: nothing is inferred, and a letter stating no rate is skipped rather than assumed. Check B compares the amount they say they assessed against the claimable subtotal we actually submitted, and asks about a difference rather than asserting one — every stated amount matches some real invoice of ours, the amounts cross Condition Thread boundaries, and the letters carry no invoice number, so re-routing a settlement is Justin's call after Petcover answers. Across all ten live approval letters (2026-08-04) Check A passes to the cent and Check B has questions about five of them. The claim amount used is always the recorded claimable subtotal, never the invoice total and never the bank charge: one accessor reads it, a guard test fails if any caller re-adds the old fallback, and where it was never recorded the surfaces say Not recorded instead of a plausible substitute.; tools: OpenClaw. Human role: The original post does not say how a person stayed involved.; limitations: Prerequisites include Gmail OAuth, Telegram bot token, and manual NetBank CSV uploads. Constraints: No bank login storage, no auto-sending, and no guessing of claim fields. Integration uncertainty: The OpenClaw gateway swap is in flight; Telegram polling and scheduling are transitioning. Human approvals are mandatory for all outbound communications. Source reliability: Secondary source; specific failure rates beyond the ten letters are unknown..
Tools
Published on Agent Work Atlas:
Overview
Personal assistant that watches for vet expenses and does the insurance-claim legwork: detect the bank charge, find the matching invoice in Gmail, fill the insurer's PDF claim form, stage a ready-to-send Gmail draft, then track the insurer's replies (acknowledgement → info requests/suspensions → settlement) until the money lands.
Workflow
Personal assistant that watches for vet expenses and does the insurance-claim legwork: detect the bank charge, find the matching invoice in Gmail, fill the insurer's PDF claim form, stage a ready-to-send Gmail draft, then track the insurer's replies (acknowledgement → info requests/suspensions → settlement) until the money lands. Also captures tasks/reminders from email onto a local dashboard. Built for one household (two dogs, two insurers). Three promises it never breaks: Never sends email. Gmail drafts only — Justin reviews and hits send himself. Never stores bank logins. Transactions arrive via manual NetBank CSV upload — the dashboard, or a document sent to the Telegram bot (/upload-tx to import a just-sent file; a caption-less document is also picked up directly when the gateway's dispatch hooks fire). Never guesses required claim fields. Anything it can't derive from a document (the claimed condition, an ambiguous pet) is flagged and asked — on Telegram and the dashboard — not inferred. The goal Vet visits generate a paper chase: a card charge, an emailed invoice (sometimes weeks later, sometimes forwarded by a spouse, sometimes a photo scan), a 4-row insurer claim form, and a reply thread that decides whether money comes back. OpenClaw's job is to make Justin's part of that chase three taps: pick a condition, review a draft, hit send. Everything mechanical — finding, matching, extracting, filling, tracking — is automated, and everything the software isn't sure about is surfaced as an explicit question rather than a silent guess. The process, end to end The whole pipeline runs on a 15-minute tick inside one FastAPI process (ADR-0006). The tick is driven by the gateway's cron since 2026-08-04 (POST /internal/tick); APScheduler is still in the code behind SCHEDULER_ENABLED for one week's rollback, and off in the deployed config. A failure on one claim flags that claim and moves on — a tick is never lost to one bad email (visible failures are a hard rule). Settlement checking asks two separate questions, because they have different answers and different audiences. An approval letter states its own full breakdown — amount claimed, fixed excess, non-claimable amount, age contribution (a rate and a dollar figure), percentage excess, amount paid — so Check A re-adds those figures and confirms they reach the amount Petcover says they paid. That is arithmetic on numbers they printed, not a model of their policy: nothing is inferred, and a letter stating no rate is skipped rather than assumed. Check B compares the amount they say they assessed against the claimable subtotal we actually submitted, and asks about a difference rather than asserting one — every stated amount matches some real invoice of ours, the amounts cross Condition Thread boundaries, and the letters carry no invoice number, so re-routing a settlement is Justin's call after Petcover answers. Across all ten live approval letters (2026-08-04) Check A passes to the cent and Check B has questions about five of them. The claim amount used is always the recorded claimable subtotal, never the invoice total and never the bank charge: one accessor reads it, a guard test fails if any caller re-adds the old fallback, and where it was never recorded the surfaces say Not recorded instead of a plausible substitute.
Reported result
Actual outcomes are not fully measured in the source. For ten live approval letters (2026-08-04), arithmetic Check A passed to the cent, while Check B raised questions on five claims regarding assessed vs. submitted amounts. No broader success metrics or financial impact are reported. Proposed acceptance check: Verify that 100% of staged drafts require manual human send and that zero emails are auto-sent.
Human role
The original post does not say how a person stayed involved.
Limitations
Prerequisites include Gmail OAuth, Telegram bot token, and manual NetBank CSV uploads. Constraints: No bank login storage, no auto-sending, and no guessing of claim fields. Integration uncertainty: The OpenClaw gateway swap is in flight; Telegram polling and scheduling are transitioning. Human approvals are mandatory for all outbound communications. Source reliability: Secondary source; specific failure rates beyond the ten letters are unknown.
Try it
Act as a personal assistant for pet insurance claims. I will provide [replaceable inputs: NetBank CSV file, Gmail access, Petcover PDF template, Telegram bot token]. Steps: 1. Parse the CSV to detect vet charges. 2. Search Gmail for matching invoices using merchant name and date ±3 days. 3. Extract invoice details (amount, date, pet) using LLM/vision OCR. 4. Fill the Petcover PDF claim form with the claimable subtotal (excluding routine care). 5. Create a Gmail draft with the PDF and invoice attached. 6. Track insurer replies for settlement status. Constraints: Never send emails automatically. Never store bank logins. Flag any ambiguous data (e.g., unclear pet, missing condition) for my review via Telegram/dashboard instead of guessing. Deliverables: A ready-to-send Gmail draft and a status report. Quality Check: Ensure the claim amount matches the invoice subtotal, not the bank charge. Error Handling: If no invoice is found, draft an invoice request email to the vet (do not send). If the invoice is a scan, use vision OCR. Safeguards: Perform a dry run on one sample claim first. Show me the extracted data and the draft before I confirm sending. Ask clarifying questions only if critical inputs like the PDF template or CSV format are missing.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.