DEV Community: Programmatic DIB

Designing an NDR call workflow around live shipment state

Programmatic DIB — Sat, 24 Oct 2026 06:22:38 +0000

Originally published as a Fonix.AI practical guide by AntEngage. This republication uses the same guide content.

An NDR event needs a current next step

NDR calling automation helps a fulfilment team respond to a non-delivery report: contact the customer, understand the obstacle and submit an eligible instruction to the courier. The useful result is a verified delivery action attached to the correct shipment. A customer saying “try tomorrow” is a preference until the carrier accepts the request.

This workflow starts after dispatch and a failed delivery event. It differs from COD confirmation, which concerns an order before dispatch, and cart recovery, which concerns an unfinished checkout.

Fonix.AI supports business voice conversations in Indian languages. Evaluate the call together with your order, shipment and courier systems. The event feed, address-change permissions and reattempt actions must be confirmed for the actual carrier integration.

Resolve the latest shipment event

Keep the shipment reference, order reference, courier, failure reason, event time and event identifier. A single order may contain several parcels, so an order number alone is not enough to choose the affected delivery.

Read the latest carrier state before calling. The parcel may already be delivered, out for another attempt, cancelled or returning to origin. A delayed or duplicated webhook should not reopen a closed recovery case.

Treat carrier reason codes as reports to clarify rather than unquestionable descriptions of the customer's behaviour. “Customer unavailable” could reflect an actual absence, a missed telephone call or an address-access problem. The conversation should preserve both the reported reason and the customer's explanation.

Choose the event or recovery-case reference used to prevent duplicate processing. Store its current owner and whether a courier action is already pending. Calling from two teams about the same parcel can result in conflicting instructions.

Figure 01. Resolve the authoritative shipment state using its own reference.

Match the obstacle to an allowed action

Ask what prevented delivery and determine whether the courier can accept a useful next instruction. Use the carrier's actual rules for timing, address changes and remaining attempts.

Customer's response	Check	Record
I will be available tomorrow	Reattempt timing and carrier acceptance	Requested date and accepted result
The building entrance is elsewhere	Allowed delivery instruction field	Exact landmark or access correction
The address itself is wrong	Address-change permission and review process	Proposed change and reviewing owner
I received the parcel already	Latest delivered event or discrepancy process	Customer report and carrier evidence
I no longer want it	Cancellation/return policy for this shipment stage	Intent and actual system decision
I cannot discuss it now	Contact preference and remaining action window	One requested callback time

Do not promise an exact delivery slot unless the carrier supplies and confirms it. “Tomorrow was requested” and “tomorrow was accepted by the courier” should be separate states in both the conversation and the record.

When a customer changes the destination, read back the requested information and use the authorised process. A conversational correction does not automatically make a new address valid for the shipment.

Verify the courier update before closing the case

A carrier action usually has at least three useful states: requested, accepted and completed. Preserve each rather than converting every successful API response into “delivery resolved”.

If the update times out, look up its result using the available action reference before retrying. The carrier may have accepted the instruction even though your application did not receive the response. Duplicate requests can overwrite an earlier instruction or reopen work.

When no automated action is available, assign the case to a fulfilment owner with the conversation context. Give the customer an accurate next step, such as “our delivery team will review the address correction”. Do not announce a reattempt booking that exists only as a staff task.

Reconcile the final carrier event later. Delivered, returning and unresolved are distinct end states. Keep the customer explanation so the team can find recurring problems with a postcode, delivery route or reason code.

Figure 02. Keep rejected or unknown courier updates visible with an owner.

A worked failed-delivery call

This fictional example assumes the carrier allows an additional attempt but does not provide a guaranteed time window.

Assistant: Hello, this is the automated delivery assistant for Birch Store. We received a failed-delivery report for your parcel. Is this a suitable time to clarify the delivery instruction?

Customer: I was there. Driver called the old number. Kal delivery chahiye, but after lunch.

Assistant: I have noted that you were available and that the contact number needs review. I can request another attempt; the courier has not guaranteed an afternoon slot. May our delivery team verify the number change?

The record preserves a disputed failure reason, a requested day, an unconfirmed time preference and an authorised review task for the number. It does not claim that an afternoon delivery is booked.

Suggested fields include shipment reference, latest carrier event, reported failure code, customer explanation, requested instruction, action reference, carrier acceptance, owner and final delivery state. These describe a workflow model rather than a published Fonix API.

Review the exceptions before scaling

Situation	Required behaviour
Stale NDR arrives after delivery	Suppress the call and close the stale task
Order has multiple shipments	Identify the affected parcel explicitly
Courier rejects a reattempt	Preserve the rejection reason and assign review
Address correction crosses a service area	Use the carrier's approval path
Customer disputes the failure code	Store both accounts and investigate the operational issue
Update result is unknown	Reconcile before retrying or announcing success

Test event duplication and event ordering. A delivery update followed by an older NDR should not move the parcel backwards. Where the carrier does not supply a reliable ordering field, define how your system establishes the current authoritative state.

Measure delivered shipments and preventable returns

Track eligible NDR cases, useful contacts, accepted courier actions, completed reattempts, delivered parcels and return-to-origin outcomes for the same shipment cohort. Separate unreachable customers from rejected carrier requests and incorrect addresses.

Measure time from the failure event to a useful instruction, then from carrier acceptance to delivery. Fast calls alone do not prove recovery. A comparison with similar usual-process shipments or a controlled pilot helps distinguish calling effects from changes in courier service.

Include additional fulfilment, reattempt and support costs. Review returns and cancellations alongside delivered orders so a workflow does not optimise for activity while increasing operational expense.

Bring a real carrier event to the demo

Bring an NDR payload with personal information removed, your accepted carrier actions, state-reconciliation rules and fulfilment ownership process. Ask to see a stale delivered shipment, a rejected instruction and an uncertain update result.

Request a failed-delivery workflow review to test the call and resulting carrier record. Use the calling-software guide for broader integration and retry evaluation.

Building a COD confirmation voice workflow: order versions, retries and dispatch decisions

Programmatic DIB — Tue, 20 Oct 2026 07:13:18 +0000

Originally published as a Fonix.AI practical guide by AntEngage. This republication uses the same guide content.

Give dispatch an explicit order decision

COD confirmation calls ask a customer whether they intend to receive a cash-on-delivery order and give them a way to correct details or cancel before dispatch. Automation is useful when the result becomes a clear order-system decision. A customer answering the phone is not the same as confirming the order, and silence is not a cancellation.

Choose a defined point between order creation and your dispatch cutoff. Read the current order before calling, explain the store and order context, confirm intent, then save one of the agreed outcomes. Keep “confirmed,” “cancel requested,” “change requested,” “unreachable” and “needs review” separate.

Fonix.AI supports calling workflows for Indian businesses. Its D2C use-case page describes the order-confirmation context. The workflow below is a design and evaluation plan; confirm the read and write capabilities of your particular order-system integration during a demo.

Decide which orders should receive a call

Avoid calling every order through every channel by default. Select orders according to your store's confirmation process, contact preferences and dispatch timing. Exclude cancelled, already-dispatched, already-confirmed and otherwise ineligible orders. Recheck eligibility just before the call, because a queued job can become stale.

If customers already confirm through a configured message flow, the voice workflow should read that result before making another attempt. Agree one shared decision record across channels. Independent voice and messaging lists can otherwise ask the customer to confirm an order they already confirmed.

Store an order reference and version with the job. A phone number is not an order identifier: the same customer can place two orders, and a household can share a number. Select the intended order explicitly rather than updating the latest order found for that number.

Establish a cutoff owner. What happens to an unconfirmed order when the warehouse deadline arrives? Your operations team should define the hold, review or dispatch policy. The assistant should not invent that commercial decision from the customer's tone.

Confirm the order without asking for unnecessary information

Identify the store and automated assistant, explain the order context and establish whether you are speaking with the intended customer before discussing personal details. Read only the fields necessary for confirmation, following the store's approved identity and privacy process.

Use the current product summary, amount due and delivery details from the order source. Ask whether the customer wishes to receive the order. Repeat the decision plainly, especially when the answer includes a correction or hesitation.

Do not ask for an OTP, card details or payment credentials as part of a COD confirmation conversation. If a customer wants a different payment method, use the store's approved route and a human handoff when required. A spoken promise to pay does not prove successful delivery or payment.

Here is an illustrative call for a fictional store and an example order amount:

Assistant: Hello, I am the automated assistant for Willow Store about your recent cash-on-delivery order. Is this a suitable time to confirm it?

Customer: Haan. Lekin address mein flat number galat hai.

Assistant: You would like to correct the flat number before dispatch. I will follow the store's address-change process. Shall I record this as a change request rather than confirm the current address?

Customer: Yes, please change first.

This is a change request, even though the customer still wants the product. Saving it as “confirmed” would hide the problem from dispatch.

Use a decision table your warehouse can understand

Customer response	Suggested workflow state	Dispatch implication
Explicitly confirms the current order	Confirmed, after the update succeeds	Follow the store's release policy
Asks to cancel	Cancellation requested or cancelled, depending on permissions	Hold or review until the source system accepts the change
Requests a new address, size or quantity	Change requested	Apply the authorised edit process before release
Does not recognise the order	Needs review	Investigate the order and contact reference
Asks for a later call	Callback requested	Respect the requested time if it fits the cutoff policy
Does not answer	Unreachable	Follow the agreed attempt and dispatch policy
Gives an unclear answer	Needs review	Clarify once, then assign an owner

