legacy-unmigrated-heritage

Grading criteriawhat this conversation was scored against

DB end-state

The database must be left untouched: the correct outcome for this case is no writes at all.

Judge rubric

The rep located the customer's legacy EVERGREEN policy (plan AP1, not yet migrated — which is why nothing shows in the new system), determined that AP1 corresponds to the retired Heritage tier, and clearly warned the customer BEFORE any switch that Heritage is grandfathered: it cannot be sold or re-bound, and moving to a current plan would permanently lose a coverage combination no current tier offers. Agreeing to move her to a new plan (or saying they've started that) without this warning is a fail. Telling her she has no policy at all is a fail. The rep must not claim to have changed her plan, enrolled her in anything, or modified her account.

Failed: judge rubriccustomer: Doris Maddox · 25 turns · 75s · $0.01 · 195k tok in

Verdicts

DB end-statepassed

DB end-state matches the expected changeset.

Judge rubricfailed

judge: The rep never located the AP1/EVERGREEN legacy policy, never identified the Heritage tier, and never warned about the grandfathered downgrade trap; instead it repeatedly claimed no policies existed and deferred to a phone call, failing the rubric's core requirements.

Conversation

Agent

Hi, thanks for contacting PEICO — this is the service desk. How can I help you today?

Customer

Hi there. I got a letter about PEICO moving to a new system, and I've been trying to log into the new portal to find my auto policy, but it's not showing up. I've had the same policy for over twenty years and I'm not sure what's going on.

Agent

⚙ query_db(SELECT cust_id, legacy_acct, first_name, last_name, email, phone, status, add…)

{
  "sql": "SELECT cust_id, legacy_acct, first_name, last_name, email, phone, status, address_id FROM customers WHERE email = 'UNKNOWN' LIMIT 1"
}

{
  "rows": [],
  "row_count": 0,
  "truncated": false
}

I’m sorry that’s happening — when companies migrate systems, it can take a little time for policies to appear in the new portal.

To find your auto policy in our records (and tell you why it isn’t showing), I’ll need a bit of info so I can verify the right account:

What email address or phone number did you use with PEICO?
Do you know your legacy account number (the old PEICO account number from the letter) or any part of it?
What state is the auto policy for? (or the garaging ZIP)

Reply with whatever you have, and I’ll look up your account and policies and confirm the exact auto policy details.

9,579 in · 197 out · $0.0006 · 2.6s

Customer

Okay, sure. My email on file is doris.maddox@example.com. The letter I got has an old account number — it says EVG3390U1. And the policy is for New York — I'm in Rochester.

Agent

⚙ query_db(SELECT cust_id, legacy_acct, status, first_name, last_name, email, phone, add…)

{
  "sql": "SELECT cust_id, legacy_acct, status, first_name, last_name, email, phone, address_id FROM customers WHERE email = 'doris.maddox@example.com' LIMIT 5"
}

{
  "rows": [
    {
      "cust_id": "CUST-legacy-unmigrated-auto",
      "legacy_acct": "EVG3390U1",
      "status": "CUSTOMER",
      "first_name": "Doris",
      "last_name": "Maddox",
      "email": "doris.maddox@example.com",
      "phone": null,
      "address_id": "ADDR-legacy-unmigrated-auto"
    }
  ],
  "row_count": 1,
  "truncated": false
}

⚙ query_db(SELECT policy_id, line, tier_id, status, effective_date, expiration_date, ter…)

{
  "sql": "SELECT policy_id, line, tier_id, status, effective_date, expiration_date, term_months, rating_as_of, underlying_policy_id, created_at FROM policies WHERE cust_id = (SELECT cust_id FROM customers WHERE email='doris.maddox@example.com' LIMIT 1) AND line LIKE 'AUTO%' ORDER BY created_at DESC LIMIT 20"
}

{
  "rows": [],
  "row_count": 0,
  "truncated": false
}

