A business owner came into a recent thirty-minute advising session believing she had a technology problem. The details here are changed to protect her, but the shape of the conversation is one I have every week.
She provides a hands-on service in more than one environment. Some customers encounter her at community events and walk up for the service without appointments. Others meet her at events aligned with her target market and are ready to pay noticeably more. She also wants people to be able to discover her online and book in advance.
Over time, she had experimented with several scheduling, payment, and web platforms trying to create a seamless customer experience.
None had fully solved the problem.
During the session she described one particularly frustrating moment. After providing her service at an event, a customer asked how much she owed. The owner was used to a flexible "pay what you can" model and struggled to confidently state a price.
The customer was prepared to pay one amount — and the owner, unable to state her price with confidence, asked for barely half of it.
For her, the question was technological: what system should I use so customers can pay me easily?
The session revealed that this was not primarily a technology problem. And that distinction — between the problem a business presents and the problem that actually needs solving — is the whole point of understanding the business before building anything around it.
How do you know when a technology problem isn't one?
You know because the friction survives every new tool. She had already tried several platforms; the frustration kept happening anyway. When switching software doesn't change the experience, the constraint usually isn't in the software. As she described taking payments at live events, three things stood out almost at once.
The first was where it was happening. These transactions were happening in person, with walk-up customers, immediately before or after the service. That means the primary requirement was never an online scheduling system. It was a point-of-sale workflow that can handle an immediate transaction with minimal friction.
The second was what she was charging. She could not consistently state what her service cost. She was using different "pay what you can" ranges depending on the audience and adjusting amounts as customers approached. Which raises the more fundamental question: is the pricing based on the actual economics and value of delivering the service? Her description suggested it was not. The payment friction was exposing a larger issue — unclear service packaging, inconsistent pricing, thin margins, and missed revenue. That gap between what the customer was ready to pay and what was asked is not a payment-processing problem. No processor on the market can recover it.
The third was who she was serving. She was intentionally trying to do two different things: keep an accessible version of her service for the surrounding community, and serve a customer who had demonstrated both the willingness and the ability to pay substantially more. Those are good goals. They don't require improvised pricing. They require an intentionally designed offer for each.
What looked like one problem was actually several
The technology question turned out to be the last question in a chain, not the first. Underneath "which payment system should I use" sat a stack of undecided pieces:
- Offer architecture — what exactly are the services being sold?
- Pricing architecture — what does each cost to deliver, what value does it provide, and what should the established price be?
- Customer segmentation — is there an intentional community-access offer and a separate standard offer, or one price improvised per person?
- Customer journey — is this a walk-up event customer or someone scheduling a future appointment?
- Transaction workflow — how does an in-person customer select and pay for a service quickly?
- Booking workflow — how does a future customer discover, schedule, and possibly prepay?
- Technology — which tools support those decisions without adding another disconnected platform?
The technology decision belongs near the end of that sequence, not the beginning. Technology can process whatever amount you type into it. It cannot tell you what your service should cost. That is a business decision — and a payment system pointed at an undecided business just makes the indecision faster.
Why one business often needs more than one customer journey
Because her customers genuinely arrive two different ways, her business has two journeys, and forcing them into one interface was part of the friction.
The event walk-up journey: customer encounters the business, picks an available service, receives it, pays immediately through point of sale, transaction recorded.
The advance-booking journey: customer discovers the business, reviews defined services and prices, selects one, schedules, pays, shows up.
These can and should feed one coherent payment and customer-management environment on the back end — nobody should be reconstructing revenue at the end of every month. But they are different use cases, and the customer shouldn't be pushed through the same doorway in both situations. This is what it looks like to treat your business as the system it already is: the parts are connected, but they are not identical.
What to decide before you choose the technology
The recommendation was not another platform. It was to establish the service catalog and pricing structure first:
- What services are currently offered, and what is included in each?
- How long does each take, and what does delivery actually cost the business?
- What is the standard price?
- Should there be a deliberately designed community-access offer, instead of an improvised discount?
Only after those decisions exist should the booking and point-of-sale systems be configured around them. For live events, a simple mobile point-of-sale flow supports immediate transactions. For appointments, a separate booking experience lets customers choose clearly defined services and schedule before arriving.
The goal was never to find one piece of software that does everything. The goal was to design the business first and choose technology that supports each part of it. This is the business of doing business — the decisions that exist whether or not any software ever gets installed.
What changed in thirty minutes
She arrived asking which technology to use. She left having recognized that the pay-what-you-can approach was unsustainable, that she needed established prices, and that the larger business needed to be defined before configuring more technology and marketing.
A Business Operating Profile session was scheduled to establish the business model, target customers, offers, pricing, and operational requirements — before continuing with website, email, social media, booking, and promotion.
No new software was purchased that day. That was the win.
What this means for larger organizations
The dollars in this story are small. The pattern is not.
An organization can believe it needs an AI platform, a CRM, an automation system, or a new technology stack when the underlying constraint is an unclear workflow, fragmented ownership, inconsistent processes, or a business requirement nobody has actually defined. Implementing technology before surfacing those conditions doesn't solve the problem; it amplifies it — at organizational scale, with bigger invoices. That is the argument the Living Systems series makes for AI specifically, and it is one reason AI enablement, done honestly, starts with the business rather than the tool.
This is Orientation Before Automation in its most everyday form: before deciding what to automate or delegate to technology, the business has to understand what it is doing, why, who decides, and what should remain human. The problem a business presents is not automatically the problem that should be solved — and the discipline is to find out which one you're holding before you pay for software to speed it up.
Frequently Asked Questions
How can a small business tell if it has a technology problem or a business problem?
Describe the problem without naming any technology. If the plain-language version exposes an undecided question — what the service costs, who owns a process, what should happen next — the constraint is a business decision, and software can only automate the indecision.
Should pricing be decided before choosing a payment or booking system?
Yes. Payment and booking systems are configured around defined services and established prices; choosing the tool first usually means rebuilding it once the real offers and prices exist.
Can one small business have more than one customer journey?
Yes, and many do — a walk-up, pay-on-the-spot journey and an advance-booking journey are different experiences that should share back-end records but not necessarily the same interface.
If you recognized your own business somewhere in this story — improvised prices, tools that never quite fit, a nagging sense that the real decisions haven't been made yet — that is exactly what the Business Operating Profile makes visible: the business first, so every technology decision after it gets easier. Book a Business Operating Profile.