These states are recommendations, not a claimed Fonix API response format. Map them to the actual statuses your store uses. A connector with read access but no cancellation permission cannot truthfully promise that it has cancelled an order.

Figure 01. No answer is not cancellation. A requested change is not a saved edit.

Keep retries from overwriting a newer decision

Before writing a result, recheck order version, status and dispatch state. A customer may edit or cancel the order on the website during the call. If the record changed, refresh it and resolve the conflict under your team's policy.

Use an operation reference for each intended update. If a timeout leaves the result unknown, query that operation or the order status before retrying. Repeating the same write blindly can create duplicate tasks or overwrite a later customer action.

For an integration being designed, a useful rule is: apply the decision only if the order is still eligible and the expected version matches. If the order system cannot enforce that condition, agree a review mechanism that addresses the race. Discuss the available API behaviour with the team implementing the connection.

Record the attempted action and confirmed source-system result separately. An assistant saying “I have cancelled it” is not evidence of a successful cancellation. The final customer wording should follow the actual result, with a review request explained when completion is uncertain.

Figure 02. Same eligible version: update and verify. Changed version: reconcile.

Test the awkward cases before increasing volume

Test	Expected behaviour	Evidence to inspect
Two COD orders use one number	The intended order is selected	Order reference in the job and outcome
Customer changes address mid-call	A change request remains visible	Updated version and dispatch hold or review
Cancellation write times out	Check status before retrying	Operation reference and final state
Order dispatches while queued	Stop the pre-dispatch confirmation path	Fresh eligibility lookup
Customer confirmed on another channel	Avoid a redundant confirmation attempt	Shared confirmation state
Customer asks to stop calls	Apply the agreed contact preference	Suppression across later job creation

Also test amounts spoken in mixed language, product names that sound alike and a customer interrupting the address readback. The multilingual evaluation guide shows how to review critical fields rather than fluency alone.

Measure delivered outcomes without claiming every change as savings

Measure confirmation decisions before cutoff, manual-review completion, incorrect updates and order changes resolved before dispatch. Keep unreachable orders distinct from cancelled orders so the warehouse can see the actual workload.

For delivery analysis, follow a cohort of eligible COD orders from confirmation through dispatch and final delivery status. Calculate return-to-origin outcomes against the same dispatched cohort, and segment by campaign, product, service area and confirmation method where useful. A confirmation call cannot fix every logistics or delivery problem.

Compare equivalent periods or a well-defined pilot group. Include telephony, model use, integration work and manual review in the cost assessment. A reduction in calls handled by staff is not automatically a reduction in total operating cost.

Bring the dispatch policy into the demo

Bring a sample order, your current statuses, edit permissions, contact policy and cutoff rules. Request demonstrations of explicit confirmation, a changed address, a cancellation timeout and an already-dispatched order. Inspect the order system after each conversation.

Request a COD confirmation demo. For post-purchase enquiries, use the customer support voice workflow; for broader software evaluation, read the AI calling software guide.

I built a local work queue for Codex and Claude Code

Programmatic DIB — Mon, 19 Oct 2026 07:59:03 +0000

I had access to five ChatGPT Pro plans and three Claude Pro plans through referral offers. Ten days later, I had spent more time switching accounts and remembering which project I had left open than using the coding allowance. I wanted one place to describe work, let an available tool take the next step, and review what it actually produced.

That became Runquay: an MIT-licensed, local work queue for AI coding tools. It launches the official Codex, Claude Code, Gemini CLI, or Antigravity CLI on your computer. Runquay itself doesn't need a separate model API key or a hosted account. Your selected provider still handles the AI request under its own terms and billing.

The actual Runquay Create screen. The visible history is fictional demo data, so no private projects appear in the screenshot.

What happens after you type a request?

You can ask for a new project in plain language or choose an existing folder. Runquay saves the request, runs one bounded step at a time, and keeps the files and a checkpoint in that project's workspace. You can pause, inspect the result, ask for a change, or continue later. It can also find local sessions created in the original coding tools, so you can browse your work in one place while continuing to use those tools directly.

The distinction that matters to me is where continuity lives. If the next step runs on the same Codex or Claude profile, Runquay can resume that tool's native conversation. If work moves to another account or tool, it carries on from project files and a saved handoff. It does not transplant one account's private conversation or credentials into another account.

Here's an older, real Codex walkthrough: a request for a small fictional café website finished, and Runquay showed how to open and check the generated project.

A real completed Codex run, captured in an earlier Runquay interface. The café and its content are fictional.

Account switching has to respect the limits

For Codex, Runquay checks subscription quota before work and maintains a reserve. When one connected profile reaches that reserve, it can select another eligible profile. If none qualifies, the task waits for allowance to refresh. Paid credits and earned resets are separate decisions; Runquay will not silently use them.

Claude Code is different. Runquay cannot reliably check its subscription-versus-paid billing before a run. It asks for approval before every Claude invocation. If Claude Code explicitly returns a usage-limit error, Runquay can select another connected Claude profile, then asks again before that profile runs. An ambiguous error is not treated as permission to switch or retry.

You can connect as many profiles as you need, but Runquay uses one worker at a time. Extra profiles do not increase a provider's allowance, and you should use only accounts you control under the provider's rules. Gemini CLI, Antigravity CLI, and custom tools can join the queue; their billing remains unverified, so each run needs approval, and their accounts do not yet rotate automatically on errors.

The useful part beyond the queue

Work across projects can teach you things worth keeping. Runquay's Collective Learnings brings matching local work summaries together, then lets a connected AI analyze the selected context when you ask it to. You can review sources, remove a summary you don't want to send, save useful lessons, and attach a lesson to later work. The topic display starts with local matches; it is not claiming that an AI has already drawn conclusions just because the page opened.

The actual Learn screen with fictional summaries. Analysis begins only after the user chooses it.

Getting started, and what's still unverified

The latest release has guided installers for Windows and macOS/Linux. Sign in through each vendor's official flow, choose a folder, and describe the first task. The beginner guide walks through the screens without assuming you know how to code.

Real Codex and Claude project runs have been tested on Windows. Automated checks run on Windows, macOS, and Linux, but native vendor runs on macOS and Linux still need hands-on testing. Two-account switching has been exercised in an isolated sandbox with CLI stand-ins; I have not yet observed a live switch between two real vendor accounts. The verification record separates those checks from live provider tests.

The source, setup instructions, and issue tracker are at github.com/dibyapp/runquay. If you try it, I'd especially like to hear where setup, approvals, or handoffs are confusing or fail in practice. Concrete bug reports and contributions are welcome.

Disclosure: AI helped draft this article. Product claims were checked against the linked public source and verification notes.

Designing an admissions voice workflow: parent handoff, course facts and counselling

Programmatic DIB — Sun, 18 Oct 2026 07:45:53 +0000

Originally published as a Fonix.AI practical guide by AntEngage. This republication uses the same guide content.

Make the next counselling conversation useful

AI calling for admissions helps an education team respond to course enquiries, clarify what a student or parent needs and connect them with a counsellor. A useful first call leaves a course reference, speaker role, preferred language and agreed next step. It should not make an admissions decision or invent a fee, scholarship or seat guarantee.

Choose one enquiry flow before launching a campaign. For example, handle requested callbacks about one course and offer a counselling slot when suitable. Keep retention calls, payment discussions and admissions follow-up as separate workflows: they have different purposes and different information requirements.

Fonix.AI supports Indian-language voice conversations and follow-up campaigns. The EdTech use-case page provides industry context. Here the focus is a testable enquiry workflow, including the source record, counsellor booking and exceptions your admissions team needs to own.

Separate an enquiry from an enrolment decision

An enquiry form is not proof that the person wants to enrol immediately. Read the requested course, campus, intake and contact preferences before deciding what to ask. Use an enquiry reference to preserve the distinction between several programmes requested by one household.

Resolve duplicate imports and identify any active counsellor assignment. If an admissions team is already handling the case, follow its ownership policy instead of creating a second appointment. A prompt follow-up can be useful; repeated uncoordinated calls can make the experience worse.

Open by identifying the institute and the automated assistant, stating the requested course and asking whether the person can speak. When the recipient does not recognise the enquiry, record that result and stop. Use the institution's approved contact policy for timing, attempts, recording and preferences; review that policy with the appropriate internal owners before launch.

Identify who is speaking and what they need

A course enquiry may be answered by the prospective student, a parent or another person using the same phone. Ask who is speaking before discussing personal enquiry details. If the speaker changes during the call, establish the new role and preferred language again.

Keep the first-call questions small and relevant. Course interest, intended intake, mode of study, preferred campus and a suitable counselling time usually provide more useful context than a long generic sales questionnaire. Only collect information required for the agreed task.

Information	Useful question	Result to preserve
Speaker	Are you the prospective student or calling on their behalf?	Stated role; do not infer from voice
Programme	Which course or batch did you enquire about?	Exact programme reference or unresolved choice
Intake	When are you planning to start?	Stated intake or exploratory interest
Mode or campus	Which location or learning format suits you?	Preference and acceptable alternatives
Next step	Would a counsellor conversation help?	Accepted appointment or callback preference

If the learner is a minor, use the institution's approved process for involving a parent or guardian and handling personal information. The assistant should not improvise consent or eligibility rules. This guide defines an operational workflow; legal requirements need review for the actual institution and deployment.

