One of the “secrets” to providing and maintaining great service integrations is identifying clear technical owners (who may be different than the business owner) from all parties. Whether it be internal or external third party services, having a means to contact the counterpart in the relationship is absolutely necessary.
The owner may or may not be a single person. It could be a team mailing list, but having a known point of contact is essential to great services.
For instance, if a service is expecting to change the API (for breaking changes or just additions), it would be good for the service provider to be able to inform the service consumer. Maybe there’s expected maintainence. Maybe there is now a (better) replacement service. Or maybe there’s different technical requirements (security changes). Maybe the service consumer is hammering the provider with an unexpected amount of traffic.
Of course, a service consumer should be able to contact the service provider for support. Maybe there’s an issue attempting to reach the service. Maybe there’s problems integrating or features that would make life easier.
Having contact information for both the service provider and consumer seems obvious, but often services do not invest in making sure the contacts are the intended audience, ensuring contact details are up-to-date, and the appropriate medium.
Separation of Business vs Technical
Many services fail to distinguish the technical role versus the business role. When you sign up for a third party service account, often you only provide a single email address or phone number. While the person owning the business relationship with the service provider may be technical, there is often someone else who is suppose to own the technical role.
Business owners may not have a clear understanding of technical details. So if the service provider were to contact the service consumer, the business owner may not understand the email and fail to take the appropriate action. For instance, a service provider may state that integrations are required to use a specific version of an SDK. Unless the business owner is technical enough to understand, the news may be lost and a last-minute change may be required by the service consumer. There should be nothing stopping the business owner from also receiving technical information; when adding a technical contact, the intent is not to skip the business owner, but to ensure that information reaches the relevant audience. In a way, it saves the business owner work from forwarding emails.
Ensuring up-to-date contact details
Services should build in an automated system to ensure that contact details are up to date for all relevant parties. Often, technical owners change if not business owners. Unfortunately, many times due to reorgs or other personnel changes, the responsibilities are shuffled and practically no one will/should volunteer to take on more responsibilities without any clear benefits.
For small businesses, a contractor may be involved to develop a new feature using a third party service, but when the contractor is finished with their work, the contractor is no longer the appropriate person to contact. Unfortunately, the service provider is not given the right contact information so any news from the service provider is subsequently lost.
When the contact information is out of date, it leads to unexpected outages, emergency patches, and other stressful events. All because one party could not contact the other.
Whether it be reminding contacts to update their information every few months, having tools to ensure transfer of ownership, or other means, service providers and consumers should be forced to regularly keep their contact information up to date with their respective counterpart.
Appropriate medium for contact
In short, email. While there are many chat programs and services, email is nearly universal for all parties. The communication should not be that often so email is appropriate in many ways.
Each service can decide what is appropriate to contact the other party with (e.g. new API capabilities, SDK versions, requirement changes, or maybe only important emergency notices).
Blogs, GitHub issues, notifications from RSS feeds for version releases, and other mediums are nice, but in many situations neither party can count on them as being monitored by the other party. Email may also be ignored but it is practically the only universal medium where direct contact can be made.
In conclusion, hopefully this post has given some ideas about how to effectively communicate service providers and consumers and why having that relationship be maintained helps ensure a smooth service integration.