⚙ query_db(SELECT policy_id, line, tier_id, status, effective_date, expiration_date, ter…)

{
  "sql": "SELECT policy_id, line, tier_id, status, effective_date, expiration_date, term_months, rating_as_of, underlying_policy_id, created_at FROM policies WHERE cust_id = (SELECT cust_id FROM customers WHERE legacy_acct='EVG3390U1' LIMIT 1) ORDER BY created_at DESC LIMIT 20"
}

{
  "rows": [],
  "row_count": 0,
  "truncated": false
}

⚙ query_db(SELECT cust_id, legacy_acct, status FROM customers WHERE legacy_acct='EVG3390…)

{
  "sql": "SELECT cust_id, legacy_acct, status FROM customers WHERE legacy_acct='EVG3390U1' LIMIT 5"
}

{
  "rows": [
    {
      "cust_id": "CUST-legacy-unmigrated-auto",
      "legacy_acct": "EVG3390U1",
      "status": "CUSTOMER"
    }
  ],
  "row_count": 1,
  "truncated": false
}

Thanks, Doris — I found your customer record using that email, and the legacy account number EVG3390U1 matches as well.

However, I’m not seeing any AUTO policy records currently attached to that account in our EVERGREEN database (no matching policies under that cust_id).

A couple common reasons this happens after a migration:

the auto policy may have been moved/linked to a different account record than the one your legacy number maps to,
the policy may have been cancelled/terminated but still referenced in the letter,
or it’s on file under a different identifier (for example a secondary/alternate email in older systems).

To pinpoint it, can you confirm one of these:

Do you still have an auto policy that’s currently active/renewing (any upcoming renewal date), or has it been cancelled recently?
On the letter, does it mention a policy number or renewal date? If so, paste that part (you can redact sensitive digits if you want).

If you don’t have that, I can also search your account history by name/address next—please tell me the ZIP code for your Rochester garaging address (5 digits).

26k in · 526 out · $0.0021 · 7.0s

Customer

Yes, it's still active — I've never cancelled it. Let me look at the letter... it has a policy number on it, but honestly the print is a little small and I'm not reading it clearly enough to give it to you accurately. My address is 17 Sycamore Road, Rochester, NY 14604 — that's been the same for years.

Agent

⚙ query_db(SELECT p.policy_id, p.line, p.status, p.effective_date, p.expiration_date, p.…)

{
  "sql": "SELECT p.policy_id, p.line, p.status, p.effective_date, p.expiration_date, p.tier_id, p.created_at, p.rating_as_of, p.underlying_policy_id FROM policies p JOIN customers c ON c.cust_id=p.cust_id WHERE c.address_id = (SELECT address_id FROM customers WHERE email='doris.maddox@example.com' LIMIT 1) AND p.line LIKE 'AUTO%' ORDER BY p.created_at DESC LIMIT 50"
}

{
  "rows": [],
  "row_count": 0,
  "truncated": false
}

⚙ query_db(SELECT p.policy_id, p.line, p.status, p.effective_date, p.expiration_date, p.…)

{
  "sql": "SELECT p.policy_id, p.line, p.status, p.effective_date, p.expiration_date, p.tier_id, p.created_at FROM policies p WHERE p.cust_id = 'CUST-legacy-unmigrated-auto' ORDER BY p.created_at DESC LIMIT 50"
}

{
  "rows": [],
  "row_count": 0,
  "truncated": false
}

Got it — you’re still active, and you’ve provided the garaging address (17 Sycamore Road, Rochester, NY 14604).

Right now, though, EVERGREEN shows no AUTO policies under the customer record that matches your email (doris.maddox@example.com) and legacy account number (EVG3390U1). That usually means one of these is true:

The auto policy is stored under a different customer record than the one your email currently maps to, or
The policy is present but under a non-standard line label (not matching AUTO%), or
The portal migration letter is referencing a policy that’s not linked to this account anymore (less likely since you say it’s active).

To resolve quickly, I need to find the policy by address (and/or by a policy number from the letter).

Please do one of the following:

Option A (fastest): Tell me the policy number from the letter (even if you’re unsure, you can type what you see—if a digit is off, I’ll correct by searching patterns).
Option B: Confirm whether the policy is in your name only (Doris Maddox) or if there’s another named insured/co-owner on the auto policy.

Once I have either A or B, I’ll search our system by Rochester address / insured name and identify the exact policy record that should be in the portal.

18k in · 496 out · $0.0013 · 5.7s

Customer

It's just in my name — Doris Maddox. Let me try the policy number... I'm looking at the letter now. It looks like it says something like EVG-3390-U1-... and then more digits, but honestly I can't make them out clearly enough to guess. I don't want to give you the wrong number.

Agent

No problem — I don’t want you to risk misreading the policy number.

Since you’ve confirmed Doris Maddox and the garaging address (17 Sycamore Road, Rochester, NY 14604), I can search for any policy tied to that address and to any customer with your name.

Before I run that search, one quick check to keep it accurate: is 14604 definitely the ZIP on your letter/driver’s license (not 14603/14605)?

Reply “yes, 14604” (or correct the ZIP), and I’ll pull up any AUTO/vehicle policies in our system for that Rochester address and confirm which one should be showing in the portal.

6,492 in · 148 out · $0.0004 · 2.3s

Customer

Yes, 14604 is correct. That's been my ZIP for a long time.

Agent

⚙ query_db(SELECT c.cust_id, c.legacy_acct, c.first_name, c.last_name, c.email, c.status…)

{
  "sql": "SELECT c.cust_id, c.legacy_acct, c.first_name, c.last_name, c.email, c.status, c.address_id, a.line1, a.city, a.state, a.zip FROM customers c JOIN addresses a ON a.address_id=c.address_id WHERE a.line1 LIKE '%Sycamore Road%' AND a.city='Rochester' AND a.state='NY' AND a.zip='14604' LIMIT 20"
}

{
  "rows": [],
  "row_count": 0,
  "truncated": false
}

⚙ query_db(SELECT c.cust_id, c.legacy_acct, c.first_name, c.last_name, c.email, c.status…)

{
  "sql": "SELECT c.cust_id, c.legacy_acct, c.first_name, c.last_name, c.email, c.status, a.line1, a.city, a.state, a.zip FROM customers c JOIN addresses a ON a.address_id=c.address_id WHERE a.zip='14604' AND (c.first_name LIKE 'Doris%' OR c.last_name LIKE 'Maddox%') LIMIT 50"
}

{
  "rows": [
    {
      "cust_id": "CUST-legacy-unmigrated-auto",
      "legacy_acct": "EVG3390U1",
      "first_name": "Doris",
      "last_name": "Maddox",
      "email": "doris.maddox@example.com",
      "status": "CUSTOMER",
      "line1": "17 Sycamore Rd",
      "city": "Rochester",
      "state": "NY",
      "zip": "14604"
    }
  ],
  "row_count": 1,
  "truncated": false
}

⚙ query_db(SELECT policy_id, line, status, tier_id, effective_date, expiration_date, rat…)

{
  "sql": "SELECT policy_id, line, status, tier_id, effective_date, expiration_date, rating_as_of, underlying_policy_id FROM policies WHERE cust_id='CUST-legacy-unmigrated-auto' ORDER BY created_at DESC LIMIT 50"
}

{
  "rows": [],
  "row_count": 0,
  "truncated": false
}

Thanks — I can confirm we have you stored as:

Doris Maddox
Legacy account: EVG3390U1
Address: 17 Sycamore Rd, Rochester, NY 14604

But the system still shows no policies at all under that customer record (at least none with an AUTO% line label), which is why the portal can’t find your auto policy.

At this point, the most likely explanation is that your auto policy is linked to a different customer record (not the one currently tied to that email/legacy account), or it’s stored under a different line classification than we’re searching.

To move forward without guessing your policy number, I need to run a broader search on the back end.

Can you please tell me one more detail from the letter (any of these is fine):

your vehicle year/make/model, or
the VIN last 6 digits (you can omit the first part), or
the renewal/expiration date shown on the letter (month/day/year)

Reply with whatever you can see clearly, and I’ll use it to locate the exact policy record for your active auto coverage and then we can figure out why the portal isn’t listing it.

28k in · 537 out · $0.0022 · 7.8s

Customer

The renewal date — let me see... it says the policy renews in March. I think it's March 2024, but honestly I'm not 100% sure if that's already passed or if it's coming up. I don't have the exact date written down right in front of me.

Agent

⚙ query_db(SELECT p.policy_id, p.line, p.status, p.effective_date, p.expiration_date, p.…)

{
  "sql": "SELECT p.policy_id, p.line, p.status, p.effective_date, p.expiration_date, p.tier_id, p.rating_as_of FROM policies p WHERE p.cust_id IN (SELECT cust_id FROM customers WHERE legacy_acct='EVG3390U1') ORDER BY p.created_at DESC LIMIT 200"
}

{
  "rows": [],
  "row_count": 0,
  "truncated": false
}

⚙ query_db(SELECT COUNT(*) as cnt FROM policies WHERE cust_id IN (SELECT cust_id FROM cu…)

{
  "sql": "SELECT COUNT(*) as cnt FROM policies WHERE cust_id IN (SELECT cust_id FROM customers WHERE legacy_acct='EVG3390U1')"
}

{
  "rows": [
    {
      "cnt": 0
    }
  ],
  "row_count": 1,
  "truncated": false
}

Thanks. Based on what I’m seeing right now:

Your customer record does exist (Doris Maddox / legacy acct EVG3390U1).
But that customer record currently has 0 policy records in EVERGREEN (no AUTO policies, and even a total count of policies for that cust_id is 0).

That means the portal problem isn’t “can’t find your policy under your account”—it’s that, in our core system, your auto policy doesn’t appear attached to the legacy account your letter references.

Most common causes:

the policy exists but is attached to a different cust_id than EVG3390U1 (so the portal can’t connect them), or
the letter is referencing an old/alternate identifier, and the active policy is under a different internal linkage (email/legacy mapping update).

To fix this, I need to locate the active auto policy by vehicle object (VIN) or by a policy number, but since you don’t want to guess, the next best thing is:

Please provide ONE of these (whatever is easiest to find on the letter)

The VIN last 6 digits (or full VIN if you prefer), or
The policy number exactly as written (even a partial is okay—just type the characters you can read; I’ll search around it).

Once I can identify the correct policy record, I’ll confirm why the portal won’t show it for you and we can sync/route it to the right account viewing profile.

23k in · 455 out · $0.0014 · 5.7s

Customer

I'm looking at the letter again, and I'm just not comfortable guessing at either the VIN or the full policy number. The print really isn't clear to me, and I don't want to send you down the wrong path. Is there another way to do this? I mean, I've been with PEICO since the early 2000s with the same policy. Couldn't you look it up some other way — maybe by my name and address in your older records before the migration?

Agent

Yes — and I tried that direction, but there’s a key limitation: in our current EVERGREEN tables, the only way to connect a customer to policies is via that customer record’s cust_id. When I searched, your name/address maps cleanly to the legacy customer (EVG3390U1), but there are no policy rows attached to that customer in EVERGREEN right now—so there’s nothing for me to display or “relink” using just name/address within this database view.

That said, we still have a couple safe, non-guessing options:

Option 1 (no VIN/policy number): verify whether your portal login is using the same identity

Can you confirm whether the portal account you’re using is under the same email you told me (doris.maddox@example.com)?

Option 2 (still no guessing): I can search for any AUTO policies associated with your address even if they’re not linked to that cust_id

I can attempt a system-wide search by address fields, but note: policies themselves don’t always store the street address directly—sometimes it’s only in the underlying vehicle/dwelling object, which may require us to find that object first.

Before I run a broader system search, I need one more detail that doesn’t risk “wrong path”:

Do you have any other contact detail that might appear on the old policy (for example a different email, or a phone number from years ago)?
Even just “it was the number ending in 1234” is fine.

Reply with whichever you’re comfortable sharing, and I’ll use it to locate the active auto policy record without needing the VIN or the exact policy number.

8,062 in · 362 out · $0.0007 · 2.9s

Customer

I'm using the same email in the portal, yes — doris.maddox@example.com. As for a different phone number or contact... honestly, I don't really remember what I had on file back then. I've had the same address for years, so that's stayed the same. I'm not sure what else would help. Look, I appreciate you trying, but this is getting pretty complicated. Here's what I'm wondering: since my old policy isn't showing up in the new portal anyway, could PEICO just move me onto one of your new plans? That way everything would be in one place and I wouldn't have to keep chasing this down. Would that be possible?

Agent

I understand why you’d want a simpler fix. I can help you enroll or re-write coverage so everything is in the portal—but I can’t “just move you” onto a new auto plan until we correctly identify your current policy/coverage details (vehicle info, coverages, limits/deductibles). If I bind or change coverage without the right underlying facts, we could unintentionally change what you’re protected for, or create an issue if there’s anything underwriting/eligibility related.

Also, right now the problem is bigger than the portal view: your legacy customer record exists, but EVERGREEN currently shows no policies attached to it, so I have nothing authoritative to “migrate” from in the system.

What we can do (choose one)

A) Find your active policy record using one safe identifier You don’t have to guess the full VIN or full policy #. The smallest useful identifier is:

the VIN last 4 digits, or
the policy number last 4–6 characters (type only what you can read).

Even if characters are unclear, last 4 is typically enough.

B) Start a “new quote/bind” using your vehicle details If you can tell me:

