Cut cost per call in Kenya: call deflection vs callback economics (with the KES math)

Every inbound call that reaches a human agent costs your business money. In Kenya, a Nairobi call-centre agent handling 40 calls/day at KES 50 000/month costs KES 31.25 per resolved call. The question is not whether to deflect calls but which ones to deflect, which to accelerate, and where the crossover point lies. This post builds the economic model for call deflection and callback scheduling using Sautikit's inbound voice flow, with numbers grounded in Kenyan labour and telecoms costs.

Most call centres underestimate per-call cost by counting only salary and ignoring NSSF, NHIF, office, equipment, and management allocation. A Nairobi agent earning KES 50 000/month has a fully-loaded cost closer to KES 75 000/month. At 40 calls/day and 22 working days:

cost_per_handled_call = 75 000 / (40 × 22) = KES 85.23

Inbound calls are free (KES 0/min), so a 2-minute IVR self-service call costs KES 0.

Deflection value per call = KES 85 − KES 0 = KES 85

At 200 calls/day with a 60% deflection rate: 120 calls/day × KES 85 = KES 10 200/day or KES 224 400/month saved.

Not all calls can be deflected. The deflectability of a query depends on whether it can be resolved with information the system already has (balance, order status, appointment time) versus whether it requires human judgment or negotiation.

Query type	Deflectable?	IVR resolution rate	Notes
Account balance inquiry	Yes	>95%	Simple data lookup
Order status	Yes	>90%	Requires order ID lookup
Payment confirmation	Yes	>85%	Play back last transaction
Appointment time	Yes	>90%	Requires booking lookup
Password reset	Partial	~60%	Often needs fallback
Loan dispute	No	<20%	Requires human judgment
Fraud report	No	<10%	Always escalate immediately
Complaint escalation	No	<5%	Deflection destroys NPS

The IVR self-service patterns that work are those with a structured answer. "Your balance is KES 1 250" can be automated. "Why was my loan declined" cannot.

IVR menu flow

Each digit press posts back to your voice_callback_url. Your server reads the Digits field and returns the next action set.

{
  "actions": [
    {
      "say": {
        "text": "Welcome. For account balance, press 1. For order status, press 2. For payment history, press 3. To speak to an agent, press 0.",
        "language": "en-KE"
      }
    },
    {
      "getDigits": {
        "numDigits": 1,
        "timeout": 10000,
        "finishOnKey": "",
        "action": "https://your-server.example.com/webhooks/ivr-main"
      }
    }
  ]
}

The main menu webhook branches on the digit received:

// POST /webhooks/ivr-main
app.post("/webhooks/ivr-main", async (req, res) => {
  const { digits, sessionId } = req.body;
 
  switch (digits) {
    case "1":
      return res.json(await buildBalanceFlow(sessionId));
    case "2":
      return res.json(await buildOrderStatusFlow(sessionId));
    case "3":
      return res.json(await buildPaymentHistoryFlow(sessionId));
    case "0":
      return res.json(buildAgentTransfer());
    default:
      // No input: route to callback offer
      return res.json(buildCallbackOffer(sessionId));
  }
});

The callback offer for customers who press 0 or don't respond:

function buildCallbackOffer(sessionId) {
  return {
    actions: [
      {
        say: {
          text: "All our agents are currently busy. Press 1 to receive a callback within 30 minutes. Press 2 to leave a voice message.",
          language: "en-KE",
        },
      },
      {
        getDigits: {
          numDigits: 1,
          timeout: 8000,
          finishOnKey: "",
          action: "https://your-server.example.com/webhooks/ivr-callback-choice",
        },
      },
    ],
  };
}

The critical principle is knowing when to stop deflecting. Forcing a customer through IVR levels when they need an agent destroys NPS.

Two observable signals of "false self-service" (calls that appear deflected but are not resolved):

The customer presses 0 (agent) at every menu level. This customer was never going to accept IVR service. They should have been routed to an agent at the first press-0 signal.
The customer hangs up during IVR. The call is counted as "deflected" but the query is unresolved. The customer will call back or complain.

Sautikit's call detail records include the digits collected at each GetDigits step in the call's event log. By logging DTMF selections and correlating them with post-call outcomes, you can identify which IVR branches are "false self-service":

-- Calls where the customer pressed 0 at the main menu (agent request)
-- but the call still ended without an agent transfer (likely abandoned)
SELECT
    date_trunc('week', c.created_at)        AS week,
    COUNT(*)                                  AS total_calls,
    SUM(CASE WHEN ce.digits = '0'
             AND c.status = 'completed'
             AND c.duration_seconds < 60
             THEN 1 ELSE 0 END)              AS probable_false_deflections,
    ROUND(
        SUM(CASE WHEN ce.digits = '0'
                 AND c.status = 'completed'
                 AND c.duration_seconds < 60
                 THEN 1 ELSE 0 END)::numeric
        / NULLIF(COUNT(*), 0) * 100, 1
    )                                         AS false_deflection_rate_pct
FROM calls c
LEFT JOIN call_events ce
    ON ce.call_id = c.id
    AND ce.event_type = 'getDigits.completed'
    AND ce.menu_level = 1
