DEV Community: Programmatic DIB

Reliable interview scheduling by voice: calendars, panels and reschedules

Programmatic DIB — Wed, 11 Nov 2026 10:50:13 +0000

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

Coordinate an interview the calendars can support

AI interview scheduling calls help a recruitment team agree on an available meeting, confirm it in the relevant systems and handle changes. The useful outcome is an interview with the correct candidate, round, panel and time. Capturing someone's preferred time is not enough to establish a booking.

This guide focuses on coordination rather than selecting candidates or making hiring decisions. Start from a recruiter-approved application and scheduling task. Keep employment judgements and changes to selection status with the people authorised to make them.

Fonix.AI supports business conversations in Indian languages. Evaluate scheduling with your applicant-tracking system, calendars and invitation process. Confirm which systems and actions are connected for the deployment rather than assuming every ATS or calendar is supported.

Resolve the current application and interview round

Use a stable application reference, role, current scheduling status and round. A candidate may have applied for several roles or already completed an interview. An old task should not invite them to a superseded round.

Read the latest ATS state before contact. Suppress withdrawn applications, cancelled rounds and tasks that recruiters already completed according to your process. Preserve the original scheduling request and its owner so corrections can be traced.

Open with the employer identity, automated assistant and the actual application context. Ask whether it is a suitable time to coordinate. If the person does not recognise the role, resolve the mismatch rather than continue discussing a different application.

Keep sensitive application information out of unverified conversations. Use the employer's appropriate identification and access process for the fields the agent needs. Scheduling generally needs less information than a screening or evaluation discussion.

Find the intersection of candidate and panel availability

Availability is a combination of candidate preference, interviewer calendars and the requirements of the round. A free calendar slot is not sufficient if a required panel member, room or meeting resource is unavailable.

Constraint	Source	What to verify
Interview round	Current ATS task	Correct role, duration and required participants
Panel availability	Approved calendar access	All required participants can attend
Candidate preference	Conversation and confirmed readback	Date, time, time zone and constraints
Meeting resource	Room or video-link process	Required resource can be reserved
Booking policy	Recruitment rules	Notice period, buffers and allowed changes
Existing reservation	ATS and calendar	Avoid duplicate or conflicting meetings

Offer a small set of eligible slots and allow the candidate to request another time. Record constraints rather than forcing an unsuitable option. If no valid intersection exists, create a recruiter coordination task with the candidate's actual availability.

Read back the day, date, time and time zone. Avoid relative phrases such as “tomorrow at eleven” without a clear date and zone. A remote candidate may hear the employer's local time as their own.

Figure 01. Offer slot B; recheck and reserve only after the candidate agrees.

Write the booking and reconcile invitations

After agreement, reserve the slot through the approved scheduling process. Check the result before announcing confirmation. If another booking takes the slot during the call, offer a currently available alternative.

Keep the calendar reservation, ATS scheduling state and invitation delivery distinct. A calendar event may exist while the ATS update fails or a notification is still pending. Record the partial result and assign recovery rather than marking all three complete.

Use stable references for the booking attempt and resulting event where available. If a write times out, inspect whether the event exists before retrying. Repeated calls should not create several events for one interview round.

Explain the next step accurately. Give the confirmed slot and the invitation channel configured for your process. If the meeting link or instructions are still pending, preserve that status and the responsible owner.

An illustrative time-zone correction

The following fictional conversation assumes the panel has an available slot, with the employer based in India and the candidate temporarily in Singapore.

Assistant: This is the automated scheduling assistant for Pine Systems about your approved technical interview. One available option is 14 November at 11:00 a.m. India time. Would that work?

Candidate: I am in Singapore that week. Eleven here means something else. Can we do later?

Assistant: Thank you for clarifying. I will use Singapore time for your readback and check later panel availability. I will confirm both time zones before booking.

The record should preserve the candidate's current zone and agreed absolute meeting time. It must not keep the first offered slot merely because a scheduler extracted “eleven” from the conversation.

Suggested fields include application reference, round, participant set, candidate zone, agreed start and duration, event reference, ATS result, invitation status and coordination owner. These are workflow fields, not a Fonix API specification.

Protect the original during rescheduling

When the candidate requests a change, retrieve the current booking and new availability. Keep the original intact until your process confirms the replacement or explicitly decides to cancel it.

