Writing

Posts worth keeping, pulled from @jeremyfdudet.

Full posts in your inbox. No click-through, no summary.

Jeremy Dudet@jeremyfdudet
Diagnosing customer churn, part 2 In my last post I shared that I want to make onboarding more rewarding. I concluded the main source of churn is that onboarding feels like a slog: lots of upfront work with almost no reward. Most users don’t see their first useful data (COGS) until 2–3 weeks in. That’s normal for this type of app. Competitors usually solve it by selling a paid done-for-you onboarding service on top of the subscription. I’m trying to avoid that. The only way is to make the app sticky during onboarding by making every session feel rewarding from day one. What does “rewarding” mean here? The user leaves every session believing their inventory is more under control, and that belief is true. Every data-entry effort has to be compensated in one of two ways: 1) A payoff. An insight they didn’t have (“your bacon is up 11% since March”) or something immediately useful (a shopping list). 2) Progress. An honest signal that they’re getting closer to a payoff, like a quest-tracking system in a game. How I'm implementing it: If we owe the user compensation for every effort, then for every payoff we have to know exactly what it depends on: what data it needs, what’s already filled, and what’s still missing. That structure is a dependency tree (example screenshot below). The top node of each tree is a payoff; every node below it is a required dependency. Tracking those trees is the entire mechanism. When the user commits their first count or processes their first receipt, the dependency-tree engine wakes up and asks: “What just became computable for the first time?” It keeps a table of every payoff it knows how to deliver and the data each one depends on. There are about seventeen trees: food cost, price watch, plate costs, shopping list, etc. One tree per thing an operator would actually ask for. The trees aren’t separate data. They’re views over one shared substrate, so the same node appears in multiple trees. The catalog sits under all seventeen. Prices feed about twelve. Counts feed eight. Sales feeds only two. Example: the operator enters one sentence—“thirty-two pounds of brisket in the walk-in.” That single count advances every tree that touches counts at the same moment. Food cost gets closer. The ranked count list reorders. The shopping list rechecks brisket against its par. How this improves onboarding? We can use the dependency trees to calculate the shortest path to the outcomes that matter most. We know what’s missing and which nodes influence the most important trees, so the AI agent can ask the smartest next questions. The app can also give honest progress indicators so the user leaves feeling like they actually accomplished something.
Read more
Jeremy Dudet@jeremyfdudet
Hi, I'm Jeremy and I'm giving this SaaS entrepreneurship-thing a fair shot. Here's my first project: t.co/Jytr9IhkCL There are lots and lots of Foodservice Inventory Management Systems out there. But, what StockCount does different is it prioritizes operational speed and ease-of-use. In other words, I'm trying to make the onboarding, the integration, and the continuous usage of a digital Inventory Management System into your foodservice operations as dead simple AND as fast as possible. The problem thesis I've developed for this niche boils down to: 1) As of today, doing physical counts is definitely unavoidable. 2) For operators, implementing an inventory systems is a challenge, but training the staff, and continuously and successfully using the software is 10x more challenging. 3) A lot of restaurant software conversations eventually become operational workflow conversations (instead of feature conversations). Tiny friction points become huge once you scale headcount or locations. UX is a wall. 4) And also, some of the current enterprise tools look great, but SMBs can't justify the $330-$480 (full features) if their 51-seat bar/restaurant is averaging $50k in sales a month (around ~5k profit / month). So, as a response to this thesis the solution I've developed: 1) Full AI-native and multi-modal data entry. **sigh....** yes I know.. AI, BUT hear me out. These are AI features intended for SPEEED. It's all about the speed. Again, with traditional inventory software, most of the operator's time isn't spent doing the counting of the inventory. It's spent operating the piece of software required input the data. It's spent in the annoying nitty-gritty data-entry busy work. The AI collapses that. The AI's whole job is to take what you'd naturally say or do and translate it into the exact sequence of clicks and operations the inventory system needs in order to correctly input your data. The simplest way I can describe it: the AI is like a trained employee who already knows how to use the inventory software, and you just talk to them. You don't learn the system. You don't navigate the screens. You tell the AI what you need, and he goes and does the clicking. That's really what it is under the hood. 2) Data analysis and Task Prioritization The AI is aware of the state of your data. It knows when any data is stale and when there are holes that makes your numbers untrustworthy. It'll recommends and prioritizes actions for your staff to take. It helps direct effort in order to faster uncover useful data. That's basically it. The hope is to make this into a digital inventory system a SMB restaurant actually keeps using. And for that to happen, it has to be faster than the clipboard and simpler than the spreadsheet. Anyway. That's the first project. It's live at t.co/Jytr9IhkCL PS: Thanks for reading this! If any of you want to try it out for free, send me a DM. I'd be happy for give you credits, in exchange for feedback :D
Read more