WHERE c.direction = 'inbound'
  AND c.created_at >= NOW() - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1 DESC;

IVR branches where the false-deflection rate exceeds 20% should be redesigned: either the content is unclear, the resolution path is too long, or the query type is genuinely not deflectable.

Call abandonment (callers who hang up before reaching an agent or completing the IVR) is a direct revenue leak. A caller who abandons has expressed intent. Recovering them with a callback converts that intent into a transaction.

The economics of callback recovery:

abandon_rate              = 15%  (typical Kenyan contact centre)
calls_per_day             = 200
abandoned_calls_per_day   = 200 × 0.15 = 30
avg_order_value           = KES 150  (per resolved call)
revenue_at_risk_per_day   = 30 × KES 150 = KES 4 500

callback_recovery_rate    = 60%  (industry benchmark)
recovered_calls_per_day   = 30 × 0.60 = 18
recovered_revenue_per_day = 18 × KES 150 = KES 2 700

A callback system recovering 60% of abandons saves KES 2 700/day in revenue that would otherwise be lost. The cost of the callback calls:

callback_calls_per_day    = 30  (one attempt per abandoned caller)
avg_callback_duration     = 3 min
cost_per_callback         = 3 × KES 3 = KES 9
daily_callback_cost       = 30 × KES 9 = KES 270

Net daily revenue improvement from callbacks: KES 2 700 − KES 270 = KES 2 430.

Payback period for building a callback system (assuming 5 days of engineering at KES 50 000/day):

build_cost     = 5 × KES 50 000 = KES 250 000
daily_benefit  = KES 2 340
payback_days   = 250 000 / 2 340 ≈ 107 days (≈ 3.5 months)

This is a defensible investment for any operation with more than 200 inbound calls/day.

The most robust callback pattern uses Record (leave a voice message) combined with an async callback queue. The customer hangs up knowing they will be called back; the agent calls back with context from the voice message.

{
  "actions": [
    {
      "say": {
        "text": "All our agents are busy. Please leave a message after the tone and we will call you back within 30 minutes.",
        "language": "en-KE"
      }
    },
    {
      "record": {
        "maxLength": 60,
        "finishOnKey": "#",
        "action": "https://your-server.example.com/webhooks/voicemail-received",
        "transcribe": false
      }
    }
  ]
}

The voicemail-received webhook puts a callback task in a queue:

// POST /webhooks/voicemail-received
app.post("/webhooks/voicemail-received", async (req, res) => {
  const { callId, recordingUrl, from, duration } = req.body;
 
  await callbackQueue.add("callback", {
    callerNumber: from,
    recordingUrl,
    recordingDuration: duration,
    scheduledFor: Date.now() + 30 * 60 * 1000, // 30 minutes
    priority: "normal",
  });
 
  res.json({
    actions: [
      {
        say: {
          text: "Thank you. An agent will call you back within 30 minutes. Goodbye.",
          language: "en-KE",
        },
      },
      { hangup: {} },
    ],
  });
});

Three metrics determine whether your deflection and callback investment is working:

Metric	Target	How to measure
Self-service resolution rate	>75% for deflectable queries	Calls that complete IVR without pressing 0
False deflection rate	<15% per branch	Presses-0 + sub-60s completions (SQL above)
Callback recovery rate	>50%	Callbacks that result in a resolved outcome

The self-service resolution rate is the primary metric. If it is below 60%, the IVR content or routing logic needs redesign before investing in additional automation.

The false deflection rate per branch tells you where to focus redesign effort. A branch with a 35% false deflection rate is costing you NPS points without reducing agent load; it is the worst of both worlds.

Callback recovery rate below 40% usually means callbacks are being placed too late (more than 1 hour after the abandon) or to numbers that have since changed (dual-SIM switching; see dual-SIM voice app patterns).

Deflection routes tier-0 queries to self-service and callbacks recover abandons, but the hardest tickets still need a person plus context across channels. When a caller needs to move from voice to SMS, WhatsApp, or a human-agent desk with ticketing, Helloduty handles that multi-channel handoff on top of your Sautikit voice flows.

Create a Sautikit workspace and claim a phone number.
Top up over M-Pesa: KES billing, no card.
Ship the Record + async callback queue pattern above, then layer in the three-level IVR to start deflecting tier-0 queries.

Start with Sautikit → · See pricing → · Need SMS, WhatsApp & an agent desk? Helloduty →

The voice actions reference covers GetDigits, Say, Record, and Redirect, the four verbs used in all IVR and callback patterns above. The wallet concept page covers the low-balance alert that prevents service interruptions during high-call-volume periods. Full per-minute pricing for inbound and outbound calls is at /pricing.

For operations currently running a manual callback process, the minimum viable implementation is the Record + async queue pattern above, roughly 2 days of engineering. The full three-level IVR with branching and CDR analysis takes approximately a week to build and tune, but the economic case at 200+ calls/day closes in under 4 months.

cost_per_handled_call = 75 000 / (40 × 22) = KES 85.23