For systems without one atomic reschedule operation, define how failures are recovered. A new event created with the old event still active needs reconciliation; an old event cancelled before the new one exists leaves the candidate without a meeting.

Exception	Expected behaviour
Slot becomes unavailable during agreement	Offer a current alternative
One panel member declines	Assign recruiter review of the participant requirement
Candidate withdraws	Stop scheduling and record the withdrawal request for the recruiter
ATS and calendar disagree	Preserve references and assign reconciliation
Event creation result is unknown	Look up the result before retrying
Candidate needs different instructions	Route the request to the appropriate coordinator
Invitation cannot be delivered	Retain the confirmed meeting and own the delivery issue

A request for an accommodation or other change should be preserved for the employer's responsible team. Do not let the agent determine candidate eligibility from the request or infer a hiring outcome from a missed scheduling call.

Figure 02. Keep old and new references; assign partial failures to a coordinator.

Measure confirmed meetings and coordination failures

Track eligible scheduling tasks, useful conversations, verified bookings, invitations delivered and attended interviews for the same cohort. Keep scheduling status separate from evaluation status and interview outcome.

Measure time from the recruiter-approved task to a confirmed slot. Also inspect duplicate events, wrong time zones, unaccepted panel invitations and meetings left without instructions. A fast call can still create an unusable interview.

Compare similar roles, rounds and panel availability. Changes in recruiter workload or panel capacity can affect booking speed independently of voice automation. Include the effort spent repairing partial writes and reschedules in the pilot cost.

Bring one interview round to the demo

Bring a masked scheduling task, required participants, calendar permissions, candidate time zones and reschedule rules. Ask to see a slot race, a calendar/ATS conflict and a candidate withdrawal during an active sequence.

The appointment-reminder guide covers stale reminders after a booking changes, while the multilingual guide helps test date and time corrections. Request an interview-coordination review to evaluate the conversation and all resulting records.

Voice feedback surveys: preserve the scale and route unresolved complaints

Programmatic DIB — Sat, 07 Nov 2026 06:52:29 +0000

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

Collect a faithful response and act on it

Automated customer feedback calls ask a defined service cohort a consistent question, preserve the response and route issues that need follow-up. The goal is useful evidence about the experience, not simply a large number of ratings.

Fonix.AI supports business voice conversations in Indian languages. Evaluate the survey with your service-event source, question set and support process. Confirm the required cohort, record-writing and escalation connections for the deployment.

This page concerns post-service feedback. The customer-support guide covers resolving the original issue. If a survey reveals that the issue is still open, give it a support destination rather than treating the low rating as the final outcome.

Define the cohort and question before calling

Choose the event that makes a customer eligible: a delivered order, completed service visit or closed case. Preserve the event reference and time, then apply your contact preferences and duplication rules.

Do not survey a “completed” service without checking that the relevant source still agrees. A reopened ticket or cancelled visit may need a different conversation. Define how long after the event the survey runs and keep that interval stable during comparison.

Select the exact question, scale and wording before the pilot. Ask one thing at a time. “How satisfied were you with delivery and product quality?” combines two experiences and makes a single rating difficult to interpret.

Record the survey version and language. If the wording changes, the resulting ratings may not be directly comparable with the earlier version. Translations should preserve the concept and scale anchors rather than introduce praise or criticism.

Preserve the scale without suggesting an answer

Read the scale clearly and accept the customer's answer. Do not steer the caller towards a positive rating, reinterpret criticism as satisfaction or insist on a number when they decline.

Response	What to capture	What to avoid
A valid rating	Raw answer and confirmed scale value	Adding an inferred reason
“Good, but delivery was late”	Qualitative response and separate delivery comment	Assigning a score without clarification
A correction from four to two	The final confirmed value and correction	Keeping the earlier value
A value outside the scale	Ask a neutral clarification	Clamping automatically to the maximum
A refusal	Declined status	Treating refusal as a low score
No understandable answer	Unknown/incomplete status	Inventing a rating to finish the form

If the customer gives a qualitative response, ask whether they want to choose a scale value. Preserve their words if they prefer not to. A complete comment with no rating can be useful without being counted as a completed numeric response.

Use readback when a critical value is uncertain. The multilingual guide describes task-level testing across language switches, numbers and corrections.