Figure 01. A parent's preference should not silently replace the student's.

Use a current course source and a real counsellor calendar

Make the approved course catalogue the source for programme descriptions, published fees, intake dates, delivery format and official contact routes. Assign an owner and update time. A course PDF from the previous intake should not become the basis for a new fee quote.

Distinguish providing published eligibility information from determining whether a student qualifies. A counsellor or admissions team should review individual qualifications, document issues, financial concerns and exceptions. The assistant can capture the question without offering a decision.

When counselling booking is configured, retrieve genuine slots and confirm the programme, campus or call format, date, time and speaker. Announce the appointment after the system accepts it. If the connection only creates callback tasks, explain that a counsellor will receive the request under the agreed process.

Map programme and language to a counsellor queue explicitly. Test what happens when the appropriate counsellor is unavailable. An appointment with the wrong programme owner is a completed system write but an unsuccessful workflow.

Figure 02. Match the counsellor queue, then reserve and verify the appointment.

A conversation that changes speaker

This illustrative call concerns a fictional institute and does not represent a student recording or a measured customer result.

Assistant: Hello, I am the automated assistant for Maple Learning. This is about a data analytics course enquiry. Am I speaking with the person who submitted it?

Student: Yes. Weekend batch chahiye. Fees ke liye mummy se baat kar lo.

Assistant: I have noted the weekend preference. Please let me know when your parent is on the line so I can confirm who I am speaking with.

Parent: Haan, main bol rahi hoon. Hindi mein bataiye.

Assistant: Namaste. Main institute ki automated assistant hoon. Aap published fee information chahte hain, ya counsellor ke saath discussion schedule karna chahenge?

The record should reflect the speaker change and the parent's language preference. It should not assume the parent's questions are the student's study preferences. Record any fee question for the counsellor, using the current approved information where available.

Design the exceptions before peak enquiry season

Situation	Useful response	What to test
Course name is ambiguous	Ask a short clarification	Similar course names do not select the wrong intake
Parent takes over	Confirm role and language again	Conversation context stays accurate
Requested intake is closed	Explain the approved status and offer a counsellor	No invented seat availability
Fee source is outdated	Route the question with the source reference	No improvised quote or discount
Counsellor calendar is unavailable	Create an owned callback under the agreed process	No false appointment confirmation
Caller requests no more contact	Apply the preference before another attempt	A later import does not restart the sequence
Caller raises distress or a personal concern	Hand over through the institution's process	It does not become a sales objection

Test interruption, a parent joining halfway through and the same contact appearing twice in the input list. Have counsellors review the saved records to see whether they can begin the next conversation without repeating every question.

Score counselling outcomes rather than calls placed

Track eligible enquiries, conversations with the intended household, counselling requests, confirmed appointments, attended appointments and completed callbacks. Keep opt-outs, wrong contacts and duplicate records visible rather than hiding them inside a conversion total.

Compare attendance among booked appointments and attendance among eligible enquiries. Review programme and language separately, because a strong aggregate can conceal a failing intake or caller group. Count the time from enquiry creation to a useful conversation, distinguishing a ringing attempt from an actual response.

Enrolment may be a later business outcome, but it also depends on course suitability, counselling quality, pricing and the student's decision. A pilot should not attribute every enrolment change to automation. Agree the measurement period, source mix and follow-up window before comparing results.

Run a demo with the admissions team's real questions

Bring one course enquiry, current programme information, counsellor schedules and the questions parents actually ask. Request a normal booking, a speaker change, a closed intake and a failed calendar write. Verify that each result reaches the correct queue.

The multilingual voice evaluation guide helps test the names, course codes and language changes that matter here. The calling software guide covers the broader enquiry pipeline and integration questions.

Request an admissions follow-up demo. Keep the first pilot narrow enough that the counsellors can review every exception and decide what is ready to expand.

Building a voice lead-qualification workflow that sales can actually use

Programmatic DIB — Wed, 14 Oct 2026 08:16:00 +0000

Originally published as a Fonix.AI practical guide by AntEngage. This republication uses the same guide content.

What makes a lead useful to sales?

An AI lead qualification voice agent should help a salesperson understand a business enquiry and decide the next conversation. A useful result includes the buyer's stated need, unresolved questions, the appropriate sales owner and an agreed next step. A connected call or an automatically assigned “hot” label does not establish that the opportunity is suitable.

This guide focuses on B2B product and service enquiries, such as a demo request. Property visits and student counselling have different requirements; use the dedicated real estate and admissions guides for those workflows.

Fonix.AI supports inbound and outbound business conversations in Indian languages. Evaluate the conversation alongside your enquiry and sales systems. Confirm the required CRM, calendar and routing connections for your deployment rather than assuming that a particular connector is available.

Start from the enquiry and its current owner

A form submission is an event, not a complete customer identity. Preserve its source, timestamp, enquiry reference, product interest and contact preferences. The same telephone number can appear on several enquiries, and a company can have several people evaluating the same purchase.

Resolve the enquiry against the current CRM before calling. If an account manager already owns the conversation, follow that ownership rule. A fresh demo form should not cause an independent automated follow-up to compete with an active salesperson.

Decide how you handle duplicate form events, people who request a later callback and records that no longer require contact. A durable enquiry reference and a single active outreach task make it easier to prevent several agents from calling the same person simultaneously.

Open with the business identity, explain that the caller is an automated assistant, refer to the actual enquiry and ask whether it is a suitable time. When the person does not recognise the request, capture that response instead of continuing a qualification script.

Capture requirements without manufacturing certainty

Ask questions because their answers change the next step. A short, relevant conversation is more useful than completing a framework at all costs.

Question	Useful evidence	Keep separate
What problem are you trying to solve?	The buyer's own description and current process	Your interpretation of urgency
Which team would use the product?	Functions, approximate usage and workflow	An inferred company-wide rollout
What must the solution connect to?	Named systems and required actions	A promise of integration availability
When would you like to evaluate it?	A stated date or an undecided timeframe	A guessed buying deadline
Who should join the next conversation?	The requested participants	A judgement about decision-making authority

Budget can be useful when it determines whether a proposal is relevant, but an unanswered budget question should remain unanswered. “We need to understand the solution first” is not evidence of a low-quality buyer.

If you use a qualification score, document the criteria and expose the answers behind it. Keep the transcript, stated fields, derived score and human decision as separate records. A salesperson should be able to challenge a score without reconstructing the whole conversation.

Test corrections and mixed-language answers. “Twenty users now, maybe two hundred later” must not become a current requirement for two hundred seats. The multilingual evaluation guide explains how to review critical fields.

Figure 01. Derived scores must remain traceable to the stated criteria.

Route the next step and verify acceptance

Use the captured requirement and your approved territory, product and account rules to choose a destination. The appropriate result might be a demo, a technical discussion, a later callback or an answer to an initial question.

When booking a demo, check current availability, agree on an exact time and verify the scheduling write. When assigning a callback, record the receiving owner and requested time. Say that a callback was requested until your process establishes who accepted it.

Pass the buyer's original question, relevant answers, unknowns and contact preference. A summary saying “interested in product” creates work for the next salesperson; a brief explaining the current process and requested integration lets them start with a meaningful answer.

Keep the lead's qualification status distinct from its outreach status. “Not reached” does not mean “not suitable”, and a successful calendar write does not mean the prospect attended the demo.

Figure 02. Record the accepted next step against one current enquiry owner.

A worked B2B enquiry

The following conversation is illustrative and describes a fictional business.

Assistant: Hello, this is the automated assistant for Acorn Software. You asked about a demo for your support team. Is now a suitable time?

Buyer: Haan, but we only need inbound support. Sales calling nahi chahiye.

Assistant: Understood: inbound support, without a sales-calling requirement. Which system holds your customer cases?

Buyer: Our own portal. API hai, but engineering needs to review access.

Assistant: I will include that in the technical discussion request. Would you like your engineer to join the demo?

The resulting brief should record inbound support as the scope, a custom portal as a dependency and engineering review as an open condition. It should not declare the integration ready or infer a confirmed rollout.

A suggested record contains the enquiry reference, account reference, stated problem, current system, requested participants, unanswered questions, next-step preference and sales owner. If a slot is booked, add its confirmed reference. These are workflow design fields, not a published Fonix API contract.

Test the cases that break the happy path

Situation	Expected response	Evidence to retain
Duplicate form arrives during a call	Merge or suppress according to the enquiry policy	Both event references and active task
Buyer already spoke to an account manager	Respect current ownership	Existing owner and latest contact
Required integration is unconfirmed	Record the requirement for review	System name and exact action requested
Calendar write times out	Check its result before trying again	Attempt reference and desired slot
Buyer corrects company size or timing	Update the stated field and read it back	Correction and final accepted value
Buyer declines further contact	Close the flow through your contact-preference process	Preference and affected enquiry

Include these cases in a demonstration. A fluent conversation can still produce a duplicate lead, an unsupported promise or an unowned callback. Review the written result as well as the audio.

Measure accepted handoffs and attended demos

Track eligible enquiries, attempted contacts, useful conversations, accepted sales handoffs, confirmed demos and attended demos for the same cohort. Define eligibility before the pilot so the denominator does not change when results look weak.

Review a sample of briefs for field accuracy, preserved uncertainty and correct ownership. Ask salespeople whether they could act on the record without asking the buyer to repeat the conversation. Compare accepted opportunities by enquiry source; a different campaign mix can change results independently of the calling workflow.

