@User Call ID: 0199bdee-fed5-7228-9759-e8de12dfaf60 (one of many): Agent is prompted to read back the phone number or license plate no for error checking to the user and reads last digits as a date or like e.g. "fifth" etc. Happens mostly when user spelled like "plus four nine.....fourteen twenty five" -> agent reads back "2nd of May" and sometimes "fifth" for the last digit! Users hang up, after agents repeats same error over and over, even when user corrects the agent. (Same happens on license plate information, the last digits are read back as a date, if the user spells it not as digits (and even if user spells it clean as single digits, it happens and agent says e.g. "fifth" instead of "2nd of may"..) It is not possible to fix this reliably via prompting!! I have tried 100´s of Variants and also what one of you mentioned to someone else posting the same issue (https://discord.com/channels/1211482211119796234/1417093711178764388) Somewhere in the VAPI logic (not the Deepgram transcriber) there is a "." added right after the last digit of a (phone) number the user spelled and the agent reads it back including the "." -> hence as a date, despite the prompt forbids it. -> Reporting this as a bug to Vapi support since it appears to be unintended behavior!! I assume: Somewhere on the transcript Vapi puts a '.' Behind the last term the user spelled even if punctuation setting is set "off" in deepgram - it seems to happen on the Vapi side. Then when re reading the number assistant says fifth or 2nd of may. Numerals is on etc. etc. I spent like 100 hours to fix this with Formatingplan etc. settings but no chance. We kindly ask you to get this fixed or provide a solution, as our clients complain that users hang up, being annoyed by the agent not even understanding a phone number.

Hey, I’ve seen this issue before — it’s usually not from Deepgram but from how Vapi formats or normalizes numeric text before playback. I can help check where that extra “.” gets added, likely in transcript or assistant rendering. Could you confirm if it only happens when the assistant reads back variables like {{customer.number}} or also with direct speech from memory? That will help narrow whether it’s a formatting or parsing issue in Vapi’s logic. @AiforYou

Hey LordXcel, thanks for your reply! You nailed it, it is not from Deepgram, but from Vapi normalizing / formatting. And it happens literally NEVER with {{customer.number}}, only if user spells a different number. In that case, the bug happens like 20-30% of the time when the user spells his number digit by digit +1 8 8 5 5 4 4 - and like 70% of the time if the user spells * + 1 eighty eight, fifty five, fourtyfour." then it apparentyl formats it to *+1 88 55 4 4. and reads all numbers correct, until the last two, which it interprets as 4th of April at the end. (even if the prompt is extremely clear, not to interpret dates, delete the "." etc etc. Any ideas or help how you fixed this would be very much appreciated.

Hey, I’ve seen this before — it happens because Vapi adds a small punctuation mark or space after grouped numbers, which makes it sound like a date. The fix is to clean and normalize the number right before it’s read back, removing any hidden dots or spaces. I can help you set this up and test it directly. Let’s discuss privately so we can sort it out quickly. @AiforYou

@Vapi can you please fix this bug?

We apologize for the delay in responses lately. We are in process of making some changes to our workflow in how we handle support requests. The good news is that we are starting to get back on track of having a 48 hour response time and we would like to start cleaning up anything old. With that being said, just wanted to check in with you to see if you have made any progress or changes to your project since support has last reached out.

Sadly not Kyle, the problem persists. Get in touch for more information please ! As soon as someone gives a number (like Phone number or License Plate) in grouped form (like fourtenn - 14 - instead of 1,4) the assistant reads it back as a date, as the VAPI platform inserts a "." behind the user input. Even trying to normalize the input and deleting the "." does not always work, as the "." gets reset behind the normalized string, as soon as the AI outputs the string.

Hi Sentinel, Thanks for the additional details — based on what you’re describing, you can try two potential mitigations while we investigate the root cause on the Vapi side. 1. Use regex replacements to strip trailing periods and re-format grouped numbers before they are spoken:

{
  "voice": {
    "chunkPlan": {
      "formatPlan": {
        "replacements": [
          {
            "type": "regex",
            "regex": "(\\d+)\\.",
            "value": "$1",
            "options": [
              {
                "type": "global",
                "enabled": true
              }
            ]
          },
          {
            "type": "regex",
            "regex": "(\\d{2})\\s",
            "value": "$1, ",
            "options": [
              {
                "type": "global",
                "enabled": true
              }
            ]
          }
        ]
      }
    }
  }
}

This removes any unintended “.” after digits and also forces clearer separation between double-digit groups so the TTS model is less likely to interpret them as dates. 2. Alternatively, switch to a different voice provider (Cartesia) with a larger chunking window:

{
  "voice": {
    "provider": "cartesia",
    "chunkPlan": {
      "punctuationBoundaries": [",", ";", ":", ".", "!", "?"],
      "minCharacters": 40  // Larger chunks = better context for number pronunciation
    }
  }
}

Cartesia tends to be more literal when reading raw digits and less likely to reinterpret grouped numbers as dates. Let me know if you’d like help testing either configuration in your assistant — happy to check logs or run live test calls with you. Best, Kyle ---

Hi Kyle, you are simply awesome! Really! Your answers are the best and most helpful. I already used such regex expressions in the prompt, however with prompting the regex , the issue persists if user corrects his input. Your solution to set it as part of formatplan is just brilliant! Only issue now: I am unsure how to set the options "[{"type": "global", "enabled": true}]" via the VAPI API reference tool. It only offers me the options you see in the screenshot below. Not "global". -> Can we schedule a really quick and short 5 minute call so you guide me through the process of setting it correctly with the API reference tool? The only Options I see there are "ignore-case" , "multiline" or "whole-word" - but not "global" - I would like to implement the regex formatplan with you. Thanks in advance! Please let me know a weekday for this week and GMT+2 Time you would be available and let me know how to privately DM you a google meeting link to chat. This should not take more than 5-10 minutes. THANK YOU!

Sorry about that. I would use

multi-line

instead of

global