How building the perfect system can distract you from finding a real buyer, and how to decide what deserves automation at the beginning.
You can spend an entire afternoon preparing for customers without getting any closer to understanding why someone would become one.
The booking page works. The welcome email sounds professional. The form sends information to the right place. A new project folder appears automatically when you test the process.
Everything is coming together.
Then you open your inbox, and the enquiry you hoped for is still missing.
I can understand the appeal of working on those systems. There is something satisfying about connecting a few steps and watching them happen without your involvement.
You can see the result immediately.
A form is completed. A notification arrives. A task appears.
Finding customers is less predictable. You can explain your offer carefully and receive no response. Someone can sound interested and disappear. A conversation can reveal that the service you were excited to sell does not address the problem the buyer considers urgent.
That uncertainty makes business preparation feel comfortable.
There is always another setting to adjust, another template to improve, or another tool to connect.
As someone interested in writing, AI, and building a business around useful skills, I find this worth thinking about. I want systems that reduce unnecessary work. I also want to recognise when setting them up is taking attention away from a question they cannot answer for me.
Who needs what I am offering enough to pay for it?
Until that becomes clearer, a sophisticated process may be supporting a very uncertain offer.
That does not make the preparation worthless. A reliable way to receive enquiries, arrange calls, and collect the information needed for a project can be useful from the beginning.
The question is how much of the business you are trying to organise before you understand the work it will actually need to do.
Imagine a writer preparing to offer a monthly content package.
They create a detailed onboarding form. They set up automatic emails explaining the process. They build a system for generating topic ideas, moving drafts through review, and sending reminders.
The package looks ready.
Then the first serious conversation reveals something they had not considered.
The prospective client has plenty of topic ideas. What they struggle with is turning the founder’s scattered knowledge into something another person can write accurately.
A second conversation reveals a different issue. That company already has drafts, but the material needs substantial editing before it can be published.
A third prospect wants a small initial project because the team needs to see how the writer handles the subject.
The system was designed around customers arriving with a clear brief and committing immediately to ongoing work.
The conversations reveal that the starting point may be different.
The writer now has useful information about what the service needs to include, how it should be explained, and what a suitable first engagement might look like.
Some of the existing setup will still help. Other parts may need to change.
This is what concerns me about automating too early.
You can build a process around assumptions and then carry those assumptions into every interaction.
The onboarding form asks questions the client cannot answer. The welcome email describes a package they have not agreed to. The reminder sequence addresses an objection that was never the real problem.
The system may run correctly while making the experience less useful.
Before spending more time on it, I would want to understand where the uncertainty sits.
Perhaps the offer is clear, but too few suitable people have seen it.
Perhaps people understand the service but cannot see why they need it now.
Perhaps the price, scope, or amount of client involvement creates hesitation.
Perhaps the work is useful, but the people responding have no authority or budget to buy it.
Those situations need different responses.
An automated follow-up sequence might help with one part of the process. It cannot, by itself, tell you which of those situations you are dealing with.
That understanding comes from looking closely at what happens when real people encounter the offer.
GOV.UK’s user research guidance recommends learning what people are trying to achieve, how they currently handle it, and where they experience problems. Although the guidance is written for public services, I would apply the same approach when investigating a business idea: understand the existing situation before deciding how your solution should work.
For a writing service, that could mean asking a founder about the last article they tried to publish.
What happened? Who contributed? Where did the process slow down? What remained unfinished? How did they handle the problem?
Those details can reveal more than a broad question about whether they would like help with content.
Someone may agree that publishing regularly is important while having no immediate intention of paying for support.
They may enjoy discussing an idea without considering it a priority.
That is why I would be careful about treating enthusiasm as proof of demand.
A person saying “This sounds useful” has given you an encouraging response. They have not necessarily shown that they will make room for the service in their budget or working week.
Even a conversation about pricing leaves questions open.
The buyer may be exploring. They may need approval. They may decide to solve the problem another way.
A paid project gives you stronger evidence that the offer is valuable to that customer under those conditions. Delivering it gives you more information about whether the work is manageable and whether the result meets the need.
Repeat work can reveal something further.
Each stage teaches you something different.
I think this matters because automation can make early signals look more substantial than they are.
A growing list of contacts can look like a healthy sales process. A collection of completed forms can look like strong demand. Scheduled messages can make the business feel active.
Those numbers need context.
Who are the people involved? What have they actually agreed to? What happens after the initial response?
A system can organise these details, but someone still needs to interpret them.
At the beginning, that person is often you.
There is also a useful kind of learning that comes from handling early work directly.
When you read an enquiry yourself, you notice the words the buyer uses. When you discuss the brief, you hear where they hesitate. When you explain your process, you discover which parts make sense and which need clarification.
These details can shape both your service and your marketing.
Y Combinator’s early startup advice encourages founders to work closely with initial customers, including through manual processes, while they are still learning what to build. It warns that creating systems for scale too soon can consume time and effort before those systems are needed.
I find the practical lesson relevant to a small service business too.
If I have only a few serious enquiries, personally reading and answering them may be one of the most useful parts of my work.
I can notice that several prospects misunderstand the same phrase. I can discover that my package includes something buyers do not need while leaving out something they keep asking for.
That information can help me improve the offer.
If I automate those conversations too heavily, I may still receive responses, but I risk paying less attention to what they reveal.
This does not mean every interaction has to remain manual forever.
It means that learning has value, and the process should leave room for it.
A simple booking confirmation can reduce unnecessary back and forth while you still handle the substantive conversation yourself.
A reminder can help you follow up at the right time while you write a response based on the person’s actual situation.
A template can keep important information consistent while allowing you to adapt it.
There are many useful steps between doing everything from scratch and building a fully automated customer journey.
I would start with those.
It is also worth looking honestly at how much time an automation is likely to save.
Suppose a task takes ten minutes and happens twice a month.
That is twenty minutes of work each month.
If automating it takes three hours, it would take nine months to recover the setup time, assuming the automation removes all twenty minutes and requires no maintenance.
That is an illustrative calculation, but it raises a practical question.
Will this task still exist in the same form nine months from now?
For a new business, the offer, process, tools, and customer needs may change considerably during that period.
The automation might still be worthwhile if it prevents a costly mistake or makes the business more accessible. Time saved is only one consideration.
But the calculation helps expose the difference between a task that feels repetitive and one that is consuming a meaningful amount of time.
A complicated setup can be difficult to justify when the task barely occurs.
The cost is also broader than the initial build.
Someone needs to test the process, check whether it still works, update messages, and handle situations that fall outside the expected path.
An automated workflow can reduce work. It can also create a new responsibility.
I would want to account for both.
The same applies to subscriptions.
A tool may have useful features, but its usefulness to another business does not establish its usefulness to mine at this stage.
If I am paying for capacity I rarely use while still trying to find suitable buyers, I would want to review that decision.
The money matters. So does the attention spent learning and maintaining the tool.
An afternoon used to configure an elaborate client portal is an afternoon unavailable for improving a sample, speaking with a prospective buyer, or delivering a small paid project.
That does not make the portal a bad idea.
It makes timing part of the decision.
There are situations where early automation makes sense.
A booking tool may help someone manage availability around another job. Automatic delivery may be essential to providing a digital product properly. Reminders can support a person who struggles to keep track of administrative tasks.
A small automation might also make customer research easier by organising responses or keeping agreed appointments visible.
Those benefits can exist before the first sale.
I would judge the setup by the real difficulty it removes and the effort required to maintain it.
For some businesses, automation is part of the product itself.
If the offer is an automated reporting service, the founder may need a working prototype to test whether it can produce a useful report accurately and consistently.
That is a meaningful part of testing the business.
The important distinction is between building what is needed to evaluate the core promise and constructing every surrounding process before that promise has been tested.
A prototype may need to generate the report. It may not yet need a complicated referral programme, several subscription levels, and an elaborate customer dashboard.
The work should match the question you are trying to answer.
I would apply similar judgement to AI.
AI can help draft interview questions, organise notes, suggest possible objections, or examine how clearly an offer is written.
Those activities can support preparation.
But an AI generated description of an ideal customer remains a proposal about who might buy. It needs to be checked against real people and their circumstances.
A simulated buyer can point out a confusing sentence. They cannot commit a real budget, reveal what happened inside an actual company last week, or decide to renew a service after using it.
I want tools to help me make better use of customer evidence.
I would be cautious about letting simulated responses become a substitute for finding that evidence.
This is particularly relevant when the work of reaching people feels uncomfortable.
I do not think everyone needs to adopt the same approach to selling. There are ways to learn about potential customers without sending large volumes of cold messages.
You can pay attention to relevant requests in professional communities. You can speak with people who already engage with your work. You can ask former clients about problems they are now trying to solve.
You can publish a specific example and invite people facing that situation to discuss it.
A referral or an introduction can also create a useful conversation.
What matters is whether the interaction helps you understand a real need and gives a suitable person a clear opportunity to consider your offer.
Publishing can support that process, but a full content calendar is not proof that it is working.
If I schedule a month of posts, I would want to know what those posts are intended to help me learn or achieve.
Are they explaining a service? Demonstrating relevant ability? Addressing a question buyers repeatedly ask? Creating a reasonable path to an enquiry?
Or am I mainly increasing the amount of content moving through the system?
That is a question I would ask without dismissing the value of visibility.
A consistent presence can help people become familiar with your work. It still needs a connection to the customers and projects you hope to attract.
The same care applies when the first sale arrives.
It is tempting to take one successful project as permission to automate the whole business.
I would celebrate the sale and study it.
Why did that person buy? What were they trying to achieve? How did they find me? Which part of the offer mattered? How much work did delivery require?
A first client gives you a real experience to examine.
They may also have unusual needs, a personal relationship with you, or circumstances that make their purchase difficult to repeat.
That does not reduce the value of the project. It means there is more to learn.
I would look for patterns across suitable customers over time.
Which questions keep appearing? Which steps stay the same? Which parts of the work require judgement each time?
The repeated, stable steps are stronger candidates for automation.
Suppose every agreed project requires the same basic information, and you have learned which questions clients can answer easily. An intake form now has a clearer purpose.
Suppose you repeatedly spend time creating the same folder structure after a project is confirmed. Automating that task may be straightforward and useful.
Suppose delivery is frequently delayed because reminders are being forgotten. A simple reminder process may address a problem you can already identify.
Those decisions are grounded in work that is happening.
You have a better idea of what the system needs to do and how you will know whether it helps.
I would also keep a way to notice exceptions.
If a client replies to an automatic message with a question, that reply should reach someone who can respond. If a step fails, it should not disappear silently. If the process stops matching the offer, it should be possible to change it without rebuilding everything.
A useful system should leave the business easier to manage.
For someone who already has an elaborate setup and very few customers, I would begin with a review rather than a dramatic reset.
Look at what is actually being used.
Keep the tools that make the basic experience reliable. Identify the unused features and sequences that depend on assumptions you have not tested. Pause additional building while you investigate the most important uncertainty.
That uncertainty might be the audience, the problem, the offer, the price, or the way people discover you.
Choose a manageable way to learn more about it.
If the offer is unclear, show it to suitable people and listen to what they think it includes.
If you are unsure about the service itself, discuss recent examples of the problem and consider a clearly scoped paid pilot.
If delivery takes too long, examine where the time goes before deciding which step to automate.
The next useful action depends on what you need to learn.
I would also keep a record of what changes after each conversation or project.
Perhaps you revise the package description. Perhaps you simplify the first engagement. Perhaps you remove a deliverable that sounded attractive but did little for the customer.
Those changes are business progress too.
They may be less visually satisfying than a connected workflow, but they can give that workflow a much stronger purpose later.
This is what I want to remember when another tool makes me feel that my business is behind.
A small business can be organised without being complicated. A professional service can begin with a clear offer, a reliable way to communicate, and a process simple enough to adjust as the work develops.
I want room to learn before I make every decision difficult to change.
And I want automation to respond to something real.
A task that is consuming time. A repeated mistake. A process customers already use. A necessary part of the product’s promise.
Before building another sequence, I would like to be able to point to the need it serves.
Then, when a new enquiry arrives, I can concentrate on understanding the person behind it. The system can handle the routine steps I already understand, while I pay attention to what this customer still has to teach me.
Top comments (0)