This is a real project. A food delivery company in Dar es Salaam — a client I have been working with since 2021 — had a process problem that was costing them time and money every single day. Staff were manually calling vendors to notify them of order updates. As order volumes grew, so did the time spent on those calls. It was repetitive, error-prone, and entirely automatable.

This is how I built the solution and what I learned in the process.

The problem in detail

Every time a new order came in, the operations team needed to notify the relevant vendor — a restaurant or food preparation partner — that an order was placed and being dispatched. With low order volumes this was manageable. As the business scaled, it became a bottleneck. Staff were spending significant time on calls that conveyed the same information in the same format every time — exactly the kind of task that should not require a human.

The business needed: automatic outbound calls triggered by order events, a recorded voice message delivering the order details, confirmation that the call was received, and logging of call outcomes for review.

The technology stack

What we built on

  • Yeastar P560 IP-PBX — on-premise telephony server managing SIP trunks and call routing
  • Asterisk — open source telephony engine handling the outbound call logic and IVR
  • Node.js middleware — API layer bridging the order management system and the telephony infrastructure
  • n8n — workflow automation platform orchestrating the trigger, logic, and notification flows
  • WireGuard VPN — securing the connection between the cloud-hosted components and on-premise infrastructure
  • REST API — connecting the order events to the automation trigger

How it works

When a new order is placed in the client's order management system, a webhook fires to the Node.js middleware. The middleware validates the order data, looks up the relevant vendor's phone number, and passes the call request to Asterisk via the Asterisk Manager Interface (AMI). Asterisk then initiates an outbound call to the vendor through the Yeastar P560, which manages the SIP trunk to the local carrier.

When the vendor answers, they hear a pre-recorded IVR message with the order details — order number, item summary, and dispatch information. The vendor can press a key to confirm receipt or request a callback. The outcome is logged back through the middleware and recorded in n8n for reporting.

n8n handles the orchestration layer — managing retries if a call is not answered, escalating to a different contact number after a defined number of attempts, and sending a summary report to the operations team at the end of each shift.

The challenges

The technical integration was not the hard part. The harder parts were:

The most important thing I have learned building automation for Tanzanian businesses is to design for failure. Connectivity drops, carrier issues, power outages — your automation needs to handle these gracefully, log what happened, and give operations staff visibility so they can intervene when needed. Automation that fails silently is worse than no automation.

The result

The manual vendor calling process was eliminated entirely for standard order notifications. Staff time that was previously spent on repetitive calls was freed for exception handling — the cases that actually need a human. Call delivery is faster and more consistent than the manual process was. The operations team has a log of every call attempt, outcome, and escalation.

The platform has been running in production since 2026 and continues to handle vendor notifications as the business scales.

What this pattern applies to

The same architecture — IP-PBX, Asterisk, API middleware, n8n orchestration — applies to a range of business automation problems beyond food delivery:

If your business has a repetitive outbound communication process that follows a consistent pattern, it is almost certainly automatable. The technology to do it exists, it is not prohibitively expensive, and the time savings compound quickly at scale.