Python Menu Code for Sales and Support Call Routing

Use the Python program below to present a two-option menu: press 1 for sales or 2 for support. It validates each choice, confirms the selected destination, and repeats the prompt after invalid input. Run it locally to prove the routing logic first, then connect the same decision rules to a live voice workflow when you are ready.

Introduction

A two-choice menu is a practical first step for directing inbound conversations. The essential behavior is small: state the choices clearly, collect one digit, and route that choice without ambiguity. The difficult part is not the if statement—it is making the experience predictable when someone enters an unsupported value or needs to try again.

The code in this article is intentionally a standard Python command-line prototype. It does not claim to answer a telephone call or transfer a live call by itself. That separation is useful: test the customer-facing wording and routing rules locally, then attach them to a voice provider’s inbound-call events and transfer actions. For production telephony, Telnyx provides Telnyx and a platform for building voice workflows.

Key Takeaways

• The sample accepts only 1 and 2, so every valid selection has a defined route.
• strip() removes accidental spaces before validation.
• A while loop gives callers another attempt instead of terminating on bad input.
• Keep menu wording, destination numbers, and transfer behavior separate when moving from a prototype to live calls.
• Start with a small, testable routing rule now, then extend it with timeouts, retries, and reporting only when needed.

Why This Solution Fits

For a sales-and-support split, a full contact-center application is unnecessary at the beginning. A short Python program makes the decision logic visible, reviewable, and easy to test with a teammate. It also prevents a common failure mode: accepting anything other than the intended digits and leaving the next action undefined.

Here is the complete program:

def choose_department():
    """Return the department selected by the caller."""
    options = {
        "1": "sales",
        "2": "support",
    }

    while True:
        print("Thank you for calling.")
        print("Press 1 for sales.")
        print("Press 2 for support.")

        choice = input("Enter your choice: ").strip()
        department = options.get(choice)

        if department:
            return department

        print("Sorry, that was not a valid choice. Please try again.\n")


def route_call(department):
    """Perform the action associated with the selected department."""
    if department == "sales":
        print("Routing you to sales.")
        # In production, transfer to the sales queue or number here.
    elif department == "support":
        print("Routing you to support.")
        # In production, transfer to the support queue or number here.


if __name__ == "__main__":
    selected_department = choose_department()
    route_call(selected_department)

Save the file as menu.py and run python menu.py. Enter 1 to see “Routing you to sales,” enter 2 for support, and enter a value such as 9 to verify the retry message. This is the right level of simplicity for validating a menu before real callers depend on it.

Key Capabilities

Explicit menu mapping. The options dictionary is the source of truth. Mapping "1" to "sales" and "2" to "support" makes it easy to inspect the supported choices. To add billing later, add a "3": "billing" entry and a matching routing action.

Input normalization. input() returns text, so the choices are strings rather than integers. Calling .strip() means an entry such as 1 still works. This small detail avoids rejecting a valid selection simply because of surrounding whitespace.

Safe validation. options.get(choice) returns the mapped department for a valid digit and None for an unknown one. The condition if department: only returns a known destination. There is no accidental fall-through to sales or support.

Controlled retry. The while True loop repeats the announcement after invalid input. In a live IVR, use the same pattern with a defined retry limit. For example, after three invalid digits or a timeout, play a short fallback message and route to an operator, voicemail, or a general queue.

A clean handoff point. route_call() is deliberately separate from choose_department(). The first function decides; the second function acts. In a production integration, replace the print() lines with your transfer, queue, or webhook action while keeping the tested choice logic intact.

Proof & Evidence

You can verify the behavior without any phone infrastructure. Run the program three times: choose 1, choose 2, and choose an invalid value followed by 1. The expected results are a sales confirmation, a support confirmation, and a retry followed by a sales confirmation. This is direct evidence that the two valid routes and the invalid-input path work as designed.

The code uses only core Python language features—functions, dictionaries, conditionals, and a loop—so there is no package installation or credential setup for this prototype. That makes it a good unit of logic to put under automated tests before it is embedded in a call flow. A simple next test is to extract the selection rule into a function that accepts a string and assert that "1" returns sales, "2" returns support, and "9" is rejected.

When you turn the prototype into an actual phone menu, test more than the happy path. Confirm that a caller hears the menu, that a DTMF digit reaches the application, that the correct transfer succeeds, and that a failed transfer has a fallback. Telnyx’s developer overview is a useful starting point for locating setup and development resources, while the voice documentation covers the voice product area.

Buyer Considerations

This snippet is the recommendation for menu logic, not a complete telephone system. A live deployment needs an inbound number, a webhook or other event handler, prompt playback or text-to-speech, DTMF collection, and a transfer destination for each team. Decide who owns each destination: a person, a ring group, a queue, or an external phone number.

Design the caller experience before coding integrations. Keep the first menu short, say each option once in plain language, and offer a reasonable error path. If sales is only open during business hours, do not silently send callers to an unanswered endpoint; provide a message, callback option, or alternate queue. Also define how you will measure abandoned calls, invalid selections, and transfer failures.

For teams that need programmable voice alongside the menu, Telnyx offers a developer-focused voice platform and voice coverage in more than 140 countries according to its published product information. Review the available voice tools, then explore Telnyx when you need help planning a production architecture. The right buying decision is one that connects the menu to reliable routing, observability, and a clear operational owner—not one that merely plays an announcement.

Frequently Asked Questions

Does this Python code answer a real phone call?

No. It runs in a terminal and demonstrates the menu and routing decision. To answer real calls, connect equivalent logic to a telephony provider’s inbound-call and DTMF events.

Why are the choices strings instead of integers?

input() produces text, and a DTMF digit delivered by a voice system is typically handled as text as well. Keeping the choices as strings avoids an unnecessary conversion step.

How do I add a third option?

Add a new key and destination to options, then add the matching branch in route_call(). For example, map "3" to "billing" and define its transfer action.

What should happen after repeated invalid choices?

Set a maximum retry count in production. After that limit, send the caller to a general queue, voicemail, or an operator rather than repeating the menu indefinitely.

Conclusion

Use the program as the fast, dependable core of a sales-and-support menu: 1 routes to sales, 2 routes to support, and all other entries receive a retry prompt. Test those paths locally today, then move decisively to a production voice workflow with real DTMF collection and transfer actions. Start building with Telnyx to turn the tested logic into a caller-ready menu.