Your people should not have to hold your systems together.
Rekeying customer details. Checking prices in another application. Chasing finance for payment information. Maintaining a spreadsheet because two systems disagree.
Kongo designs and builds integrations between your CRM, ERP, finance, commerce and specialist systems, so your commercial teams can work with the information they need without manually bridging every gap.
Understand the business logic before building the connection.
A customer record in the CRM might represent a prospect. In an ERP, creating that same record could mean opening a trading account with payment terms and a credit limit.
The fields might look similar. The business meaning is not.
We establish what the information represents, which system owns it and when it should move before deciding how to connect the applications.
The connection can support actions as well as data exchange, such as creating an order or updating a customer account. Those actions need the same attention to business meaning, permissions and error handling.
Connect the systems behind your commercial operation.
CRM and ERP.
Connect customer, product, pricing and order information where your processes need it. We define what sales should see, what operations should receive and which system remains responsible for each part of the record.
Finance and commerce.
Connect the information behind quotes, invoices, payments, subscriptions and purchases, so commercial teams can work from an agreed picture of the customer and transaction.
Specialist business applications.
Bring relevant information from learning, membership, registry, practice, service and other specialist platforms into the commercial process. We assess each system’s interfaces and constraints rather than assuming every connection works the same way.
Data and reporting.
Make information available for reporting and decisions with consistent definitions, identifiers and ownership. Moving more data is only helpful when people understand what it means.
Build for the way the business actually operates.
We agree the rules for creating and updating records, the direction of each connection and how quickly information needs to move.
We also consider duplicates, incomplete records, conflicting updates and changes to the source systems. The design needs to account for a transaction succeeding even when its acknowledgement does not arrive, so a retry does not blindly repeat a business action.
Sometimes an existing connector is sufficient. Sometimes the business rules require custom development. We recommend the approach that fits the requirement, rather than building something bespoke by default.
Plan for operation, not just launch.
Kongo’s existing integration notification centre supports event monitoring, failure notifications and retry logic based on the type of error.
For each solution, we establish what needs to be monitored, which errors can be retried and when someone should investigate. We also agree the support responsibilities and what happens when a connected platform changes.
A working connection is the starting point. Keeping it useful and supportable is part of the design.
When the requirement goes beyond a connection.
An integration can check stock, create an order or retrieve a credit decision. The wider process still needs to determine when those actions should happen, which can run in parallel and what to do if their results conflict.
That is where Business Orchestration complements integration. It manages the decisions, dependencies and recovery across the whole process, using connections we build or suitable ones you already have.
Integration connects your systems. Orchestration controls how the whole process runs.
Connect the design with the people using it.
GTM Advisory helps establish the commercial requirements and data ownership behind the connection. Change Management and Training and Adoption help teams understand where to maintain information, what the integration does for them and how to handle exceptions.
AI and Technology Governance can address access, supplier responsibilities and usage costs where relevant. We bring in those capabilities when the problem needs them, not as a compulsory bundle around every integration.
Common questions.
Should we use a native integration instead?
Where it meets your requirements, yes. We assess the data coverage, business rules, error handling and operating model before recommending whether to use an existing connector, extend it or build a different solution.
Can you integrate a system that is not on your website?
We can assess it. Feasibility depends on the interfaces, access, data and actions the system supports. We confirm those details before committing to a solution.
Do integrations include ongoing support?
Ongoing support and monitoring arrangements are agreed as part of the engagement. We make the responsibilities, coverage and escalation process clear rather than assuming every integration has the same support needs.
Tell us what needs to connect. And why.
We will help you define the information, business rules and operating requirements behind the connection, then choose an appropriate way to deliver it.