Complex commercial processes. Beyond CRM automation.
A single sale can depend on pricing, stock availability, credit decisions, approvals and delivery capacity across several systems and teams.
Kongo designs business orchestration to manage that complexity. We define what happens in parallel, what must wait, which business rules determine the next step and how the process responds when something changes or fails.
Your CRM participates in the process. It does not have to control the whole operation.
More than a sequence of automated tasks.
Sending information to another system does not establish whether the whole process is ready to move forward. Showing a task as complete does not resolve the dependencies around it.
An order might have enough stock but still need credit approval. An approval might arrive after a reservation has expired. A customer might change the order while fulfilment is being prepared.
Orchestration manages the process around those conditions, rather than leaving people to reconcile the results of disconnected automations.
Integration connects your systems. Orchestration controls how the whole process runs.
Design the logic behind the work.
Run independent activities in parallel.
Identify which steps can happen together and which depend on earlier results. Stock checks, credit assessment and delivery planning do not always need to wait for one another, but the final release may depend on all three.
Apply business rules at the right decision points.
Route work according to the customer, order type, value, margin or other agreed conditions. Define which cases can proceed automatically and which need review, including what happens after a decision is rejected or changed.
Manage work that takes time.
Design how the process waits for a person, an external event or a deadline. Establish reminders, escalation paths and checks that information is still valid before the next step proceeds.
Control the dependencies.
Make the conditions for proceeding explicit. Starting onboarding or releasing an order should depend on the required checks and approvals, not simply on the most recent system event.
Recover deliberately when something fails.
Define which failures can be retried, which require intervention and what happens to work already completed. That can include releasing reserved stock or cancelling a provisional booking when a later decision prevents the process from continuing.
A retry should not blindly create another order or repeat an action that has already succeeded. We design the checks and recovery actions around the behaviour of the connected systems.
One order. Multiple systems. One coordinated process.
Consider an order agreed in the CRM, with pricing and stock in an ERP, credit assessment in finance and fulfilment managed by a delivery team.
The orchestration first checks that the required information is complete and selects the appropriate process. Stock and credit checks can then run in parallel, with exceptions routed to the right decision maker.
Fulfilment remains on hold until stock, credit and any required approvals are confirmed. If approval is overdue, the process escalates it. If credit is declined after stock has been reserved, the process can release the reservation and notify the account owner instead of allowing the order to continue.
These are business behaviours we design and implement, not capabilities that appear simply because the systems are connected.
Check required information. Select the process by order type and value.
Confirm pricing and reserve stock while finance assesses credit.
Apply credit rules. Route exceptions to the appropriate approver.
Start fulfilment only when stock, credit and required approvals are confirmed.
Stock availability and credit checks happen together.
Stock reserved. Credit cleared. Required approvals complete.
Keep fulfilment on hold, release reserved stock and notify the account owner.
Escalate to the agreed decision maker. Keep the order on hold.
Retry where safe. Alert the team if unresolved. Prevent dependent steps from proceeding.
Give AI a defined role within the process.
An AI agent might review an onboarding brief, summarise customer history or recommend how to route an exception. Its output becomes an input to a controlled process, not permission to take every subsequent action.
We establish what the agent can access and do, how its output is checked and where a person must decide. Conventional rules and automation remain the right choice where reasoning is not required.
Established technology. Designed around your business.
Kongo’s orchestration architecture is designed around AWS Step Functions, with your CRM, integrations and other business systems participating in the process.
We combine reusable components with the business rules and workflows your process needs. That includes the required connections, human interactions, monitoring and exception handling, with responsibilities and support agreed for the engagement.
Systems Integration provides the connections. GTM Advisory establishes the commercial rules and priorities. Change Management, Training and Adoption, and AI and Technology Governance help make the resulting process workable and accountable.
Common questions.
Could this stay in our CRM workflows?
We assess that first. Work that belongs in the CRM can stay there. A separate orchestration layer is appropriate when the wider process needs coordinated decisions, dependencies and recovery across several systems and teams. It is not a reason to move every automation out of the CRM.
Can people participate in the process?
Yes. Reviews and approvals can be part of the design. We establish how people receive the work, what information they need and how their decision returns to the process. A suitable task or approval interface is part of the solution to be scoped, not something we assume the orchestration engine provides.
Does orchestration need new integrations or AI?
Not necessarily. We assess and reuse suitable connections and automation where they exist. AI is included only where it serves a defined purpose. The requirement is to coordinate the process, not to replace working components or introduce AI everywhere.
How do we know when a process needs attention?
We define the process states, events and exceptions that matter, then design the required visibility and escalation. That might include stalled approvals, failed actions or work waiting on another system. Monitoring and support coverage are agreed for the solution.
Bring us the process that is too complex for another workaround.
Tell us which systems and teams are involved, where the decisions sit and what happens when things do not go to plan. We will help you design how the whole process should run.