Project Management Central

Please login or join to subscribe to this thread

Topics: Stakeholder Management
How to Gather Information from adamant client - Not Sharing Information
Network:22



Hi,
I'm working in SaaS product company. The client integrates with our product through APIs
The challenges are

1.Client refuses to share information on how his system consumes our APIs
2.Refuses to share on exception handling mechanism at their end
3. Refuses to connect to his tech team to know on system design

Due to these missing information, it results in system making more than desired API call to our platform and finally resulting in choking the system, db etc. We have experienced same in the past. Now I'm new program manager for this client projects and don't historical information on integration aspect
Sort By:
Network:1550



If you are working through APIs you do not need the information you list. I worked lot of time into those environments in banking and finance domain and we must integrate with credit cards companies or ATP companies where we were not able to get the information you listed and, in fact, it is not needed. Key to understand in this type of enviormens is: 1-who will act as the client and who will act as the provider. 2-the provider must give you all the details about how to interact with it due to you will "see" it as a blackbox. Inside the information things like error management must be included. 3-SLAs must be negotiated and you have to get an agreement before evrything start.
Network:534



Client need to share API information if he want to achieve objective. There must be an agreements document - business and technology scope.

If technology scope has architectural and API interfacing pre-requisites than customer should provide those details to smoothly execute project. Otherwise option is formally escalate in hierarchy. Pl dig out for escalation, agreement and past communication.
Network:10354



This is not my key area, but certainly Sergio's 3rd point about SLA's is extremely important. Also Rajeev pointed out the same issue. Sounds like your contract with the client is either inadequate, non existing or null in void.
Network:1620



Agree with the point of SLA.
Also, think about how you can modify your API methods not to send information beyond certain MB/GB or members. - Not sure how feasible it is.
But I think it is you designed API and you should own rights to modify it.
Network:1724



Sergio laid out really good information. Prior to the start of the engagement, expectations would be set in the SLA and even the SOW. Even prior to that, when the provider's account manager is beginning the partnership with the client's leadership much of this 'how' and 'expectations' are discussed, then reiterated in the 'discovery' phase.
Network:1550



Just trying to add something more remember that will are "surrounded" by APIs. For example plug-and-socket connections. The only thing you must know is how to plug your component into the provider component. All that happens from the socket to the provider is a concern of the provider. All that happens from the socket to the client is a concern of the client. That is because the hardest part of this type of situations is to stay clear about "all that happens" into each site and how you will interact due to you can do nothing from the socket to your provider environment. I am facing this type of situations every day.
Network:91



As many opinionated, I agree that SLA is what is required but really do not require information how the APIs are being used, exceptions etc. More over we (in my organization) provide documentation on what APIs does, how it needs to be used and limitations if any. For example the input to API is list of values. Can this list have 1K, 100K or 1000K values? This what is provided in the documentation and behavior of API if it exceeds supported values.
Network:723



I'm a little unclear on who is feeling the impact. If you as the service provider are experiencing system issues because of your client's access methods then it either presents an opportunity to improve the scalability of your solution OR deal with the client as if they are violating the terms of their usage agreements by engaging in what is essentially a denial of service attack. If it is the client whose internal systems are being affected due to their inability to integrate efficiently with yours, there's not much that you can do if they won't share some of their info with you.

When I worked for a SaaS provider who offered such bidirectional integration options, we always entered into an agreement with the prerequisite that data consumption and provision specifications would be shared on both sides.

Kiron
Network:22



Thank you so much for all the advice. The agreement with client is inadequate and doesn't specify about data consumption and provision specifications to be shared on both sides.
It is inclined more towards what as service provider must share with client.

Since client is major source of revenue for the company, the escalation option is ruled out.
Let me explain scenario with an example:
Client is e-commerce global player, which runs festive season events such Black Friday deals etc and we power backend technology. During such events, client does transaction more than our system can handle and we realized that it is not our system capability in question but rather different workflows calling APIs connecting to system.
...
1 reply by Kiron Bondale
Feb 10, 2018 12:31 PM
Kiron Bondale
...
Given that the client is a major source of revenue for your company, it sounds like if you can't convince them to change how they are consuming your APIs and don't want to risk losing them as a client, you'll need to find a way to make your own infrastructure more robust to support their access. This might require isolating their access from your other clients and using a dynamic load handling approach which will add processing power based on their demands.

Kiron
Network:723



Feb 10, 2018 11:51 AM
Replying to SHARATH BHAT
...
Thank you so much for all the advice. The agreement with client is inadequate and doesn't specify about data consumption and provision specifications to be shared on both sides.
It is inclined more towards what as service provider must share with client.

Since client is major source of revenue for the company, the escalation option is ruled out.
Let me explain scenario with an example:
Client is e-commerce global player, which runs festive season events such Black Friday deals etc and we power backend technology. During such events, client does transaction more than our system can handle and we realized that it is not our system capability in question but rather different workflows calling APIs connecting to system.
Given that the client is a major source of revenue for your company, it sounds like if you can't convince them to change how they are consuming your APIs and don't want to risk losing them as a client, you'll need to find a way to make your own infrastructure more robust to support their access. This might require isolating their access from your other clients and using a dynamic load handling approach which will add processing power based on their demands.

Kiron

Please login or join to reply

Content ID:
ADVERTISEMENTS

"It takes a lot of courage to show your dreams to someone else."

- Erma Bombeck

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events