Hebrew & Yiddish IVR Development: A Multilingual Voice Platform

Industry

GPS tracking · family safety · IoT

Languages

Hebrew · Yiddish · English

Inbound

Yemot HaMashiach IVR

Outbound

Twilio Voice alerts

Backend

NestJS · PostgreSQL

Honest claim

Recorded prompts + DTMF — not an LLM agent

Project overview

The business problem: safety information must remain accessible by phone

GPS trackers, smartwatches and connected devices can provide location and safety information. Not every user can or wants to open a mobile application every time they need that information.

The platform needed a telephone interface for users who wanted to:

• Hear the latest available location of a registered GPS device
• Register a phone number or add a device
• Navigate menus in Hebrew, English or Yiddish
• Access registered-device information through controlled menu flows
• Set, change or remove a device PIN
• Manage recorded device nicknames
• Receive voice notifications about SOS, geofence changes, low battery and supported device-health alerts

Inbound telephone self-service and outbound event-driven notifications were separate workflows with different requirements for caller input, data access, call progression, scheduling and delivery handling.

Why Hebrew and Yiddish made this more than a standard IVR

Supporting multiple languages on a phone system is not translating an English menu. A usable multilingual IVR needs language-specific audio, deterministic menu routing, reliable keypad handling, and a method for speaking dynamic information such as an address or device status — especially when the selected language does not have dependable TTS on the chosen telephony platform.

Hebrew IVR

The inbound workflow included a dedicated Hebrew prompt path. Callers selected Hebrew at the start of the call and continued through the applicable telephone menus. The implementation had to preserve the selected language while processing caller input and returning the next prompt.

Yiddish IVR

Yiddish required particular attention to the availability and playback of recorded audio. The documented Yemot implementation relied on recorded WAV prompt packs because available platform TTS was not suitable for the required workflow. A language can be supported through properly prepared recordings even when the platform cannot reliably synthesize that language dynamically.

English IVR

English was another supported path through the same telephone experience. Each language had its own prompt resources rather than a single English menu with translated labels.

Engineering lesson: Language support must be designed around the actual capabilities of the telephony provider, the audio assets and the application — not assumed from the language list in an AI or TTS product description.

The engineering challenges I addressed

1. Language-aware telephone navigation

The system needed to route callers into the correct language-specific menu without losing context for subsequent steps. I worked on the inbound IVR flow and its backend interaction contract so the application could determine the next prompt from the caller’s current interaction.

2. Reliable state across IVR callbacks

Yemot communicates with the backend through HTTP callbacks. Keypad input or prompt progression can trigger another request. The backend had to return the appropriate next instruction each time — including platform-specific behaviours such as repeated or empty callbacks and stale keypad values.

A technically successful HTTP request does not guarantee a correct telephone experience. A menu can still repeat, advance incorrectly, or accept an unintended digit.

3. Public and registered caller workflows

Unregistered callers needed device-location lookup and registration. Known callers needed device lists, location information and selected device-management operations. PIN checks and retry behaviour were part of the controlled interaction design for protected actions.

4. Outbound safety alerts

The outbound pipeline connected device events and alert rules to scheduled voice delivery through Twilio:

• Event-based alert evaluation
• Delivery scheduling and quiet-hour policies
• Spoken alert sequences using the appropriate audio assets
• Answering-machine detection (AMD)
• Retry handling for applicable delivery outcomes
• Grouping of multiple alerts within a call, subject to defined limits

SOS notifications followed a separate policy that could bypass standard quiet hours.

5. Audio playback and provider limitations

A multilingual workflow is only useful when its audio assets are playable in the target environment. The implementation accounted for platform-specific audio-folder constraints and the need to use the correct recorded prompts. Dynamic spoken information and prerecorded menu audio are different requirements. For Yiddish, recorded prompt playback and dynamically generated speech are not interchangeable capabilities.

The solution: one backend, two telephony paths

I worked on the backend and telephony integration that connected the application to two distinct telephone workflows. Application decisions and device-related business logic stayed in the backend; each telephony provider performed the telephone-specific work it supports.

INBOUND
  Caller
    |
    v
  Yemot HaMashiach
    |
  HTTP callbacks
    |
    v
  NestJS API  ---->  PostgreSQL (devices, PIN, location)
    |
    v
  Next prompt / DTMF instruction

OUTBOUND
  GPS / IoT event
    |
    v
  Alert rules + quiet hours
    |
    v
  Twilio Voice  (TwiML, AMD, retries)
    |
    v
  Recipient hears greeting + device + alert

Inbound: Yemot HaMashiach

The caller dials the service number, selects a language, and navigates with keypad input. The telephony platform sends callbacks to the NestJS API, which evaluates the current interaction and returns instructions for the next step.

Outbound: Twilio Voice

