Hey lovely community! A few of you were asking about how to reliably extract any required information from users while the AI is actively having a conversation beyond just basic name, email, and phone. While we already have tools for standard fields, the most powerful and reliable approach for advanced, custom, or business-specific data collection is using Automatic Data Extraction (Map Custom Fields) instead of Extraction Tools. Here's the guide on how to do it- https://help.assistable.ai/how-to/how-to-gather-and-extract-important-user-information-using-automatic-data-extraction @Ryan B hope you find this useful. This directly solves the data capture reliability issue you were facing

For a client I set up an ai receptionist. But IMO the performance is pretty poor. Bad enough that most customers will be frustrated with it. She can't get the email correct even though it was spelled out a couple times, then she muffs the street name, and reads the address number like it's math class. Is this the best we can expect? Or what can be done here? Also, why does she sometimes run sentences together without pausing? Thanks for any tips! See call attached.

So, its been a long process and a lot of work - literally re-writing our voice orchestration to be native - and we still have a small sprint before we will start flowing traffic that way. Here is just a general guide of somethings that will change, be added and be deprecated. So, rollout. first - the users using our numbers will start seeing the traffic flow first. Then older numbers. Then trunked numbers. Nothing tangible changes from your perspective besides lower latency. Tooling - So, we are adding POST / GET / PUT / PATCH / DELETE to api request types. We also have it where you can configure headers, query parameters, path parameters and body parameters. So, fully customized API calls. We will suppose variables in these as well so you can pass API keys or your access token for GHL. Here's the thing, tools is now running through a proxy of ours that will open up the doors for a couple things: - Tools to run as they do today - Direct API calls (will be a toggle), so instead of being wrapped in a args object with metadata, etc - we will just send the API call. This gets rid of the need for middleware because you can make direct API calls. - Workflow execution; not today or the next week but we are adding native workflows to the platform. You can configure a custom tool to trigger a workflow locally to run multi-agent frameworks and basic automation so we will support a middleware internally. Abilities - all stays the same, but we are adding agent teams in voice (chat following right after). So, add different assistants into call to create a team env on the call either through a "prompt change" so we just change the prompt dynamically, or through a team so mutliple voices, etc. AI Models - We will be running a custom fine-tuned model thats been fine-tuned for voice orchestration. aka, this llm outputs text-to-speech friendly output to keep weird translations to a minimum. You will be able to select an OpenAI model if you would like and run it with your key if you prefer OpenAI output.

I have a client with two locations and two different phone numbers to put on two different landing pages... Can I have a single bot answer both numbers (I would forward the two different GHL numbers to the same Assistable bot phone number)(I assume I can have two different GHL numbers forward to the same number... correct?) Or should I create two bots and just use the actual Assistable ai phone number(s) on the landing pages (vs. forwarding from a GHL number)?

No more spam bot calls ... Only real people get through. User have to select “I am human” before they reach your AI or AI call them back.