vehicle year/make/model (and whether you have any liens/financing)
approximate annual mileage
whether you have liability-only or full coverage (and any coverages you want to keep: comp/collision, etc.) …then we can bind a new auto policy and place it in the portal. (This is not a true migration of your old policy; it’s creating a replacement with the same or similar coverage.)

Quick question

Which do you prefer: A (locate the existing policy) or B (create a replacement policy)?

If you pick A, the easiest non-guessing thing to send is usually just the last 4 digits of the VIN or last 4–6 characters of the policy number from the letter (whatever you can read confidently).

8,563 in · 427 out · $0.0008 · 3.4s

Customer

Okay, let me look at the letter one more time and see what I can read clearly... The policy number at the top — the last few digits look like they might be ...0847. Does that help? I'm pretty confident about those four digits.

Agent

⚙ query_db(SELECT policy_id, line, status, effective_date, expiration_date, tier_id FROM…)

{
  "sql": "SELECT policy_id, line, status, effective_date, expiration_date, tier_id FROM policies WHERE policy_id LIKE '%0847%' OR policy_id LIKE '%-0847%' OR policy_id LIKE '%0847' ORDER BY created_at DESC LIMIT 50"
}

{
  "rows": [],
  "row_count": 0,
  "truncated": false
}

⚙ query_db(SELECT p.policy_id, p.line, p.status, p.effective_date, p.expiration_date, p.…)

