We currently work with a company that has a fairly simplistic web system for processing warranty information. The only way to get data out of it is through excel exporting. Compilation of this data and correlation with our systems has to be manual and makes us be reactive in our response.

The ideal situation would be setting up a web service on their side and automatically mash it up with our data so that we can have good and timely information without human overhead or the weekly bottleneck.

However, when we mentioned this same argument to them, their IT department creeped out from us wanting to access their systems "directly", since they have other information for other vendors which are our competition. In other words, they seem to think it is something weird and insecure.

My question is: how would you make them understand the need to modernize their systems?, have you had any experience convincing the company you want the web-service from?, and, would you go convince them yourselves as a company with the need, or hire a consultant to assess this and speak with them instead?

Edit: We supply custom made electronic devices for our clients which then sell it to end users. End users deal with our clients and, depending on the case, then the client deals with us if they require software/hardware fixes for the next revision.

  • What's the nature of the business partnership? Commented Aug 9, 2012 at 16:45
  • @Baqueta Answered your question in my edit Commented Aug 9, 2012 at 18:33

3 Answers 3


I've worked on this exact problem with several B2B clients and it what it always comes down to is having a conversation with the team on their end where you clearly discuss the pros and cons of your proposal and work to mitigate any concerns they raise.

Before you do this you need to understand where your client is coming from. It's extremely difficult to get businesses to make significant (or even minor) shifts in their systems because what they have, no matter how crappy, is working for them and they know how to work around all the rough patches and bugs. It's quite amazing how people will adapt to and become quite proficient with crappy software. It's easy to say upgrading to a new system will transport them to a mystical land of efficiency and unicorns and rainbows but the fact is that updating to a new system poses significant risk in the terms of new bugs and potential downtime. All of these things equate to lost money for a business.

So the chief argument you need to make is that your proposed set up is going to make the system work more efficiently with fewer errors. This is something most IT teams will get behind as they do want to do less work and make their systems more efficient. You have to present them with a clear, well thought out solution and then work with them to address their concerns.

Here are two general solutions that I've used in the past:

Push Web Service

A push web service is a web service that you set up on your end and the client pushes data to (not sure if this is the official name of this but it's what I've always called it). I've found that most clients favor this option as it puts them firmly in the driver's seat in terms of what data is going out of their system.

Pull Web Service

This is the opposite of a push service and what you mentioned in your question. In this scenario the client sets up a web service that you then call to get data out of their system. Clients typically don't like this for variations on the reasons you stated in your question. In fact I've only set up such a system once and then the server making the call first had to connect to the client's VPN (spoiler: it was a complete pain in the ass).

There are other details you need to consider as well. For example, setting up your push service such that it won't get overloaded by a client pushing too much data too frequently.

In the end it always comes down to having a good, close working relationship with the client's IT team. If you establish this relationship you'll be good.


A lot of organizations are hesitant to have an external source pull data from them. Perhaps a compromise would be to setup an endpoint on your end that will allow them to periodically push data. This way they know exactly what data you are processing and they control the frequency of data updates.

Education on your definition of a "web service" is often the best way to bring them to your side. A lot of IT workers in the enterprise world seem to a "web service" means a process that will SSH/FTP into a server and download data. They don't realize that they can setup a REST/SOAP/XMLRPC endpoint (with strong[ish] authentication) and only export data they have chosen to share.

I'd say build a simple proof-of-concept, present your implementation to them, and give them example code with instructions on setup. Let them play around with the idea, determine it's secure, and see where they go from there.

Lastly give them the opportunity to ask questions, primarily what about all of this concerns them about this idea. Ideally have this be in person or over video conference so you can see each other face to face and give ample opportunity to brainstorm and think out loud.


You have to remember that your idea of new and better may not fit with their goals. You will, of course, need to clearly indicate the advantages of switching to your proposed architecture. However, you must also outline the disadvantages.

Just because the client rejects your idea, it doesn't mean that they are acting unreasonably. Go in and ask lots of pointed questions and get very specific answers as to what their concerns are about changing their systems. If you feel an answer is too vague (e.g. "Change is bad"), then dig deeper for a reason.

The ultimate goal is to work together with them to determine the best solution to the issue at hand. You may find that their reasoning is completely valid.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.