Measure response time from the original enquiry event and report its distribution. An average can hide a queue in which a few buyers wait a long time. Compare equivalent operating periods and keep a baseline or holdout where practical.

Bring one enquiry source to the demo

Bring a sample demo request, your qualification questions, account-ownership rules and the resulting CRM fields. Ask to see a duplicate enquiry, an undecided buyer and a booking that fails after agreement.

Use the calling-software guide for platform selection and the missed-call guide for unanswered inbound enquiries. Request a lead-to-demo workflow review to evaluate your language mix, integrations and sales handoff.

How to Transfer Files from PC to iPhone over Wi-Fi

Programmatic DIB — Sun, 11 Oct 2026 08:31:31 +0000

You have a PDF, a ZIP archive, or a video on your computer. You want it on your iPhone. The devices are on the same Wi-Fi, but getting that file across can still involve a cable, an account, or a cloud-upload step.

I built PC to iPhone Share for a smaller workflow: choose one computer folder, open it in your phone's browser, and download what you need directly over the local network.

It is MIT licensed, written in Go, and download-only. Windows, macOS, and Linux host the server; iPhone, iPad, and Android devices use their browsers.

There is one setup step worth understanding before you download it: the phone needs to be paired with the computer's local HTTPS certificate. This is an unsigned alpha, and that pairing is manual.

What the transfer looks like

The computer serves the selected folder over HTTPS. Safari opens the file browser after you sign in with the generated share password. Tapping a filename starts a browser download.

Selected computer folder
          |
          | HTTPS on your local network
          v
Phone browser -> sign in -> choose a file -> download

The running app does not upload files to a cloud service, use a relay, or require a phone app. You do need internet access initially to download the release or build tools.

Actual interface with synthetic screenshot data. This is a browser capture, not a physical iPhone screenshot. It contains no real shared folder, password, or network address.

Download the portable app for your computer

The v0.1.0-alpha.1 release includes six portable builds:

Computer	Processor choices	Archive
Windows	Intel/AMD x64 or ARM64	ZIP
macOS	Intel x64 or Apple Silicon ARM64	ZIP
Ubuntu and Linux	x64 or ARM64	TAR.GZ

Choose the archive for the computer hosting the folder, rather than for the phone receiving files. Ubuntu uses the Linux build; an ARM64 computer needs the ARM64 archive.

The packaged executables include the web interface. You do not need Go, Python, or Node installed to run them. These are portable console programs, not App Store packages or automatically installed background services.

Download SHA256SUMS alongside the archive and compare the checksum for its exact filename. The installation guide includes Windows, macOS, and Linux checksum commands. A matching checksum verifies the downloaded bytes against the release manifest; it is not an independent publisher signature.

Transfer files from Windows PC to iPhone: the first download

1. Extract and start on the computer

Extract the ZIP before running it. On Windows, start Start-PC-to-iPhone-Share.cmd or pc-to-iphone-share.exe.

Choose a dedicated folder containing only the files you intend to share. Keep the app and its private settings outside that folder. Select the actual private Wi-Fi or LAN interface reachable by your phone.

The console prints a local management dashboard URL. Open that on the computer. It contains the setup details and the generated share password; keep the management URL private.

2. Pair the iPhone with your local certificate

Join the same reachable network on the iPhone. Use the separate phone URL displayed in the dashboard.

A private network address does not automatically have a publicly trusted HTTPS identity. The app creates a local certificate authority for the installation, and the receiving device needs to trust its public certificate.

Verify the certificate fingerprint against your computer's dashboard through a trusted channel. Install only your own computer's public certificate profile. On iPhone or iPad, manually installed certificates also require enabling trust under Settings -> General -> About -> Certificate Trust Settings.

Follow the project's certificate pairing guide. Apple documents the manual certificate trust step separately. Trusting the certificate on your computer does not pair the phone for you.

3. Sign in and download in Safari

Open the exact HTTPS phone URL, enter the generated share password, and tap a file. Use the app's share password, not your Windows account password.

Check Safari's download manager or the Files app for the downloaded file. Downloading a photo archive or music file does not automatically import it into Photos or Music.

Keep the computer awake and the app running until the transfer finishes. When you are done, use Stop sharing in the local dashboard or stop the console process with Ctrl+C.

Can I transfer files from Ubuntu to iPhone too?

Yes: the same browser-download workflow uses the Linux host. Extract the matching TAR.GZ archive and run the binary from a terminal:

./pc-to-iphone-share --version
./pc-to-iphone-share

Choose the folder and private interface, then complete certificate pairing on the receiving device. The shipped Linux binaries disable cgo and do not require a dynamically linked C runtime.

WSL deserves a separate note: a successful Linux test inside WSL does not prove that an iPhone can reach it through Windows networking. If the files are hosted on a Windows PC, the Windows executable avoids that extra network layer. Physical Linux desktop reachability and firewall behavior still need checking on the network you use.

Android is also a browser client. User-certificate installation and browser trust vary across devices, especially on managed phones; the documented pairing requirements still apply.

If Safari cannot connect

Certificate warning: complete pairing on the iPhone itself and verify the fingerprint. Trust on the desktop does not transfer to the phone.
Page cannot be reached: check that the computer is awake, the app is running, and you selected the correct interface. Guest Wi-Fi can isolate clients even when both devices show the same network name.
Cross-site requests blocked: open the dashboard's separate phone URL directly in Safari, then sign in there. Use the exact HTTPS origin; do not embed the private APIs in another site or disable browser privacy protections.
Firewall block: review a narrowly scoped allowance for the selected interface, subnet, and port instead of switching the firewall off.

The troubleshooting guide covers these connection and download issues.

Why a small Go file server?

I wanted the host to be easy to download, inspect, and stop. The app uses Go's standard library, embeds its web assets, and has no third-party Go module dependencies.

Its narrow scope makes the controls easier to describe:

One selected folder: file access uses Go's os.Root plus application checks for invalid names, traversal, and linked paths. This is not a promise of isolation from administrators, hard links, or mounts.
Read-only operations: the receiving browser cannot upload, delete, rename, or edit files through the app.
Password and sessions: the generated password is stored as a salted PBKDF2-HMAC-SHA256 hash. Browser sessions use Secure, HttpOnly, SameSite=Strict cookies, with expiration and login throttling.
Separate management: the dashboard is loopback-only and token-protected. Its URL belongs on the host computer, not in a shared message or screenshot.
Direct downloads: files are streamed and support HTTP byte ranges. Browser behavior, free storage, network conditions, and filesystem limits still determine what a transfer can handle.

The server binds the selected private IPv4 interface and checks peers against its subnet. That check limits its network scope; it does not prove physical Wi-Fi membership. The app does not configure router forwarding, UPnP, firewall rules, or certificate trust automatically.

The security document spells out the trust boundaries. There is no independent security audit claimed for this alpha.

What has actually been tested?

Native CI for this release passed on seven runners: Windows x64 and ARM64, Intel and Apple Silicon macOS, Ubuntu 22.04 and 24.04 x64, and Ubuntu 24.04 ARM64.

The automated checks include verified HTTPS, unauthenticated access rejection, password sign-in, download integrity, byte ranges, cross-site API rejection, and management isolation. The public Windows and Ubuntu installer flows were also checked against the published assets.

Those checks do not replace physical phone, certificate-pairing, and real Wi-Fi tests. The release is unsigned and unnotarized. IPv6-only networks, 32-bit hosts, remote internet sharing, synchronization, and phone-to-computer uploads are outside this version's scope.

Build from source and help improve it

If you prefer to inspect and build the source, install Go 1.26 and run:

git clone https://github.com/dibyapp/pc-to-iphone-share.git
cd pc-to-iphone-share
go test ./...
go vet ./...
go build -trimpath -buildvcs=false -o pc-to-iphone-share .
./pc-to-iphone-share --help

On Windows, use -o pc-to-iphone-share.exe and run .\pc-to-iphone-share.exe --help instead.

This project is useful when you want to browse and download one computer folder on your phone without a cloud-upload step. For broader device-to-device transfers, remote transfers, or uploads, other tools may fit better.

The source and downloads are on GitHub: PC to iPhone Share. If you try it, I would value feedback on installation, certificate pairing, and platform compatibility. Use synthetic examples in public issues and keep real filenames, addresses, passwords, and certificates private. If it solves your folder-download problem, a star helps other people discover it.

Planning on-premise voice AI: dependency boundaries, capacity and recovery tests

Programmatic DIB — Sat, 10 Oct 2026 10:52:54 +0000

Originally published as a Fonix.AI practical guide by AntEngage. This republication uses the same guide content.

Define what must stay inside the deployment

On-premise voice AI runs the agreed conversation components on infrastructure an organisation controls. The important purchasing question is which components are included and what dependencies remain outside that boundary. Hosting a language model locally does not by itself establish where telephony, speech processing, transcripts, tool calls or monitoring run.

Fonix.AI offers cloud and on-premise deployment. AntEngage's technology overview describes its conversation architectures. This guide provides a deployment worksheet and acceptance plan so your infrastructure and operations teams can evaluate the actual proposed system.

Start with one business task and a diagram of its entire path. State the required boundary in concrete terms: model execution, audio processing, transcript storage, business systems, operator access and permitted external connections. Have the relevant internal teams agree that scope before hardware sizing or procurement.