Figure 01. Declined: no rating. Unknown: clarify. A comment is not a scale value.

Separate feedback from complaint resolution

A survey may surface a missing parcel, unresolved service fault or request for a person. Capture the issue and send it to the appropriate support queue with the original event reference.

Keep the rating, comment, complaint and follow-up result as different fields. A complaint being assigned does not change the survey rating, and a high rating does not remove the need to resolve a specific problem.

Tell the customer the accurate next step. “I have requested a callback” is appropriate when only a task was created. “The issue is resolved” requires evidence of an actual resolution.

Define whether the survey should stop when an urgent unresolved issue appears. Continuing several satisfaction questions while the customer is asking for help can damage the experience you are trying to measure.

An illustrative rating correction

This fictional survey follows a completed service visit. Assume the approved question uses a one-to-five scale, with five as most satisfied.

Assistant: On a scale from one to five, where five means most satisfied, how satisfied were you with the service visit?

Customer: Four. Actually two, kyunki problem abhi bhi hai.

Assistant: I have recorded two as your corrected rating. You also said the problem remains. Would you like the service team to contact you about it?

Customer: Yes, tomorrow morning.

The record contains a final rating of two, the raw correction, an unresolved problem and a requested callback time. It should not count four as the answer or claim that a support booking is confirmed without a receiving task.

Suggested fields include service-event reference, survey version, language, raw response, confirmed rating, comment, completion status, complaint reference and receiving owner. These are workflow suggestions rather than a published Fonix API.

Review refusals, repetition and record quality

Case	Expected behaviour
Duplicate service event	Avoid a second survey for the same eligible event
Ticket reopened before the call	Recheck eligibility and choose the appropriate flow
Customer gives an unclear number	Clarify neutrally or preserve unknown status
Customer refuses	Stop and record the preference
Complaint transfer fails	Create an owned follow-up rather than mark it resolved
Write result is unknown	Reconcile before submitting a duplicate response

Review a sample of recordings against stored answers. Check whether the assistant changed the scale, added a leading phrase or lost a correction. Record quality matters before interpreting an average rating.

Report the denominator and response limits

Show eligible customers, attempted contacts, reached customers, survey respondents and completed numeric answers separately. A rating average among respondents does not represent every eligible customer.

For a satisfaction percentage, define which valid ratings count as satisfied and divide by the valid answers to that question. Do not include refusals as negative answers or drop inconvenient low ratings. Keep incomplete and unknown responses visible alongside the metric.

Compare cohorts with similar service types, time since service, question versions and language mix. Changes in response rates can change the average even without a change in service quality. Track complaint acceptance and resolution time as separate operational outcomes.

Figure 02. Report the denominator, refusals, unknowns and question version.

Test one service cohort first

Bring a sample completed event, the exact question and scale, language variants and complaint-routing rules. Ask to see a refusal, a corrected score and a request for help during the survey.

Request a feedback-call evaluation to review the conversation and written record. Use the voice pricing guide to include survey and follow-up costs in your pilot.

Calculate voice-agent cost from billing units, not headline rates

Programmatic DIB — Fri, 06 Nov 2026 10:10:46 +0000

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

Compare the workload behind the quoted rate

AI voice agent pricing in India is easier to evaluate when you define the task, the metered usage and the costs around it. A per-minute rate is only one input. A meaningful comparison uses the same connected calls, duration, transfer behaviour and verified outcomes across proposals.

This guide explains the cost model behind our editable workload calculator. Its example values are hypothetical inputs, not Fonix rates or a market-price survey. Use the live Fonix pricing page and a dated proposal for current commercial terms.

The AI calling-software guide covers platform selection. This page concentrates on billing and operational economics so you can compare the cost of completing a task rather than a headline rate alone.

Define a workload that both vendors can price

Start with one period and one task, such as confirming eligible orders or arranging support callbacks. Count connected conversations separately from attempts. List average duration, the distribution of call lengths, transfers and follow-ups.

Workload input	Why it matters	Source to bring
Connected calls	Determines the conversations that may be billed	Call logs or pilot plan
Duration by call	Billing increments may round each call separately	Completed-call timestamps
Attempts with no conversation	Some proposals meter these differently	Carrier outcomes and rate scope
Transfers and carrier legs	A second active leg may add usage	Transfer logs and quote definitions
Additional follow-up calls	Another conversation adds another unit of usage	Workflow sequence and stop rules
Verified task outcomes	Establishes the denominator for task cost	Source-system confirmation

