Here's what the episode covers:

• The bike as the primary record: Auto repair software centers the vehicle, not the owner — bike shops need the same logic. One customer, three bikes, three completely different specs; if the record is built around the person, every visit starts from scratch.
• What bike-level fields actually matter: Serial number, frame size, brake standard, derailleur hanger part number, bottom bracket spec, tubeless setup — and for e-bikes, motor system, battery serial, firmware version, and key number. If a vendor demo can't show you these on a bike-level record, you're looking at a sales CRM in a service costume.
• Repair history vs. invoice history: A list of past invoices tells you what a customer paid for. A real service record carries declined work, actual parts used by SKU, labor time per job, and searchable mechanic notes — the kind of detail that saves an hour on the next visit. Bike shop work orders built around this structure make the difference visible immediately.
• Why texting has to live inside the ticket: SMS open rates sit around 98%; automated reminders reduce no-shows by 30–60%. But none of that holds if the thread lives in a separate app. The right pattern puts the text conversation inside the customer-and-bike record, firing status updates from the ticket and routing replies back to the same thread — alongside an AI receptionist for bike shops that can handle initial inbound contact without pulling a mechanic off the stand.
• The retention math: The probability of selling to an existing customer is 60–70%; for a new prospect, 5–20%. A five percent lift in retention can raise profits by 25–95%. Clean bike-level records are the engine behind that number — enabling timely outreach based on last service date, flagged wear, and seasonal patterns.
• Questions to ask in a vendor demo: Pull up a demo customer with three visits. If you see three invoices and three dates, the product knows what a sale is — not what a repair is. Ask about texting numbers, photo support, and whether a customer reply creates a task or vanishes.

More from the show: if you're weighing what bike shop software actually costs across all its line items, the episode What a Bike Shop Actually Pays for Software, Line by Line pairs well with this one. For a deeper look at how BIKE.co approaches pricing, see BIKE.co pricing.

BIKE.co

Here's what the episode covers:

• Subscription sticker price vs. real price: Bike-specific platforms cluster at the higher end of the $50–$200/month range, and the tier you actually need — the one with the QuickBooks sync or multi-user access — is almost always one step above the plan you quoted.
• Per-register and per-location fees: Each additional till is typically billed separately, turning a clean headline number into something considerably larger for a multi-station shop.
• Payment processing as the dominant line item: At an average effective swipe rate around 2.4%, card processing routinely accounts for more than half of a shop's total software spend once real card volume runs through — and bundled processor lock-ins deserve extra scrutiny before you treat a discounted software price as a win.
• One-time costs that quotes tend to bury: Hardware per station can reach $2,000 or more, migration fees vary widely depending on whether serial-numbered bikes and service history are included, and training downtime for a five-person team represents a four-figure soft cost before the vendor invoices anything. For shops managing complex intake workflows, purpose-built tools like bike shop work orders can reduce the training surface area significantly.
• Integration sprawl: A shop running separate tools for scheduling, ecommerce, email, accounting, payroll, and text messaging can easily reach seven subscriptions — each with its own seat pricing and renewal date. New software that replaces only one or two of those tools adds cost, it doesn't consolidate it.
• A sanity-check benchmark: Small businesses typically allocate 4–6% of annual revenue to technology. For a shop at the $1.2M industry average, that's $48,000–$72,000 across every piece of software, hardware, connectivity, and payment processing combined. If a single POS quote is consuming a third of that envelope before payments, the math doesn't work.

The episode closes with a practical exercise: take the vendor quote, open last month's bank statement, and write every line of the quote as a real monthly debit. Shops evaluating their labor economics alongside software costs may also find the labor rate guide a useful companion. If you missed the previous episode, The Comeback Problem: How to Stop Fixing the Same Bike Twice is worth a listen before you commit to any new system.

BIKE.co

Here's what the episode covers:

