Blog

The Fundamental Problem with IT Services: They never cared about your bottomline

Why IT delivery and business results can drift apart. A real estate broker's story explains incentives, vendor dependence and what a business partner should own.

The Fundamental Problem with IT Services: They never cared about your bottomline. A real estate broker sees flat site visits while an IT vendor's monthly bill grows, despite a delivered CRM.

Imagine you are a real estate broker. You spend money on ads and property portals, but too many enquiries never become site visits. Leads get assigned late, follow-ups are inconsistent, and interested buyers disappear without anyone knowing why.

You hire a technology company. Its proposal includes a CRM, WhatsApp integration, automated reminders, and dashboards.

All useful things. But somewhere in this conversation, “help us convert more buyers” becomes “implement these tools.”

I think this is where the traditional IT services model often went wrong. The engagement was organised around delivering technology, while responsibility for improving the business remained unclear. There were genuine partnerships, of course. The commercial structure just did not always require one.

Ravi wants more buyers to show up

Ravi, a real estate broker, asks for more site visits. A vendor proposes a CRM, WhatsApp integration and dashboard.

The gap is easy to miss when you are signing the proposal. You see the tools as a way to improve sales. The supplier sees a defined set of deliverables.

Economists call the underlying conflict a principal–agent problem. You hire someone for their expertise, but their interests do not automatically match yours. And because they understand the technology better, you cannot easily judge every recommendation.

Does fixing follow-up really require another integration? Is a custom application necessary? Could changing the assignment rules solve the problem?

Research on software outsourcing has examined this combination of unequal information and divergent incentives for years. You do not need dishonest people for it to become a problem. The arrangement itself can pull competent people towards different priorities.

The CRM is ready. Buyers still miss visits.

The CRM is delivered, but buyers still miss visits. The vendor offers more automation and support; Ravi asks what is going wrong.

The CRM can work exactly as specified while enquiries still go unanswered. A reminder can be sent without anyone checking whether the buyer actually intends to attend.

Before proposing another feature, someone needs to investigate that gap.

Now look at the commercial incentives. Hourly billing rewards billable effort. A fixed-price project rewards keeping delivery costs below the agreed price. Change requests create additional revenue. Support agreements extend the relationship.

These arrangements can fund necessary, valuable work. But none automatically rewards finding the simplest way to improve your sales process. US procurement guidance explicitly recognises the weak incentive for cost control and labour efficiency in time-and-materials contracts.

LTV, renewals, and revenue per client are sensible business metrics. The question is whether account growth comes from increasing customer value or increasing customer dependence.

If the customer keeps paying while the original problem continues, the supplier's account can grow without the customer's business becoming meaningfully better.

Ravi thinks about changing vendors

Ravi asks a new team to take over, then discovers he needs admin access, setup notes, lead exports and integration details.

That sounds straightforward until you try.

Your lead history sits in one system. Follow-up rules live in another. Someone else controls an integration account. Nobody has documented how the pieces work together.

With a licensed CRM, you would not expect to own the platform's source code. You should still understand your account rights, data exports, integrations, and transition options. For custom software, receiving the code is only part of being able to operate it independently.

Some switching costs are unavoidable. But missing access and undocumented workflows make the transition harder than it needs to be. The UK National Audit Office has documented dependency on uncompetitive, single-supplier support arrangements among legacy IT risks.

A customer renewing because the team keeps creating value is a healthy relationship. Renewing because leaving feels operationally dangerous deserves a closer look.

Maintenance is necessary. What is it improving?

I am not arguing that support or annual maintenance contracts should disappear.

Your systems need security updates, monitoring, backups, and adjustments when external services change. Someone has to do that work and should be paid for it.

But you should be able to see what the ongoing relationship produces. Are repeat failures declining? Are integrations more dependable? Is the sales team using the system properly? Is less time being spent chasing the same issues?

An ongoing fee can support prevention and improvement. It should not become an unquestioned charge for repeatedly dealing with avoidable problems.

AI does not automatically change the incentives

Suppose AI helps the vendor complete an integration faster. Under hourly billing, that could reduce revenue. Under fixed pricing, it could increase margin.

Neither tells you whether the real estate broker now converts more relevant enquiries into attended visits.

There is nothing wrong with a supplier benefiting from better productivity. But the useful conversation is what that productivity makes possible for the customer.

Can the team investigate missed follow-ups? Improve qualification? Help salespeople act on buyer preferences? Test a better appointment-confirmation process?

Adding AI to delivery does not, by itself, turn an IT vendor into a business partner. The responsibilities and measures still matter.

This time, they start with the missed visits

The new team reviews missed visits with Ravi, finds that nobody confirmed appointments, and agrees responsibility and weekly review.

The useful change here is that someone follows the problem beyond whether the software works. The team checks the enquiry records, finds a gap in responsibility, and agrees what each side will do.

Then they review whether it helps. If attendance does not improve, they keep investigating. Perhaps the appointment timing is inconvenient, the buyer is not ready, or the property does not fit.

This does not mean a technology partner can guarantee bookings. Inventory, pricing, financing, buyer intent, and the sales team all influence the result.

It means those dependencies get discussed, responsibilities are agreed, and progress is reviewed against evidence. A completed implementation is a milestone in that work.

Even outcome-based pricing needs care: tying payment to factors outside a supplier's control can create another badly aligned arrangement.

How we approach this at OLN Labs

At OLN Labs, we bring business, product, technology, and go-to-market thinking together around an agreed goal. We define success and how to measure it, then build, run, and improve the solution. Customized AI agents and our platforms accelerate the work, while ownership, responsibilities, and commercial terms remain clear. This is our approach to Outcome as a Service: staying involved in making the solution useful to the business.

When you next review your technology engagement, ask: are we discussing what was delivered, or what improved—and what we need to fix next?

If you want to have that conversation about your business, talk to us.

Contact

Let’s talk.

Tell us what your business needs.

Talk to us