Customer success teams improve retention by keeping every integration running
When a customer reports that something stopped arriving in their accounting system, the expensive part is finding out which system, which call and which moment. Maesn puts that in one record with the same fields whichever system answered.
- targetSystemthe customer's own system
- unifiedApithe call that ran
- timestampthe moment it ran
- meta.warningsthe field it ignored
The ticket is cheap, the diagnosis is not
A customer reports a symptom. Everything expensive happens between that and knowing what went wrong.
Without a layer in between, answering one report means knowing which of the connected systems that customer runs, where that system keeps its errors and what its particular vocabulary calls this failure. The work is per system and it lands on the person who has the customer on the line, which is rarely the person who wrote the integration.
The second cost is the shape of the answer. When support cannot separate a rate limit from an expired credential, every report becomes a question for engineering, and every customer hears the same thing: somebody will look into it.
Four documented fields, and the same four every time
The record answers who, what, when and what was ignored, whichever system was behind the call.
- Which system?context.targetSystem
The customer's own system, named on the record rather than inferred from the connection.
- Which call?context.unifiedApi
The unified endpoint that ran, so the report maps to something you can reproduce.
- When?context.timestamp
One moment, comparable across systems, so a failed sync is attributable rather than approximate.
- Anything ignored?meta.warnings
A field the target system silently dropped, surfaced instead of discovered in a report weeks later.
- Unified Logging & Monitoring
Opening a different vendor console per customer to find out what happened.
- Unified Error Handling
A failure vocabulary per system, and a runbook that grows with every integration.
- Unified Webhooks
Finding out from the customer that something changed on their side.
- Asynchronous Processing
The month-end pile-up arriving as a wave of tickets instead of a queue.
Three outcomes instead of a taxonomy per vendor, and one of them needs the customer
A support process does not need to know which of six status codes it was, it needs to know which of three things to do. Because the envelope, the categories and the retry policy belong to Maesn rather than to each vendor, that list is three items long and stays three items long as you add systems.
Rate limited, an internal error, or the target system is down. Retried with a backoff on our side, so the answer to the customer is that it is already in hand.
The credentials stopped being valid, which happens when a customer changes their own login or revokes access. The only case in this list where the customer has to do something.
The payload failed validation or the record already exists. This one is a bug report with the failing fields already named, rather than a mystery to reproduce.
Three outcomes rather than one taxonomy per vendor, and only the middle one needs the customer. The documented retry guidance behind them, code by code, is on the error handling page.
A collection platform on what happened when customers could connect their own tools
“Since integrating with Maesn, we've dramatically increased our platform adoption - supporting a wide range of accounting systems in one go. Our customers can connect their existing tools instantly, which drives engagement and makes Maesn a key part of our success strategy.”
We make the failure legible, the conversation stays yours
A layer that claimed to manage your customer relationship would be overreaching, and easy to disprove.
- Which system, which call and which moment, on the record itself
- One failure vocabulary and one retry policy across the systems
- A warning where a target system silently ignored a field
- Retries for the failures that are ours, before anybody is told
- What the customer is told, and when
- Whether a reconnect is worth a call or an email
- Which integrations an account should be using at all
- The renewal, which no integration layer can claim credit for
The workflow a support team is usually asked about is payment reconciliation, because that is where a customer notices a gap first. Which systems a customer can be connected to at all is the integration directory, and what is kept on the way through, which is the question a customer's own security team will ask, is on the security page.
Common questions
A customer says the sync stopped. Where does support start?
Can support tell whether it is our problem or the target system's?
What does support have to ask the customer to do?
Do we find out about a problem before the customer does?
Does a field the target system ignores show up anywhere?
What happens at month end, when everything runs at once?
Does this reduce churn?
Can integrations be activated per customer after go-live?
Build once on the Unified API.
See how a failure you can attribute in one lookup works for your integration, or dive into the technical reference.