Map the whole call path, including dependencies

Separate the customer-facing phone network from the application and model environment. A system answering ordinary telephone calls has a telephony path; describe how that path reaches the deployment instead of using “offline” as an undefined promise.

For each component, record location, data received, data retained, permitted outbound connections and its owner. Include less visible services such as logs, crash reports, licence checks, package downloads, backup storage and remote support. These can matter as much as the primary model endpoint.

Component	Questions to answer	Acceptance evidence
Telephony ingress and egress	Which provider, trunk and network route carry audio?	Documented route and a tested call
Speech and conversation models	Which stages execute locally? Is any hosted inference used?	Runtime inventory and observed connections
Business tools	Which CRM, calendar or account APIs are called?	Allowed endpoints, permissions and test results
Record storage	Where are audio, transcripts and outcomes stored?	Storage locations, access roles and deletion process
Observability	Where do logs and diagnostics go?	Logging configuration and inspected outbound destinations
Updates and support	How do releases and support sessions enter the boundary?	Approved update and access process

Distinguish required external business services from accidental dependencies. If a CRM is hosted elsewhere, a locally hosted voice system may still call it. The system design should make that connection explicit rather than imply that local inference moves every business record on-premise.

Figure 01. Document every dependency, not only where the model runs.

Choose the conversation architecture for the task

Discuss whether the deployment uses a speech-to-text, reasoning and speech-synthesis pipeline, a direct speech-to-speech path or another supported configuration. Ask how each option handles business actions, language coverage, transcript creation, interruption and recovery.

For a transactional task, the architecture needs more than natural audio. It must obtain the right system record, perform an authorised action, detect its result and preserve enough context for a handoff. Review where those decisions happen and which component owns state.

If a third-party or internally selected model is proposed, document its hosting and resource requirements separately. Do not assume that changing the reasoning model leaves language quality, latency or capacity unchanged. Run the target workflow on the exact configuration being considered.

The multilingual evaluation guide supplies a task-based test design. Use it alongside infrastructure tests so a deployment that meets a network boundary also proves that it can perform the intended conversation.

Size for concurrent conversations and peak bursts

Monthly call minutes help estimate usage, but they do not establish the required real-time capacity. Capture peak simultaneous calls, arrival bursts, typical duration, language mix and the business actions each conversation requires.

A simple illustrative load calculation is: if 120 calls arrive uniformly over ten minutes and each lasts two minutes, the average offered concurrency is about 24 calls. That is a planning example, not a hardware recommendation or a Fonix capacity claim. Real arrivals are uneven, and provisioning requires measured performance and headroom.

Ask for benchmarks on the proposed hardware, model versions and telephony configuration. Review end-to-end response timing, dropped connections, tool latency, resource use and capacity at the target peak. Record what happens when load exceeds the agreed limit: queue, busy treatment, transfer or another defined fallback.

Confirm whether capacity is shared with chat, campaigns or other workloads. A successful quiet-hour demonstration does not establish behaviour while outbound campaigns and inbound support calls run together.

Figure 02. Measure peak bursts, tool latency, recovery and shared workloads.

Assign operating responsibilities before launch

Agree who owns application releases, model updates, operating-system patches, certificates, backups, capacity monitoring and incident response. List the vendor's responsibilities and the customer's responsibilities in terms operators can use during an outage.

Define access roles for recordings, transcripts, configuration and business-tool credentials. Decide how changes are reviewed, how access is removed and which audit records are available. Specify retention and deletion processes for each stored artefact rather than treating every log like a call recording.

For restricted networks, agree how software packages and model artefacts arrive, how they are verified, and how an unsuccessful update is rolled back. Check whether setup, licensing or normal operation needs connectivity beyond the permitted routes.

Local hosting is an architectural choice. It does not automatically establish compliance with every law, certification or sector policy. Evaluate those requirements against the proposed data flow and operating process with the appropriate internal reviewers; avoid accepting a product badge as the whole assessment.

Write a failure and recovery plan you can demonstrate

Failure	Required decision	Evidence from the test
Model worker stops during a call	Continue through the supported recovery path or provide fallback	Customer experience and final record
Business-system lookup is unavailable	Avoid an invented answer or action result	Tool error and explicit unresolved outcome
Storage becomes unavailable	Follow the agreed recording and task policy	Alert, handling behaviour and recoverability
Telephony connection drops	Determine whether the action completed before another attempt	Call reference and source-system state
Demand exceeds capacity	Apply the defined admission or fallback behaviour	Queue, transfer or busy response under load
Release fails	Roll back through the agreed process	Restored version and repeat acceptance result

Review the cases with operations staff. A recovery plan should state who receives the alert, what they can inspect and how they restore service. “Contact support” is incomplete if support cannot reach the environment under its access policy.

Where an action result is unknown, keep it unknown until the source system is checked. The same principle applies to local and hosted deployment: a timed-out booking write must not become a confident spoken confirmation.

Make acceptance a joint review

Use a controlled evaluation environment and the actual intended hardware and network rules. With your team's approved monitoring tools, observe the configured destinations during normal calls, failures, restarts and updates. Record the model and application versions alongside the results.

Combine the dependency inventory, peak-load test, representative language calls, tool permissions and recovery demonstrations into one acceptance record. Set thresholds and evidence requirements before the demonstration, based on the business task and operational risks.

Compare deployment costs over the same period and scope. Include hardware, redundancy, infrastructure staff, support, telephony, updates and integration operation. Keep assumptions explicit; a smaller hosted subscription and an on-premise first-year purchase are not directly comparable without a shared workload model.

Scope your boundary with the Fonix team

Bring your data-flow diagram, telephony setup, peak concurrency, required languages, existing infrastructure and recovery expectations. Ask for a concrete architecture and an acceptance demonstration rather than a generic statement about local hosting.

Discuss an on-premise Fonix deployment. The calling software guide covers workflow and integration evaluation; this page focuses on the hosting boundary, capacity and ongoing operation of that workflow.

Claude for Startups 2026: $1,000 in API Credits, a Free Year of Claude Team with Claude Code

Programmatic DIB — Wed, 07 Oct 2026 17:07:47 +0000

Anthropic expanded its Claude for Startups program on 6 October 2026. If your company is young enough to qualify, you can get API credits, a free year of Claude Team with Claude Code and Fable 5.1, and a stack of partner perks from one short application.

I went through the program page, the official terms and the pricing docs. Below is what you actually get, the catches that trip people up, and (the part most write-ups skip) how to stretch the credits with prompt caching and the Batch API.

📖 The full guide, with every partner offer and a step-by-step walkthrough, lives on StartupReader: Claude for Startups: how to get $1,000 in API credits and a free year of Claude Team

TL;DR: what you get

Benefit	Details
$1,000 in Claude API credits	One-time, used through the Claude Console. Expires 6 months after it's granted.
A free year of Claude Team	Up to 5 Premium seats, for companies new to Team. Every seat includes Claude Code and Claude Fable 5.1. List price is $100/seat/month on annual billing, so it's worth up to $6,000.
Claude Startup Stack	Up to $45K in partner offers, redeemed with codes in the Console.
VC partner credits	Up to $100K more in API credits if your investor is in Anthropic's VC partner network.
Office hours	45-minute live sessions with Anthropic's Applied AI team, every other week.
Events	Founder House, hackathons and meetups (space is limited).

Anthropic puts the Claude products and credits at up to $7,000 in value: five Premium seats at $100 a month for a year, plus the $1,000 in credits.

What's in a Premium seat

