I don't have a job title for what I want to do next.

I don't have deliverables for the jobs I actually want, only stories from the job I've had. So instead of waiting until I actually have one of those jobs to build them, I built some now.

This is the first time I've built something like this. I'm self-taught by nature, and I'd rather take the initiative to figure something out than wait for someone to hand me a process. I worked with Claude on the writing and the design, told it what actually happened, and pushed back every time a draft made me sound like someone I'm not.

Whatever the role, I care about doing it well. About the customer in front of me, about the people I work with. That doesn't change based on a title. Two employers in close to ten years: when I invest somewhere, I stay invested.

This customer came to us already using Shopify's newer login: customers verify with just an email or phone number and a one-time code, no password. Our platform wasn't built for that yet, and nobody caught it.

The account came to me the normal way, transferred from the implementation manager once onboarding wrapped. What I found: the main thing this customer wanted the program to do was filter actual loyalty members from everyone else, people who'd joined versus people who'd just logged in to check an order. With this login, there was no separate opt-in step, so there was no way to make that distinction. The loyalty tiers were also set up almost flat, which didn't help, but the filtering was the real problem.

Once I confirmed this was a genuine product limitation, not a configuration mistake, I escalated it as far and as fast as I could. I also went back and listened to the actual sales calls, to check what this customer had been told versus what was actually possible. They'd been promised this filtering, clearly, and it wasn't something our platform could do. Not on the day they signed, and not for a while after.

I told my manager the truth: we'd sold them something that didn't exist yet. So I gave the customer two options, and meant both of them. Start over, tiers fixed, on the beta of the fix, with the contract extended to make up for what they were promised and didn't get. Or we part ways, and I refund the contract.

They chose to start over. I rebuilt the setup myself. It's the only time in four years at Yotpo I offered someone a way out of their contract, because it was the only time the honest answer was that we might deserve to lose them.

The tier structure, for reference

This part is out of the box, standard on any Yotpo loyalty program. Each tier should earn faster than the last:

This customer had it set at 1.0 / 1.1 / 1.2 instead, flat enough that upgrading barely mattered. That was the setup I inherited and fixed.

I inherited this account from a teammate going on leave. Her transfer note said the customer claimed we'd cost them money, we hadn't, and the case was closed. That wasn't enough to actually resolve anything, so I went back to the account history instead of the note.

This customer had been with us a couple of years, running their loyalty program on a generic platform where points were originally set to never expire. At some point the platform added the option to set an expiration, and the customer turned it on. What nobody had properly explained, not to the customer and not to us on the CS side, was what that switch does to points that already exist. Every point sitting in someone's account got stamped with the date of the change, as if it had just been earned that day. So instead of expiring on a rolling basis, everyone's existing points were now set to expire on the same date, a year out.

This wasn't just a complaint. The customer was furious, threatening to leave, and had stopped paying. They billed quarterly and had built up a debt of two or three payments while this sat unresolved. They were also threatening to sue for additional damages on top of what they said we'd already cost them. It was, genuinely, a bad situation.

Their claim was that members were redeeming more points than they should have, and it was costing them thousands of dollars. Some of that was real. The number wasn't. It took our solutions engineers a lot of digging, matching individual redemptions against individual earn dates across the account, to find out what had actually happened and what it had actually cost.

Once both sides had the real number, calculated exactly instead of estimated, we reached an agreement. Their annual contract went from 12 months to 14, two extra months added to make up for what happened. They renewed and left feeling like they'd gotten something back. Yotpo ended up paying out far less than the customer had originally threatened to claim.

Nobody had actually explained what a routine-sounding setting change would do to an account that old. Not to them, not to us. It took someone going back to look.

Our QBR template was thin, especially on numbers. It listed what a loyalty program had running, sign-ups, some totals, but no real comparisons and no graphs. I'm a visual person. If I can't see something plotted against something else, I don't really get it, so I started building my own slides in Sheets, pivot tables against redemption and earning-rule data, just so I could actually understand my own accounts.

People noticed I was presenting different slides in my QBRs and started asking about them: what they were, how I was pulling the numbers, how I was analyzing it. I explained it and shared the template when they asked.

Looking back, I don't think I fully realized it at the time, but I'd found a real gap: the way we presented data to customers wasn't detailed enough to actually show them how their program was performing. A program usually has several earning rules and campaigns running at once, a referral bonus here, a birthday bonus there, a seasonal push on top of both. Rolled into one performance number, you can tell whether the program overall is doing well. You can't tell why, or which piece is actually driving it.

So I pulled it apart myself. There wasn't a seamless way to do this. I exported the raw reports, mapped individual purchases back to the specific earning rule or campaign that drove them, then compared across time frames. If there was a site-wide sale with no new campaign running, I could isolate how much of the lift was the sale and how much was the program. If a new earning rule launched outside of a sale, the same logic worked in reverse.

The part that's less tidy

Any time I handed off an account to a teammate, I put real effort into it. Direct links to the account's key stakeholders on LinkedIn, so whoever took it over could see who they were dealing with. Who I talked to most. What actually mattered on the account, beyond what was in the CRM. I did that because I know what it's like to receive the opposite: a one-line note that costs someone weeks of digging through old tickets to understand where an account stands. That's exactly what happened at the start of the last case.

I raised it with my manager, that our handoffs were inconsistent and it was costing real time. It didn't go anywhere. I think it read as a complaint about one bad handoff instead of a proposal for a fixed process.

I still think it's a real gap. A standard handoff template is a small thing to build and an easy thing to measure. I just never had the mandate to actually own it.

Salesforce, SQL and MySQL at a basic level, Spanish, English, and Hebrew, and enough pivot tables to build the dashboard above from scratch.