Use a measured sample where possible. An average duration is useful for a first estimate but cannot reproduce per-call rounding exactly when individual calls have different lengths.

If retries are already included in the connected-call count, do not add them again. Likewise, a bundled rate should not receive another speech or model charge unless the proposal explicitly excludes it.

Read the meter before multiplying minutes

Ask when billing starts, when it stops, what minimum applies and whether increments round each call or the monthly total. Confirm how silence, hold time, voicemail, transfers and disconnected calls are counted.

For a simplified workload in which all calls have the same duration, billable minutes equal connected calls multiplied by the duration rounded up to the stated increment. If the increment is 60 seconds, an illustrative 130-second call becomes three billable minutes. At a one-second increment, the same conversation contributes approximately 2.17 minutes.

For actual logs, round each call independently according to the contract, then sum the result. Rounding the average and multiplying can overstate or understate the bill. Minimums, different carrier legs and separate component meters need their own calculations.

Confirm the scope of a quoted rate: telephony, speech recognition, speech generation, model use, runtime, recording storage and tools. Ask for the rate definition in writing. A low rate with several separate meters may still suit a workload, but it is not directly comparable to a bundled rate without those additional inputs.

Figure 01. Round each real call independently, then sum the billed units.

Include fixed and operating costs

Add platform fees, number rental, setup allocation, implementation support, monitoring, record review and manual exception handling where they apply. Keep one-time and recurring costs visible rather than hiding implementation in a monthly average without explanation.

Allocate setup over the period relevant to your decision. A six-month pilot and a multi-year deployment have different cost views. Report the original setup amount as well as the allocation so someone reviewing the calculation can change the assumption.

For an on-premise proposal, include the hardware and operating responsibilities your team actually takes on. The on-premise voice guide covers infrastructure boundaries and capacity. Monthly conversation minutes alone do not determine the hardware needed for peak simultaneous calls.

Treat taxes, minimum commitments, discounts and credits according to the dated proposal. The workload calculator excludes tax and does not apply a plan's minimum spend or bundled allowances automatically.

A transparent illustrative calculation

Suppose a fictional workload has 1,000 connected calls, each lasting 130 seconds, with 60-second billing increments. Assume a hypothetical all-in variable rate of ₹4 per billable minute, ₹3,000 in fixed monthly costs, ₹1,000 in allocated setup and ₹2,000 in manual operating work.

The conversation workload is approximately 2,166.67 measured minutes. Under the uniform-duration assumption, it becomes 3,000 billable minutes. Variable cost is ₹12,000; total estimated cost is ₹18,000 before tax. If 400 tasks are independently verified as completed, the estimated cost is ₹45 per completed task.

These numbers show the arithmetic, not a product price or guaranteed outcome. If callers have different durations, replace the uniform assumption with a log-level calculation. If ₹4 covers only the platform component, add the missing metered costs instead of calling it all-in.

The editable calculator uses this same model. Transfer usage can be added separately, provided it is not already included in the connected-call duration. Its “completed tasks” field is an observed or planned input; the calculator does not forecast conversions.

Figure 02. 1,000 calls × 3 billed minutes × ₹4 = ₹12,000 variable use.

Compare costs for the same completed task

Define completion in the operational system: a confirmed booking, a delivered shipment or an accepted case resolution. A generated transcript, successful call connection or payment intention is not interchangeable with those outcomes.

Calculate total operating cost divided by verified completed tasks for the same cohort. Keep unresolved work and later cancellations visible. If there are no completed tasks, cost per outcome is undefined; report the total expense rather than divide by an invented denominator.

When comparing pilots, use similar task scope, source quality and language mix. A provider handling simpler questions may show a lower cost per outcome without performing the same work. Include human review when comparing a fully automated flow with an assisted one.

Ask for a proposal you can reconcile

Question	Evidence that makes the answer useful
What exactly is a billable minute?	Start/stop rules, minimum and rounding examples
Which components are included?	A component list with separate rate definitions
How are transfers charged?	Carrier-leg and agent-runtime treatment
What happens after a failed call or tool action?	Attempt billing and retry rules
Are there minimum commitments?	Spend floor, allowance and expiry terms
What setup work is required?	Deliverables, owners and one-time amount
How do we reconcile the invoice?	Usage export and references matching call records