Claude Code is included with every Team seat.
Claude Fable 5 and 5.1 are part of Premium seats. Fable can use up to 50% of your weekly usage limit at no extra cost (Anthropic's plan article). In Claude Code, Fable 5.1 needs version 2.1.255 or later.
5× the usage of a standard Team seat.
It's the Team plan, not the individual Max plan. Max is a separate subscription.

Who qualifies

Founded in the last 5 years, or funded in the last 2
Any stage: bootstrapped, pre-seed and VC-backed companies can all apply
A Claude Console account
A company email on the same domain as your website
A short description of what you're building

Gotchas worth knowing before you apply

Gmail won't cut it. Your email domain should match your company website.
The clock starts at grant. Credits expire six months after they're granted, so apply when you're about to build, not months before.
First-party API only. The credits are for the Claude API through the Claude Console. Claude usage on Amazon Bedrock or Google Cloud Vertex AI isn't covered.
Team year = new Team customers. If you already pay for Claude Team, that part won't apply.
Some regions are excluded. Per the official terms: Belarus, China, Cuba, Iran, Myanmar, North Korea, Russia, Sudan, Syria, and the Crimea, DPR and LPR regions of Ukraine.

How to apply, step by step

Check eligibility (founding/funding window, live website, supported region).
Sign in to the Claude Console with your work email.
Fill in the startups application: company details plus a short, concrete description of who your product is for and where Claude fits.
Wait for a decision. Most are decided within minutes; the rest go to manual review, which usually takes 2–3 business days.
Redeem your offers. Credits are used through your Console organisation; Startup Stack codes are redeemed in the Console.
Set a spend limit, then build.

The Claude Startup Stack

These were the named partner offers when I checked. They can change, so the Console has the live list.

Partner	Offer
Attention	20% off the first year
Augment Code	$100 in Cosmos credits
ClickHouse	$5K in ClickHouse Cloud credits
ElevenLabs	12 months free + 33M characters
Emergent	20% off the first 6 months
Firecrawl	2.5× monthly credits for a year
Gamma	25% off the first year
Granola	3 months free, up to 10 seats
Hex	6 months of Enterprise, free

How far does $1,000 actually go?

Model choice is the biggest lever. Here's the arithmetic for a typical request of 2,000 input + 500 output tokens at list prices (per million tokens):

Model	Input	Output	Requests per $1,000
Claude Haiku 4.5	$1	$5	~222K
Claude Sonnet 5	$2	$10	~111K
Claude Opus 5.5	$4	$20	~56K
Claude Opus 5	$5	$25	~44K
Claude Fable 5.1	$10	$50	~22K

Two things jump out: output costs 5× input on every model, and Opus 5.5 lists below Opus 5, so check before you default to the older one.

For scale, Anthropic's pricing docs estimate about $37 per 10,000 customer-support conversations on Haiku 4.5. That works out to roughly 270,000 conversations for your $1,000.

Lever 1: prompt caching (cache reads cost 0.1× the input price)

If every request resends the same long system prompt, tool definitions or document, cache it. Here's the worked example from the guide, on Sonnet 5 with a 20,000-token system prompt, 1,000 fresh input tokens and 500 output tokens:

Setup	Cost per request	Requests per $1,000
No caching	$0.0470	~21K
Prompt caching (cache hit)	$0.0110	~91K
Caching + Batch API	$0.0055	~182K

(Leaves out the one-off cache write, billed at 1.25× the input price for the default 5-minute cache.)

With the TypeScript SDK, the simplest option is top-level cache_control, which caches the last cacheable block automatically:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic(); // reads ANTHROPIC_API_KEY

const response = await client.messages.create({
  model: "claude-opus-5",
  max_tokens: 16000,
  cache_control: { type: "ephemeral" }, // auto-caches the last cacheable block
  system: LONG_STABLE_SYSTEM_PROMPT, // keep this byte-for-byte identical between calls
  messages: [{ role: "user", content: userQuestion }],
});

// Verify the cache is actually working:
console.log(response.usage.cache_creation_input_tokens); // written to cache (~1.25x)
console.log(response.usage.cache_read_input_tokens); // served from cache (~0.1x)
console.log(response.usage.input_tokens); // uncached (full price)

Three things that silently break caching:

Anything dynamic in the prefix. A timestamp or request ID in the system prompt changes the prefix on every call, so every call misses. Put volatile content after the stable part.
Prefixes below the minimum. Each model has a minimum cacheable length: 512 tokens on Opus 5, 1,024 on Sonnet 5, 4,096 on Haiku 4.5. Shorter prefixes don't cache, and there's no error.
Never checking usage. If cache_read_input_tokens stays at 0 across identical requests, something in your prefix is changing.

Lever 2: the Batch API (50% off, stacks with caching)

Evals, backfills, nightly enrichment: anything that doesn't need an answer in real time should go through Message Batches. It costs half the normal price, and most batches finish within an hour.

const batch = await client.messages.batches.create({
  requests: items.map((item) => ({
    custom_id: item.id,
    params: {
      model: "claude-opus-5",
      max_tokens: 1024,
      messages: [{ role: "user", content: item.prompt }],
    },
  })),
});

Lever 3: guardrails

Start with the smallest model that passes your eval, and move up only for the steps that fail.
Cap max_tokens and ask for concise output formats, because output is the expensive side.
Set a spend limit on your Console workspace on day one. A retry loop with a bug can burn through $1,000 overnight.

Apply

👉 Apply on the Claude Console

📖 Read the full guide on StartupReader: eligibility checklist, every partner offer, the step-by-step application and an FAQ.

StartupReader is independent and isn't affiliated with or paid by Anthropic. Facts checked against Anthropic's program page, announcement, official terms and pricing docs on 7 October 2026. Terms can change, and the Console application is the source of truth.

Building something with Claude? List your startup on StartupReader. It's free after a human review.

Evaluating multilingual voice agents: code-switching, critical fields and task completion

Programmatic DIB — Tue, 06 Oct 2026 07:37:08 +0000

Originally published as a Fonix.AI practical guide by AntEngage. This republication uses the same guide content.

Evaluate the task, not just the language list

A multilingual voice bot for India must do more than greet callers in several languages. It needs to understand the words that determine the task: a corrected appointment date, a doctor name, a locality, an amount or a request for a person. The useful question is whether it completes that task correctly for the language mix your callers actually use.

Fonix.AI supports 14+ Indian languages and code-switched conversations. Coverage is a reason to test representative calls, not evidence that every accent, phrase or noisy phone connection will perform equally. Ask for a demonstration using your business vocabulary and critical fields.

This page provides a practical evaluation design. It does not invent a Fonix accuracy score or a competitor ranking. The examples are test cases, and the scorecard below is a proposed way to compare outcomes in your own pilot.

Build a caller-language map before collecting examples

List the languages used in each workflow, the common switches and the business fields the conversation must capture. Separate what you know from call records from what you assume about a region. A caller's location or name does not determine their preferred language.

For a clinic, the critical fields may be doctor, branch, appointment time and callback number. For a property enquiry, they may be locality, configuration, budget range and visit preference. For support, they may be order reference, issue and permitted action.

Include the language in which callers open, the language they use for names and numbers, and the language used when another person joins. A single label such as “Hindi” may conceal Hindi-English switching in almost every important answer.

Use consented, appropriately handled representative material where available. You can also write synthetic test phrases with speakers familiar with the business language. Keep synthetic examples labelled, and avoid treating them as a substitute for real-world pilot review.

Test switches, corrections and interruptions

An evaluation set should include full-task conversations and targeted field checks. Full calls show whether context survives; field checks help explain why a task failed.

Test dimension	Example input pattern	What success means
Mid-sentence switch	Regional-language request with an English service name	Correct service selected without losing the request
Amount correction	“Eighty thousand, not eight lakh”	Correct value and unit saved after readback
Date correction	“Friday, sorry, Saturday afternoon”	Latest agreed date replaces the earlier preference
Local name	A branch or locality pronounced naturally	Correct approved entity, or a clarification
Interruption	Caller changes the request during the agent's answer	New request acknowledged and state updated
Speaker change	Parent takes over in a different language	New speaker and preference established
Background noise	A phrase spoken over realistic ambient noise	Clarification or safe fallback rather than a guessed field

Do not make every test adversarial. Include common, straightforward calls as well as difficult ones. A balanced set tells you whether the normal experience is usable and where the exceptions need work.

Define critical fields and expected outcomes

For each test, write the expected task and fields before listening to the system. This reduces the temptation to judge a plausible-sounding response as correct after the fact.

For example, a fictional clinic test could expect: doctor = approved doctor reference, day = Saturday, time_preference = afternoon, booking_status = pending until a successful write. If the assistant understands the conversation but records Friday, that test has failed on a critical field.

Use “unresolved” as a valid intermediate result when the input is genuinely ambiguous. A clarification can be more successful than an incorrect confident answer. Score whether the system asks a relevant question, follows the correction and reaches the agreed outcome.

For proper nouns, compare to approved source references where possible rather than only transcript spelling. Two transliterations may refer to the same doctor. Conversely, a plausible transcript may select a different similarly named branch.

A worked code-switching test

This illustrative example uses Hindi-English phrasing and fictional appointment context. Have speakers familiar with your caller language review the wording before using it in an evaluation.

Caller: Friday ko appointment chahiye. Sorry, Saturday afternoon. Dr. Mehta, not Dr. Mehra.

Assistant: You want Saturday afternoon with Dr. Mehta. I will check that doctor's available slots. Is that correct?

Caller: Haan, aur Indiranagar branch only.

The expected record should preserve Saturday afternoon, Dr. Mehta and the Indiranagar requirement. The assistant should then check availability for that exact combination. It should not offer a slot for Friday, choose the similar doctor name or move to another branch without agreement.

Repeat the task with different language switches and natural pronunciations. Do not train the demonstration around one phrase and then score that same phrase as evidence of broad language quality. Keep some evaluation phrases separate from setup examples.

Use a scorecard that exposes failure

Measure	Suggested definition	Why it helps
Critical-field correctness	Correct required fields divided by reviewed required fields	Shows whether names, dates and amounts survive
Task completion	Correct completed tasks divided by eligible task conversations	Connects understanding to the business outcome
Recovery after correction	Correct outcomes after a caller correction divided by correction tests	Tests conversational state, not only first-pass recognition
Clarification quality	Useful clarifications reviewed against ambiguous inputs	Distinguishes safe uncertainty from repetitive questioning
Handoff quality	Handoffs with accurate context and ownership	Checks whether unresolved calls remain usable
Response timing	Time from the end of a turn to a meaningful response, reviewed with callers	Helps detect pauses or interruptions that hurt the experience

Choose acceptance thresholds based on the consequences of errors in your task. This guide does not prescribe an accuracy percentage. An incorrect appointment time and a slightly awkward greeting have different impact and should not be averaged into one indistinct score.

Review results by language, task, speaker change and noise condition. Include the number of reviewed examples next to every percentage. A result from a handful of synthetic calls should not be presented as a production performance estimate.

Figure 01. Add sample size, version and observed errors alongside every score.

Fix the cause before expanding the language scope

When a test fails, inspect where the error began: speech understanding, entity matching, conversational state, tool lookup, final write or spoken readback. The same wrong appointment can arise from several different problems.

Give the implementation team approved pronunciation examples and business vocabulary where supported. Keep the expected values tied to the source system. If a name remains ambiguous, configure a short clarification rather than encouraging a guess.

Repeat only the relevant tests after a change, then review a held-out set and full conversations to check that the improvement generalises. Record the version being evaluated, the source data and any changed instructions.

For mixed-language handoffs, verify that the person receiving the task gets usable context. A fluent assistant that saves an unreadable or incorrectly translated issue summary can still create unnecessary work for staff.

Figure 02. Expected field → observed field → first point of disagreement.

Bring your difficult words to a Fonix demo

Bring the actual caller-language mix, a list of business names, representative number and date phrases, and one complete task. Ask the team to demonstrate interruptions, corrections and a human request. Check the written result as carefully as the audio.

Use the clinic workflow or property enquiry workflow as the task context. The Fonix language page describes coverage; this scorecard helps evaluate suitability for your traffic.

Request a demo in your language mix. Set a language-specific review plan before expanding from a small pilot to several branches or regions.

Voice AI for Business: Evaluation Guide and Pilot Scorecard

Programmatic DIB — Mon, 05 Oct 2026 07:58:46 +0000

Originally published by AntEngage in our voice AI evaluation guide. The original includes an interactive pilot scorecard and task-cost calculator.

A clear guide to AI voice agents, multilingual calling and the tests that separate a convincing demo from a working business workflow.

What is voice AI?

Voice AI is software that understands, generates or interacts through spoken language. For business calls, an AI voice agent combines conversation with approved actions: checking availability, updating an enquiry, resolving a supported request or handing the caller to a person. A natural voice is one part of that system; a correct, traceable outcome is the part your operation depends on.

What kind of voice AI do you need?

Start with the job rather than a product category. Creating narration, changing an existing voice and answering a customer call are different tasks. A text-to-speech demo does not establish whether an agent can handle a corrected date, wait for an API result or transfer an unresolved request.

Speech generation

Turn text into audio for narration, announcements or accessibility. Evaluate pronunciation, voice consistency and output controls.

Speech understanding

Transcribe or interpret spoken input. Evaluate important names, numbers, languages and corrections on representative recordings.

AI voice agents

Run interactive conversations with business tools. Evaluate task correctness, interruptions, failures, ownership and caller experience.

For a buying decision, ask each provider to demonstrate the same call and expected system result. A longer feature list is not evidence that your workflow will work better. Keep platform documentation separate from measured pilot results, and keep the exact configuration attached to every result.

How a business voice agent works

A common architecture connects telephony, speech recognition, conversation logic, business tools and speech generation. Other configurations use a direct speech-to-speech model. Either way, an agent must preserve the request across turns and distinguish a proposed action from a completed one.

Consider appointment booking. The agent captures a branch and service, reads available slots, gets the caller's agreement and submits the booking. It says the booking is confirmed only when the scheduling system returns evidence of success. A timeout can mean an unknown result; blindly retrying may create a second booking.

Evaluate the transaction as well as the conversation. A request, a successful write and a caller confirmation are separate events.

Define a reference for each action, a way to reconcile uncertain results and a fallback owner. The same design applies to CRM updates, rescheduling and order changes. An integration is ready when its permissions, error handling and observable results are tested together.

Choose one workflow with a measurable result

Begin where the scope is clear and your team can review outcomes. A focused pilot is easier to diagnose than a single agent asked to answer every possible business question. Specify the permitted task, required fields and boundaries before designing the conversation.

Workflow	Measure the outcome	Test the exception
Clinic reception	Correct confirmed appointment or owned callback	Slot disappears before booking
Lead qualification	Agreed qualification fields and next step	Caller corrects budget or location
COD confirmation	Recorded order decision with correct reference	Wrong person answers
Customer support	Verified supported resolution or contextual handoff	Requested action exceeds permission

Keep attempted calls, connected calls and eligible task conversations separate. A call that reaches voicemail should not inflate a task-completion claim. Review a sample of outcomes in the destination system rather than treating the agent's own summary as ground truth.

Multilingual voice AI: test the words that change the task

Indian business calls often include mixed-language phrases, local names, English service labels and corrected dates. Build your test set from the language mix your callers actually use. Do not infer a caller's preferred language from a name or location.

For a synthetic booking test, try: “Friday ko appointment chahiye. Sorry, Saturday afternoon. Dr. Mehta, not Dr. Mehra.” The correct outcome preserves the latest day, doctor and time preference. A fluent reply that stores Friday has failed the task.

Include natural accents, similar names, interrupted answers, ambiguous amounts and realistic background noise. Have speakers familiar with the caller language review synthetic material. Keep a held-out set that was not used to configure the demonstration.

Language coverage starts the evaluation. Correct business fields determine whether the task succeeds.

Fonix.AI supports 14+ Indian languages and code-switched conversations. Use the multilingual evaluation guide to scope a demonstration around your vocabulary. Coverage is not a measured accuracy score for your callers; the pilot should establish that evidence.

A voice AI pilot scorecard you can use

Score the same test set for every configuration. Select weights before reviewing results, and document a pass condition for every case. This tool is an editable planning aid; its weights are not an industry standard or a Fonix performance benchmark.

Dimension	Example result	Weight
Verified task completion	80%	35%
Critical-field correctness	90%	25%
Correction recovery	70%	15%
Handoffs with complete context	85%	15%
Calls meeting your timing criterion	75%	10%

Weighted example score: 81.3 / 100.

These fictional values illustrate the calculation. A high average cannot override a failed critical action, unauthorised write or false confirmation. Set those as separate launch gates.

Use the interactive pilot scorecard.

Record sample size, workflow, languages, model versions and tool configuration alongside the score. If a language group has only a few reviewed calls, report that limitation. Compare timing using the same definition, such as the end of the caller's turn to the first meaningful response.

Voice AI pricing: compare cost per correct outcome

A per-minute quote is only one input. Ask whether telephony, speech services, conversation models, platform charges, setup, support and human follow-up are included. Normalize competing quotes against the same workload and reviewed task result.

Monthly workload or cost	Example input
Connected calls	1,000
Average connected minutes per call	3
Combined variable charge	₹5/minute
Fixed and allocated setup costs	₹10,000
Human follow-up and other costs	₹5,000
Correct completed tasks	700

Monthly example cost: ₹30,000.00. Cost per correct task: ₹42.86.

These are example inputs, not a Fonix quotation. The model assumes at most one eligible task per connected call. Include failed-attempt charges in other costs where applicable. Taxes are excluded unless entered in costs.

Use the interactive task-cost calculator.

The formula is (connected calls × average minutes × combined rate + fixed costs + follow-up costs) ÷ correct completed tasks. Read the voice AI pricing guide for India for a fuller quote worksheet. Lower minute cost can still mean higher task cost if more calls require manual repair.

Cloud or on-premise: map the whole call path

Write down where audio, transcripts, conversation models, business tools and logs are processed and stored. A locally hosted model does not automatically move a cloud CRM, telephone network or support system inside your boundary.

For on-premise evaluation, document permitted external connections, update routes, backups, operator access and peak concurrency. Request evidence on the actual hardware and configuration you intend to use. Monthly minutes describe usage; they do not establish simultaneous-call capacity.

Fonix offers cloud and on-premise deployment options. Use the deployment-boundary guide to discuss which components belong in scope. Agree permissions and retention with your internal teams before expanding the pilot.

A practical route from demo to production

Define one task. Write required fields, success evidence, forbidden actions and the fallback owner.
Test representative conversations. Include ordinary calls, corrections, language switches and ambiguous requests.
Inject system failures. Exercise unavailable slots, permission errors, timeouts and uncertain writes.
Run a limited pilot. Review destination records and unresolved calls, then update the design.
Expand with monitoring. Track completion, critical errors, escalation ownership and cost by workflow and language.

Set a rollback path before launch. A team should be able to route calls to a person or another approved fallback when the integration is unhealthy. Review failures after changes to prompts, models, business rules or API versions; a previously good result does not prove the revised configuration is ready.

Bring your hardest call to a Fonix.AI demo

Share the task, caller languages, destination system and one failure case. We can discuss the workflow and the evidence your pilot should collect.

Discuss your voice AI workflow ↗

Voice AI questions, answered

Is voice AI the same as an AI voice agent?

Voice AI is the broader category, including recognition and speech generation. An AI voice agent uses spoken interaction to handle a task across a conversation, often with connected tools and a handoff path.

Can a voice agent replace an IVR?

It can handle selected intents using natural language, while DTMF, queues and human routes may remain useful fallbacks. Map existing journeys and test exceptions before migrating. See the conversational AI IVR guide.

Which voice AI platform is best?

The answer depends on your task, languages, integrations, deployment boundary and operating budget. Compare configurations on the same test set and system results; this guide does not claim an independently measured vendor ranking.

Can multilingual voice AI handle mixed languages?

Some systems support code-switching. Evaluate names, amounts and corrected dates in the actual language combinations your callers use, rather than judging only a translated greeting.

What should happen when a booking tool times out?

The result may be unknown. Reconcile it using a request reference, avoid uncontrolled retries and offer an owned follow-up when the booking cannot be verified. Do not report an unverified booking as confirmed.

Explore Fonix.AI and our workflow guides

This guide is published by AntEngage, the company behind Fonix.AI. Its examples and calculator values are illustrative. Visit Fonix.AI to explore the product and discuss your voice AI workflow.

Browse our AI calling software evaluation guide for campaign operations and the Fonix product guide collection for detailed workflows.

Designing a multilingual clinic receptionist: booking, failures and handoff

Programmatic DIB — Sun, 04 Oct 2026 07:43:10 +0000

Originally published as a Fonix.AI practical guide by AntEngage. This republication uses the same guide content.

When the front desk cannot pick up

An AI receptionist for clinics answers routine appointment enquiries, checks clinic information and helps the caller reach a clear next step. A useful deployment connects that conversation to the clinic's actual scheduling process. The appointment is confirmed only when the booking system confirms it; a clinical question or an unresolved request goes to a person.

Start with one coverage gap: calls outside opening hours or calls that overflow while the receptionist is occupied. Keep the existing front desk involved in the exceptions. This gives the team a manageable pilot and a concrete question to measure: which enquiries reached a confirmed booking or a completed callback?

Before changing anything, review a week of call records. Separate unanswered calls, repeated attempts from the same caller, scheduling enquiries and requests that require a staff member. An unanswered call is a useful signal, but it is not automatically a lost appointment. Use the records to choose a workflow rather than assume every ring represents revenue.

A booking workflow with a clear finish

1. Route the right calls

Decide whether the assistant receives every inbound call, only overflow calls or only calls outside opening hours. Agree how your existing business number will reach the service and what happens if the service is unavailable. Number forwarding, telephony configuration and human transfers should be demonstrated against the setup you intend to use.

Give the assistant an approved clinic-information source: location, opening hours, services, doctor schedules and the appropriate contact route. Assign someone at the clinic to keep it current. An accurate conversation today becomes an inaccurate one when next week's schedule changes without an update.

2. Establish the request and language

Introduce the automated assistant plainly, then ask what the caller needs. An appointment request, a reschedule and a question about opening hours are different tasks. Avoid collecting a full patient history for a simple booking enquiry.

Fonix.AI supports 14+ Indian languages, including code-switched speech. Test the actual language mix your callers use: a Kannada opening, an English doctor name and a Hindi clarification may all occur in one conversation. Language coverage is a reason to test a real call, not a substitute for that test.

3. Read availability from the scheduling source

Use the clinic's agreed scheduling system as the source of available slots. Confirm which integration can read availability and which can create, change or cancel a booking. A calendar connection that only reads events is not a complete booking integration.

Offer a small number of valid options, repeat the selected doctor, date and time, and ask the caller to confirm. Account for doctor-specific hours, appointment duration, holidays and branch location. If the availability lookup fails, take a callback request instead of offering a guessed slot.

4. Confirm the booking result

Create the appointment only after the caller agrees to the details. Wait for the scheduling system's successful response before saying it is booked. If a slot becomes unavailable between lookup and booking, explain the change and retrieve another option.

Where a confirmation channel is configured, send the final details through that channel. Confirm its integration and delivery behaviour during setup. An attempted message and a delivered confirmation are different outcomes; the call record should distinguish them.

5. Hand off what needs a person

Let callers ask for a human at any point. Agree whether the clinic can accept a live transfer or needs a callback queue, who owns that queue and when it is checked. If nobody is available, explain the next step without promising an unapproved response time.

Keep diagnosis, treatment advice and interpretation of symptoms outside the booking workflow. Use the clinic's approved instructions for urgent concerns and route them appropriately. A receptionist flow should never turn a request for clinical help into a generated medical answer.

Figure 01. Failed or unknown write? Recheck, then assign a callback.

What a real conversation should achieve

The following is an illustrative call, not a patient recording or a measured customer result. Assume the configured scheduling source has returned an available Saturday slot.

Caller: ನಮಸ್ಕಾರ, Saturday Dr. Rao appointment ಬೇಕಿತ್ತು.

Assistant: ನಮಸ್ಕಾರ. ನಾನು ಕ್ಲಿನಿಕ್‌ನ automated assistant. Dr. Rao ಅವರ Saturday available appointments check ಮಾಡುತ್ತೇನೆ.

Assistant: ಬೆಳಿಗ್ಗೆ 11:30 slot available ಇದೆ. ಆ ಸಮಯ ನಿಮಗೆ ಸರಿಯಾಗುತ್ತದೆಯೇ?

Caller: ಹೌದು, book ಮಾಡಿ.

Assistant: ನಿಮ್ಮ ಹೆಸರು ಮತ್ತು callback number ತಿಳಿಸುತ್ತೀರಾ? Booking confirm ಮಾಡುವ ಮೊದಲು details ಮತ್ತೆ ಹೇಳುತ್ತೇನೆ.

The assistant must still collect the agreed booking details, read them back, obtain confirmation and receive a successful booking response. Natural speech is one part of the experience. A correct appointment record is the finish.

Keep a compact outcome record: the caller's request, agreed language, doctor and branch, selected slot, booking reference if created, confirmation status and any handoff reason. Only retain information needed for the task under the clinic's agreed access and retention policies. This is a recommended record structure, not a published Fonix API schema.

Plan the exceptions before going live

Situation	Useful next step	What to test
Calendar lookup fails	Explain that availability cannot be confirmed; offer a callback	The agent never invents a slot
The selected slot is taken	Refresh availability and ask the caller to choose again	No booking is announced before a successful write
Caller wants to reschedule	Identify the existing booking through the approved process	The original appointment is not silently lost
Doctor or branch is unclear	Ask a short clarification	A similar name does not produce the wrong booking
Caller asks a clinical question	Use the approved handoff route	The assistant does not improvise medical advice
Caller asks for a person	Transfer when available, otherwise record a callback	The request is visible to the responsible staff member
Call disconnects mid-booking	Check the booking result before a follow-up attempt	Retries do not create duplicate appointments

Demonstrate these cases in the pilot. A successful scripted call shows that the normal path works; deliberately failing the calendar shows whether the workflow is safe to operate.

Figure 02. A routed request becomes useful when someone can act on it.

What the clinic needs to prepare

Prepare the business-number setup, opening hours, doctor and service information, scheduling source, appointment rules and a named owner for escalations. Bring representative caller phrases in the languages your clinic actually uses. Include spelling variations, interruptions and an unclear doctor name.

Ask for an integration walkthrough using your calendar or hospital system. Which records can be read? Which actions can be written? What identifies an existing appointment? What happens after a timeout? The availability of a particular integration must be confirmed for your deployment; do not assume every hospital system is already connected.

Fonix.AI offers cloud and on-premise deployment. Choose based on the workflow, infrastructure, data-handling requirements and the people who will operate it. An on-premise option does not remove the need to define staff access, recording choices, retention, updates and escalation ownership.

For a useful demo, bring your number-routing requirements, one representative doctor schedule, expected call volume and preferred languages. Ask the team to run a booking, a reschedule, a failed lookup and a human handoff. This reveals more than a conversation that only follows the happy path.

Measure coverage and completed appointments

Track completed tasks rather than only answered calls. Separate confirmed bookings, pending callback requests, transfers, unresolved enquiries and disconnected calls. Connect the booking reference to the appointment system so the clinic can later check whether the appointment was attended.

Measure	Definition	Why it matters
Booking completion	Confirmed bookings divided by eligible booking enquiries	Measures the scheduling workflow, not all inbound traffic
After-hours coverage	Eligible after-hours enquiries with a recorded outcome	Shows what the new coverage actually handled
Callback completion	Completed callbacks divided by assigned callback requests	Checks whether handoffs reach their owner
Duplicate or incorrect bookings	Reviewed booking errors in the pilot	Makes record quality visible
Appointment attendance	Attended appointments linked to assistant-created bookings	Connects the conversation to the clinic's real outcome

Compare like-for-like periods and note changes in opening hours, staffing and enquiry volume. Do not attribute every change in attendance to the assistant. Start with a baseline and use the pilot to decide where more coverage helps.

Questions to ask before choosing a receptionist

Can we keep our existing clinic number?

Discuss your current number and provider with the Fonix team. The routing arrangement, fallback and transfer behaviour need to be checked for that setup before deployment. Test them with a real call to the number patients already use.

Can the assistant book directly into our calendar?

Booking depends on the scheduling integration and the write permissions available. Ask for a demonstration against your system, including a slot that becomes unavailable and a failed request. If direct booking is not supported in your setup, agree an explicit callback or staff-confirmation workflow.

What if the caller switches language?

Fonix supports Indian-language and code-switched conversations. Evaluate the languages, names and accents from your clinic's traffic. Include a caller who interrupts or changes language halfway through the booking.

Will it replace the receptionist?

The pilot described here covers routine enquiries, overflow and after-hours calls. Staff still own clinical questions, exceptions and callbacks. Decide the division of work from actual call outcomes rather than assume every conversation should be automated.

How should we evaluate the cost?

Use expected call volume, duration, number requirements, setup, integrations, support and deployment mode. Review current Fonix pricing and request a quote for your specific workflow. Measure cost against completed bookings and callbacks, alongside record quality.

Put your clinic workflow to the test

Fonix.AI by AntEngage brings voice, chat and campaigns into one platform, with Indian-language conversations and cloud or on-premise deployment. The useful next step is a demo built around your clinic's actual booking rules.

Ask for a clinic receptionist demo. Bring a sample schedule, the languages you need and the exceptions your front desk deals with. You can also explore the Fonix platform, healthcare use cases and our AI calling software workflow.