Skip to content
Pedro Gomes
All work

In development

Phone-menu mapping and live navigation

Backend for a consumer telephony app that maps a company’s phone menu by calling it, then walks that menu on a live call for you and hands the call over at the destination. Under NDA: no public demo, source code or vendor names.

Architecture: the mobile apps, the app API, the orchestrator with its explorer and navigator engines, and the telephony, speech-to-text and LLM services they use

Who has this problem

Calling a large company usually means listening to a phone menu, guessing which option leads to a person, and starting over when the guess is wrong. The client, a consumer telephony startup that has not launched yet, wanted an app that shows you the menu before you call and then does the navigating for you. Understanding the menu was the easier part. The hard part is timing: phone menus pause in the middle of a greeting, keep reciting options after you press a key, ignore keys pressed at the wrong moment, and give you a few seconds to answer before they start over.

My role

FastAPI services for menu mapping and live navigation, app API integration and telephony session control.

Decisions I made

  • Two engines on one call pipeline. An explorer maps a company’s menu by calling it inside a fixed budget of calls and time, a few calls in parallel, and notifies the app when the map is ready. A navigator walks a chosen path on a live call. Both share the same call control, streaming transcription and decision layer, so a fix made for one is measured on the other.
  • Menu discovery keeps the last complete map when an interrupted or incomplete run cannot improve it. Live navigation confirms that a key was sent and rejects options that the menu did not offer.
  • A map never gets worse. An interrupted or poorer re-map, one that lost a branch or reachable endpoints, is refused instead of replacing a complete map. The map also stops serving phantom paths, options the menu never really offered, without losing the real ones.
  • The navigator advances only on a key press it confirmed was sent, and refuses keys the menu did not offer. When it reaches the destination (a person, a transfer or a prompt only the caller can answer), when the line goes quiet or when it cannot go on, it hands the call to the user through a conference bridge.
  • Numbers entered during the call, such as an order number, are redacted from logs at the point where they are dialled.
  • Live calls run in an isolated single-worker service because session state is held in memory. Menu discovery and navigation share call control, streaming transcription and decision handling.

Limits that remain

  • The app has not launched and the work is under NDA, so there is no public demo, no code and no vendor names here.