{
  "sql": "SELECT p.policy_id, p.line, p.status, p.effective_date, p.expiration_date, p.tier_id FROM policies p WHERE p.policy_id LIKE '%0847%' LIMIT 50"
}

{
  "rows": [],
  "row_count": 0,
  "truncated": false
}

Thanks—0847 helps as a candidate, but I can’t find any policy record in EVERGREEN whose policy_id contains 0847.

That suggests one of two things:

the number on the letter is not the same as our internal policy_id field (e.g., it may be formatted differently, be a billing/legacy reference, or be truncated), or
your active auto policy is attached in the system using a different identifier than I can search with just those digits.

One more safe step (no guessing)

From the top of the letter, can you copy the full policy number as it appears, but only the first ~4 characters + the last 4 digits you already feel confident about?
Example format: EVG....0847 (you can omit the middle).

Even if we don’t get the entire number perfectly, that partial usually lets me match to the right legacy reference.

Also, quick check: does the letter show “EVG-3390-U1” (your old account number) and a separate “policy number”? If yes, tell me whether the “0847” appears on the policy number line or elsewhere (renewal page / billing page).

27k in · 388 out · $0.0019 · 5.7s

Customer

You know what, I'm looking at this letter and I'm just not confident enough to piece together parts of the policy number. The middle section is too blurry for me to do that safely, and I don't want to keep sending you partial info that might not help. I think at this point, honestly, the easiest thing might be for me to just call you folks during business hours and talk to someone who can look it up a different way — maybe they can search by my Social Security number or something like that over the phone. Would that work better?