Test a short call, a long call, no answer and a transfer against the provider's stated meter. Compare the usage export to your logs. A spreadsheet estimate is useful, but an invoice that can be reconciled is stronger evidence.

Bring your workload to a pricing review

Bring connected-call counts, duration samples, carrier routing, transfer rates and one clearly defined task outcome. Request a voice workload estimate and confirm rates through the current pricing page.

Use the calculator to prepare questions and compare assumptions. It is a planning tool with visible inputs, not a vendor quote or a promise of savings.

Building insurance-renewal calls with current policy state and advisor handoff

Programmatic DIB — Sun, 01 Nov 2026 06:01:44 +0000

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

Make a renewal conversation useful

AI insurance renewal calls can remind a policyholder about a renewal, explain approved current information and arrange a conversation with an advisor. The operational goal is a clear next step attached to the correct policy. Renewal interest, payment initiation and an issued renewed policy are separate states.

Fonix.AI supports business voice conversations in Indian languages. Use this guide to evaluate renewal coordination against your policy-administration, advisor and communication systems. Confirm the required connections and permissions for your deployment rather than assuming that every insurer or intermediary system is supported.

Keep information and logistics distinct from advice or policy decisions. Questions about changing coverage, suitability, exclusions or claims should reach the person authorised to answer them. The guide proposes a workflow, not an underwriting or coverage-advice service.

Resolve the policy and current renewal record

A contact may have multiple policies, and the same household number may appear on several records. Start from a stable policy reference, product, expiry date, current status, approved contact and assigned advisor. Apply the appropriate identity checks before discussing private details.

Read the latest renewal state before each call. A policy may already be renewed, cancelled or awaiting review. Suppress records that no longer need the reminder and avoid relying only on a list exported several days earlier.

Keep a version or timestamp for the quote and any approved explanation. A prior year's premium or coverage description is not necessarily the current renewal offer. The call should disclose which information it can explain and route uncertainty rather than guess.

Agree on the outreach process with the responsible business team, including timing, preferences, disclosure and escalation. Review applicable requirements before a campaign; do not treat a vendor's general compliance statement as approval for a specific renewal script.

Separate renewal facts from advisor questions

Use the agent for information that has a current approved source. Build an explicit destination for questions requiring judgement or a policy change.

Request	Agent's task	Owner of the next decision
When is renewal due?	Read the verified expiry and renewal information	Policy operations for source conflicts
What is the current renewal amount?	Quote the approved current record after verification	Advisor or operations if the quote is unclear
I want to change the coverage	Capture the exact change requested	Authorised advisor
Does a treatment or event qualify?	Preserve the question without determining cover	Authorised policy/claims team
I renewed yesterday	Check the current policy state	Operations if payment and issuance differ
Please call later	Record one suitable callback preference	Assigned advisor or renewal team

Avoid interpreting a request for more information as agreement to renew. Read back the requested next step so the policyholder can correct it. If a family member needs to join a discussion, record that preference without transferring private policy information prematurely.

Regional-language evaluation should include dates, policy references, amounts and corrections. A correct-sounding reminder with the wrong expiry date can create more work than an unanswered call.

Figure 01. Keep the policy context, exact question and receiving owner attached.

Keep payment and policy issuance distinct

When an approved renewal link is configured, retrieve or generate it through the authorised process. Record whether the policyholder requested it and whether delivery was confirmed by the relevant channel.

A delivered link is not payment. A successful payment is not necessarily a policy already issued or a coverage change accepted. Use the administration system's confirmed state for the actual renewal result and preserve intermediate states for reconciliation.

If payment or issuance is pending, explain only the verified status and route the unresolved step. Do not announce that cover has continued merely because the person expressed an intention to pay.

Define the stop condition for reminder sequences. An issued renewal, an active advisor task or another ineligible state should prevent unrelated automated reminders according to your approved process. Recheck that state before queued attempts.

Figure 02. Only the policy-administration record verifies issuance.

An illustrative advisor handoff

The following example concerns a fictional policyholder after verification. Assume the renewal source is current and the agent is permitted to explain its date.

Assistant: This is the automated renewal assistant for Maple Insurance Services. Your current record shows renewal due on 18 December. Would you like a reminder link or an advisor conversation?

