About half my discovery calls end the same way.
"I don't think I'm the right person for this project."
Then I recommend someone else. Or suggest they solve it differently. Or tell them they're not ready for automation yet.
Early on, I would have taken every project. Needed the money. Wanted to build the portfolio. Worried about turning work away.
But I learned something. Bad-fit projects cost more than they pay.
Here's what I mean by bad fit.
Projects where automation isn't actually the solution. Where the client needs to fix their process first. Where expectations don't match reality. Where I'm not the right person for the job.
These projects never go well. Even if you deliver exactly what was asked for, the client won't be happy. Because what they asked for isn't what they needed.
I had a discovery call with a small business owner. Wanted to automate customer support responses. Had a dozen people manually answering emails. Thought AI could handle it.
I asked to see examples of the support emails. Looked through about 50 messages. Every single one was different. Complex questions. Nuanced situations. Required understanding business context.
AI couldn't handle that. Not reliably. Not without constant human oversight, which defeats the point.
I told him that. Explained why it wouldn't work. Suggested they standardize responses first, build an FAQ, reduce the variation. Then maybe automate specific types of inquiries later.
He thanked me. Appreciated the honesty. Didn't hire me. That's fine. I saved us both from a failed project.
Bad projects don't just fail to deliver value. They actively harm your business.
They take time away from good projects. They drain your energy dealing with misaligned expectations. They damage your reputation when the client isn't happy, even if you did good work.
And they kill your motivation. Nothing is worse than working on something you know won't actually help the client.
I took a bad-fit project early on. Should have said no. Didn't. Spent three weeks building something the client thought they wanted. Delivered it. They used it twice and went back to their old process.
Wasn't my fault. I built what they asked for. But it didn't solve their actual problem. They were frustrated. I was frustrated. Nobody won.
That's when I started saying no.
Here's what makes me say no.
If the problem isn't well-defined. "We want to be more efficient" isn't specific enough. "We spend 10 hours weekly manually copying data from X to Y" is specific. I need specifics.
If they haven't tried solving it manually first. Automation multiplies your process. If your process is broken, automation makes it break faster. Fix the process. Then automate.
If they want AI but don't need it. Most automation doesn't need AI. If simple rules work, use simple rules. Cheaper, faster, more reliable. If they insist on AI for the sake of AI, wrong fit.
If they're not ready to change how they work. Automation requires some adjustment. Training. New workflows. If they want automation but refuse to change anything, it won't stick.
If their expectations are unrealistic. "Can you build this in two days for $500?" No. I could. But it won't be good. And you'll be unhappy. Better to say no upfront.
If I'm not the right person. Maybe they need a full custom application. Or they need enterprise integration with systems I don't specialize in. Or they need ongoing 24/7 support I can't provide. I'll recommend someone who can help.
Here's what makes me say yes.
Clear problem. They can describe exactly what's broken and how they currently handle it.
Measurable outcome. They know what success looks like. "Save 10 hours weekly" or "Reduce errors by 90%" or "Process orders in under 5 minutes."
Realistic timeline. They understand this will take weeks, not days. They're willing to invest time in planning and testing.
Willingness to adapt. They're open to changing their workflow if it makes the automation better.
Right scope. The project fits what I'm good at. Business automation. Workflow optimization. Simple AI integration. Custom tools.
When all of those align, the project usually goes great. Client is happy. I'm happy. They get real value. I get a case study and probably a referral.
Being selective is a privilege.
I can only do this because I'm not desperate for work. I have a day job at Wells Fargo. Consulting is side income. I don't need every project.
If you're starting out and need the money, you might not be able to turn down work. That's okay. Sometimes you have to take suboptimal projects to pay bills.
But as soon as you can afford to be selective, be selective. Your business will be better for it.
Every yes to a bad project is a no to a good one. You only have so much time. Use it on work that actually makes a difference.
How to say no without burning bridges.
I'm honest about why it's not a fit. I don't make up excuses. I explain what they actually need and why I'm not the right person to provide it.
I try to help anyway. Point them toward resources. Recommend other consultants. Suggest alternative approaches.
I stay open to working together later. "You're not ready now, but if you fix X and Y, reach out again in six months."
Most people appreciate the honesty. They'd rather hear "no, and here's why" than waste time and money on something that won't work.
And some of them come back later. After they've addressed the issues. When they're actually ready. Those turn into great projects.
Saying no is hard. Especially when you're building a business. But it's necessary. For your sanity. For your clients. For the quality of your work.
Take the projects that fit. Say no to everything else. You'll be happier. Your clients will be happier. Your work will be better.