A device event is evaluated against applicable alert rules. The system creates a delivery record and initiates an outbound call when the notification policy permits it. The call plays the configured greeting, device information and alert audio, with status handling and retries where appropriate.

Shared application backend

NestJS and PostgreSQL hold device data, location information, registration, alert rules and delivery records. Redis supported selected call-session capabilities.

How the multilingual IVR works

Caller journey

1. Call the service number. The inbound telephony platform receives the call.
2. Choose a language. The caller selects Hebrew, English or Yiddish.
3. Enter the appropriate menu. The system routes into the corresponding recorded-prompt path.
4. Identify the device or account. Keypad input or the registered-caller path.
5. Perform the requested operation. Location lookup, registration, or a supported device-management action.
6. Receive spoken information. Recorded prompt or supported speech output.
7. Continue or exit. Next menu instruction or end of session.

Outbound alert journey

1. A tracker or supported device reports an event.
2. The backend evaluates the event and applicable alert rules.
3. A delivery record is created and processed according to scheduling and quiet-hour policies.
4. Twilio initiates the outbound call.
5. The recipient hears the configured greeting, device identification and alert message.
6. The system processes call status and applicable retry conditions.

This separation is easier to understand, test and extend than treating every inbound menu and outbound notification as one generic voice flow.

My technical contribution

Backend engineering and telephony workflows, including:

• Yemot callback interaction logic
• IVR state and menu-progression handling
• Outbound Twilio voice delivery and TwiML responses
• Answering-machine detection and applicable retry policies
• GPS events → alert evaluation → notification delivery
• Device capability checks and controlled access to protected operations
• System architecture and telephone-journey documentation
• Automated IVR tests and callback-replay validation
• NestJS API integration with the existing PostgreSQL data model

The mobile application interface was maintained separately from the backend codebase covered by this case study. Client identity is withheld.

Technology stack

• Backend: Node.js, NestJS, TypeScript
• Data: PostgreSQL; Redis for selected call-session capabilities
• Telephony: Yemot HaMashiach, Twilio Voice, DTMF, TwiML
• Voice and audio: Language-specific recorded WAV prompts; TTS only where the provider actually supported it
• Quality: Jest, callback-replay scripts, Swagger/OpenAPI
• Deployment: Node.js on EC2 with PM2 and an automated deployment workflow

The implementation used existing telephony platforms rather than recreating the telephone network or building a proprietary speech model. Adjacent stacks on this site: AI voice development · IVR automation · SIP AI voice agent.

Engineering outcomes

The following are delivered functionality from the implementation and documentation — not unverified business KPIs.

• Three-language inbound IVR — English, Hebrew and Yiddish menu paths using language-specific recorded prompts
• Telephone-based self-service — device-location lookup, registration and supported device-management operations
• Integrated outbound voice alerts — device events triggering configured Twilio voice notifications
• Alert-delivery controls — scheduling, quiet hours, AMD and applicable retry handling
• Backend integration — IVR and alert processing connected to the existing GPS tracking / safety application
• Documented and testable workflows — API documentation, IVR test suites and callback-replay scripts

I do not claim a percentage reduction in support costs, a specific call-completion rate, or a measured increase in user satisfaction — those figures were not established by the available project evidence.

What this project demonstrates

The work sat at the intersection of application engineering, multilingual voice workflows and telephony integrations: real telephone interaction patterns, provider-specific callback contracts, device data, alert processing and audio playback constraints — not a chatbot on a web page.

It is especially relevant to teams that need a developer who can work through the details of a language-specific IVR rather than relying exclusively on generic AI or CPaaS product capabilities.

Can this architecture be extended to AI voice agents?

Yes — as a separate engineering extension, subject to provider support and language-specific testing. A conversational voice implementation could introduce STT, an LLM dialogue layer and TTS while retaining the existing application and telephony responsibilities where appropriate.

• Hebrew: validate speech-recognition accuracy, language routing, voice quality and dynamic-prompt behaviour
• Yiddish: validate the actual speech provider’s recognition and synthesis with representative native-language recordings. If suitable TTS/STT is unavailable, recorded prompts plus deterministic keypad flows remain more reliable

This project should not be interpreted as evidence that an LLM-based Hebrew/Yiddish voice agent was already implemented. It demonstrates the multilingual IVR and voice-notification engineering that can inform a future extension. See the SIP AI voice agent case for conversational voice on a live call, and AI voice articles for the educational layer.

Who can benefit from this experience

• Businesses serving Hebrew-speaking and Yiddish-speaking communities
• Family safety and GPS tracking platforms
• IoT and connected-device companies requiring voice notifications
• Service providers building multilingual telephone self-service
• Product teams integrating IVR with existing APIs and databases
• Telecom companies evaluating AI-assisted voice workflows
• Startups needing a custom IVR rather than a generic contact-center package

Questions this case study answers

Project confidentiality is respected. Client-specific identifiers and private implementation details are not published.