Policyholder: I want to renew, but add my spouse. Premium change hoga?

Assistant: I have recorded your renewal interest and the request to add your spouse. An advisor needs to review the change and current quote. What time would suit that conversation?

The record should show renewal interest, a requested policy change and an advisor callback. It should not show an accepted quote, an added member or a completed renewal.

Suggested fields include policy reference, current renewal state, quote version, verified contact, requested change, advisor question, callback preference, link result and issued-policy reference. They are proposed workflow fields rather than a published Fonix API.

Test the conflicts that matter

Situation	Required response
Policy renewed after the list was exported	Stop the reminder after a current lookup
Several policies share the contact	Identify the correct record through the approved process
Prior-year and current quotes differ	Use the approved current version; route unresolved conflict
Policyholder asks about a claim	Preserve context and use the authorised claims route
Link creation times out	Check whether it was created before retrying
Payment succeeds but issuance is pending	Keep the states separate and assign reconciliation
Advisor callback is not accepted	Keep the task open with a responsible queue

Include a coverage-change request in the demo. It tests whether the agent respects its information boundary and whether the advisor receives enough context to help.

Measure renewal outcomes without hiding open work

Track eligible policies, useful verified conversations, advisor requests accepted, links delivered, payments confirmed and renewals issued for the same expiry cohort. Separate no-contact records, declined renewals and pending changes.

Review policy-reference accuracy, incorrect quote readbacks, reminders after renewal and age of open advisor tasks. These indicators reveal failures that a simple call-connect rate hides.

Compare similar products, expiry periods and outreach treatments. A policyholder renewing after a call does not establish that the call caused the renewal. Preserve the baseline and any parallel channels when interpreting the pilot.

Bring one renewal process to the demo

Bring a masked policy record, current renewal information, advisor destinations and the statuses your administration system supplies. Demonstrate an already-renewed policy, a coverage question and a payment with issuance pending.

The support guide covers verified lookups and escalation, while the EMI reminder guide explains the distinction between a stated intention and a confirmed payment. Request a renewal workflow review to test your process and languages.

Building a support voice bot: trusted lookups, ticket writes and escalation context

Programmatic DIB — Wed, 28 Oct 2026 06:36:12 +0000

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

Resolve the issue from a trusted source

A voice bot for customer support answers routine questions, retrieves permitted account information and routes unresolved requests to a person. A useful support workflow produces a verified answer or an actionable ticket. It should not report a refund, replacement or account change unless the relevant system confirms that action.

Choose one issue family for the first pilot, such as order status or a published service policy. Identify the source of truth, access rules and escalation owner. Avoid starting with every support topic: each additional task introduces different verification requirements, tool permissions and failure cases.

Fonix.AI provides voice conversations in Indian languages and supports business workflows. Confirm your specific knowledge, account-system and helpdesk connections with the team. The architecture below is an evaluation design, not a claim that every named support product has a ready-made connector.

Classify the request before looking up private details

Begin by identifying the business and automated assistant, then let the caller explain the issue. A general policy question and an account-specific question need different information. Someone asking for store hours should not have to provide an order number first.

Use an agreed set of issue categories to route the conversation, but preserve the caller's actual question. “Delivery problem” can mean an order has not dispatched, a package is delayed or an item arrived damaged. Those are different source lookups and different next actions.

Ask a short clarification when the category is uncertain. After repeated misunderstanding, offer the configured human route. A bot should not loop through the same question simply because its classifier needs an answer.

Allow the caller to request a person. Confirm transfer availability and the alternative when nobody is available. A promise to transfer is not a completed transfer; test the staffed destination and the timeout behaviour.

Separate public answers, account lookups and permitted actions

Create a task matrix with your support team. It should state which information can be read, what verification is needed and whether the assistant may change anything.

Task	Approved source	Permission boundary	Useful result
Opening hours or published policy	Current business knowledge source	Public information	Answer with the relevant condition
Order or ticket status	Account-linked system record	Approved recipient verification	Current status and next step
Change a delivery preference	Order system	Verified recipient and allowed state	Confirmed update or review request
Refund or replacement request	Support policy and authorised workflow	Case-specific review where required	Ticket or confirmed permitted action
Complaint or repeated failure	Helpdesk and escalation policy	Appropriate staff access	Owned escalation with context