• Mistake vs. misunderstanding: The two root causes of comebacks look identical at the front counter but demand completely different responses — confusing them is where shops go wrong.
• Why intake documentation changes the whole conversation: Recording the bike's condition at drop-off — including what was noticed and not addressed, and why — turns a tense comeback into a two-minute reference check. Bike shop work orders that capture those condition notes give everyone a shared record to point to.
• Handling genuinely ambiguous comebacks: When neither the shop nor the customer is sure what happened, winning the argument is the wrong goal. Treating the visit as a diagnostic opportunity — looking at the bike together, narrating what you find — preserves the relationship without surrendering accountability.
• The hidden cost of silent write-offs: Absorbing ambiguous comebacks without logging them makes the problem invisible. Without a record, you can't spot whether a specific repair type, service tier, or mechanic skill gap is quietly generating repeat visits.
• Building a simple comeback log: Tagging any return visit within a two-week window on the original job — noting what was found, what was done, and whether it was a warranty — creates the data that surfaces patterns over time. Consistent service checklists at intake reduce ambiguity before a job even starts.
• What the data eventually tells you: A comeback log reveals underpriced repairs that rarely hold on the first pass, training gaps in specific skill areas, and service tiers that aren't setting the right customer expectations.

If you're thinking about the broader systems that support repeat-free service work, the BIKE.co blog has a practical look at switching your bike shop away from Lightspeed — worth a read if your current software is making documentation harder than it should be. For more on pricing the service side of your shop, don't miss the earlier episode Why Your Tune-Up Menu Is Costing You Money (And How to Fix It).

BIKE.co

Here's what the episode covers:

• Task-based vs. outcome-based tiers: Defining each service level by the condition the bike leaves in — not just the motions a mechanic goes through — eliminates the comeback arguments that task lists invite.
• Pricing the gaps correctly: Tiers priced too close together collapse into one option in practice; tiers too far apart kill your mid-range. The episode walks through a worked example showing how interval spacing drives which tier becomes your volume seller.
• What to explicitly exclude: Stating what's not included in a tier removes bench-side judgment calls, turns add-ons into clean customer conversations, and eliminates invoice surprises — a small structural choice with an outsized effect on trust.
• Making your work orders do more work: When your service checklists map to outcomes rather than motions, every completed step becomes an accountability checkpoint — useful for comeback protection and for training newer mechanics.
• Naming your tiers so your team actually uses them: Forgettable tier names ("Basic / Standard / Premium") get replaced with vague, hesitant pitches at the counter. Names your staff can say with confidence shape how your whole shop talks about its services.
• The menu as a management tool: A well-designed tune-up structure sets expectations, defines what "done" means, and gives every person in the shop something consistent to stand behind — not just a pricing sheet.

Use a three-tier tune-up checklist to put these ideas into practice right away. More from the show: listen to How to Switch from Lightspeed to BIKE.co Without Losing the Winter for a related look at the operational decisions that happen behind the counter.

BIKE.co

The episode covers a six-week parallel-run migration strategy designed to fit inside the winter slow season — the one window where training doesn't eat into billable time and a dropped ticket won't cost you a peak-season customer. Here's what gets unpacked:

• Why winter is the only realistic window: Nearly 80% of service volume is compressed into seven months, making a mid-season cutover mathematically brutal — and a slow Tuesday in November genuinely manageable.
• The parallel-run principle: Rather than a hard flag-day switch, the method keeps both systems live for a defined overlap period, with a single rule — every new ticket into BIKE.co, every existing open ticket finishes in Lightspeed — to prevent the same bike from living in two systems at once.
• What moves and what stays: Workshop tickets, bike shop work orders, bench scheduling, mechanic time tracking, repair invoicing, and service checklists migrate to BIKE.co; retail POS, parts inventory, and card processing stay in Lightspeed for now.
• Week-by-week scope: Six distinct phases — scope definition, system configuration, ticket cutover, full bench migration, reconciliation, and archiving — each with a clear goal and a defined endpoint.
• Honest roadmap awareness: The episode names exactly which BIKE.co features are live today and which are still planned, so shops can build a migration that doesn't depend on functionality that doesn't exist yet. See what is live and what is planned.
• Four metrics to track post-switch: Turnaround time, billable hours per mechanic per day, missed calls, and average ticket value — concrete numbers to evaluate the move come spring, not just a gut feeling.

Whether you're running a repair-first operation or a full retail-and-service shop, the core argument here is simple: if service is where your margin is, the software running that side of the business should be purpose-built for it. Winter is the window to make that change without losing revenue, momentum, or your mechanics' sanity.

BIKE.co