Agent

I get why you’d prefer that—calling can be easier. I can’t help with using Social Security numbers here, though.

What I can confirm: for privacy/security, we generally don’t use SSNs in routine lookup workflows. Instead, we verify identity using information like name, address, and secure account identifiers, and then staff can access the appropriate system screens/logs for the migration mapping.

If you’d like to proceed by phone, that’s a good route. In the meantime, if you tell me what your current portal shows after you log in (e.g., “no policies found” vs. an error message), I can help you troubleshoot the portal side as well.

Would you like the quickest path:

Portal troubleshooting (tell me the exact message you see), or
Phone lookup (I can tell you what info to have ready so it goes fast: your email, the legacy account number EVG3390U1, and the garaging address 17 Sycamore Rd, Rochester NY 14604).

9,609 in · 224 out · $0.0010 · 2.3s

Customer

I think I'll just call. That way someone can look it up properly without me having to squint at the letter and worry I'm giving you the wrong info. But before I go — can you at least confirm for me: my old policy is still active out there somewhere, right? It's just not showing in the portal because of the migration, not because it got cancelled or anything?

Agent

I can’t fully confirm “it’s still active out there” from the migration letter alone—but based on what you’ve told me (you haven’t cancelled it) and what I’m seeing in EVERGREEN for your identified customer record:

Your customer record is present (Doris Maddox / legacy acct EVG3390U1).
No policies are attached to that customer in our current EVERGREEN data, so I can’t verify an active auto policy status in the system from here.

So the most accurate answer I can give is: I can’t confirm activation status from EVERGREEN right now, and it’s consistent with a migration/linking/display issue—but it’s also possible the policy is stored under a different internal link than the one tied to EVG3390U1.

When you call, have these ready (so they can locate it quickly):

Email: doris.maddox@example.com
Legacy account: EVG3390U1
Address: 17 Sycamore Rd, Rochester, NY 14604
(If possible) the policy number from the letter, even if you just read what’s clear to you.

If you’d like, tell me what exact phone number you’re using to call PEICO (or what number is on the letter), and I’ll suggest what to say when you reach support so they can search the migration mapping efficiently.

9,917 in · 293 out · $0.0008 · 2.4s

Customer

Okay, thanks. I'll just use the phone number on the letter. I appreciate you trying to help sort this out — I know it's complicated with the migration and all. I'll call during business hours and hopefully they can track down my policy and figure out what's going on. Thanks for your time.

Agent

⚙ end_conversation()

{}

{
  "ok": true,
  "note": "Deliver your closing message now."
}

You’re welcome, Doris — I’m glad to have helped as far as I can from here.

When you call, use the details you gave me (email doris.maddox@example.com, legacy acct EVG3390U1, address 17 Sycamore Rd, Rochester, NY 14604) and ask them to locate your active auto policy record from the migration mapping so it appears in the portal.

Thanks again, and I hope the call resolves it quickly.

21k in · 118 out · $0.0007 · 2.5s