Agree how the system identifies an account and verifies the recipient. A caller knowing an order number is not automatically authorised to hear every detail about that order. Test the actual approved process rather than designing verification from assumptions.

Limit tool permissions to the tasks in the pilot. A status-lookup workflow does not need broad write access. Keep information returned by tools scoped to the conversation so unnecessary account fields do not enter a transcript.

Figure 01. Do the smallest permitted lookup or action that resolves the request.

Answer the question the source actually supports

For general answers, maintain an approved knowledge set with owners and update dates. Version policy changes so a refund rule from last quarter does not silently remain in the answer source. If two documents disagree, route the conflict for review instead of combining them into a new policy.

For account questions, read the current record and distinguish a known status from a prediction. “Dispatched” and “will arrive tomorrow” are different claims. Give an estimated date only when the source explicitly supports it, and explain the approved limitation where necessary.

Repeat critical values clearly: order references, dates, amounts and branch names. Let the caller correct them before proceeding. An interruption may contain the exact fact needed to avoid looking up the wrong record.

If a lookup fails, explain that the information cannot currently be verified and offer the configured next step. Do not replace a failed lookup with a confident answer generated from similar past cases.

A failed lookup can still produce a useful ticket

This is an illustrative order-status call. No customer result or integration is implied.

Caller: Mera parcel abhi tak nahi aaya. Tracking link bhi nahi chal raha.

Assistant: You are asking about a delayed parcel and a tracking link that is not working. I will follow our verification process before checking the order.

Assistant, after an unavailable lookup: I cannot verify the current delivery status right now. I can send this issue to the support team with the order reference and the tracking-link problem. Would you like me to create that request?

If ticket creation succeeds, give the confirmed reference and approved expectations. If the write fails or its result is unknown, explain the configured fallback without inventing a reference number.

A suggested handoff record contains the verified account reference, issue summary, relevant source status, attempted tool action, its confirmed result, customer's requested next step and receiving queue. These are design fields, not a published Fonix schema. Preserve uncertainty so the next agent does not treat an attempted action as completed.

Make escalation a workflow with an owner

Specify which queues accept billing, delivery, technical or general complaints. Route on the issue and required authority, rather than inferred emotion or personal characteristics. If a person is upset, use a clear handoff instead of repeatedly offering the same generated explanation.

For live transfers, test whether the receiving agent gets context and what happens when the line is busy. For callbacks, name the responsible queue and use only an approved response-time statement. Record whether the queue accepted the task.

Use a deduplication rule when a caller contacts support repeatedly about the same unresolved issue. Appending context to an existing case can be more useful than opening another ticket. The helpdesk's own ownership and merge rules should control this behaviour.

The conversational AI and IVR guide covers call-routing choices and known fallbacks. The COD confirmation guide describes the separate pre-dispatch decision flow.

Figure 02. An accepted queue, accurate context and a responsible owner.

Test resolution, access and recovery separately

Test	Expected behaviour	What to inspect
Caller fails account verification	No account detail disclosed	Verification outcome and permitted fallback
Knowledge documents conflict	Review or handoff	Source versions and exact conflicting rule
Status API is unavailable	Explain uncertainty and offer a next step	Lookup result and escalation context
Ticket write times out	Check the operation before retrying	Confirmed ticket reference or explicit unresolved result
Caller has an existing open case	Follow helpdesk deduplication policy	Existing case and appended context
Transfer destination is busy	Offer the configured alternative	Transfer result and callback ownership

Include language switching, unclear order references and a caller interrupting with a correction. Check each final record against the source system. A pleasant call can still produce an incorrect or unauthorised result.

Measure support resolution rather than apparent containment

Count eligible issues, verified answers, successful actions, accepted tickets, completed handoffs and unresolved cases. Define resolution using evidence from the task, rather than assuming that a call ending without transfer means success.

Review repeat contacts for the same issue within a defined window. A bot can appear to contain a high share of calls while customers call again because the answer did not help. Look at repeated issues, wrong answers and reopened tickets alongside handling time.

Segment results by issue and language. Include sampled record review and caller feedback where available. Cost calculations should include manual follow-up and integration operation, not just conversation minutes.

Request a support lookup demo with one frequent issue, an approved source and a failure case. Agree the evidence that proves resolution before expanding the support scope.

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.