Here's the feedback directly from the client:
Read a detailed review from our valued client here
An AI-based platform that integrates Rep360 bots with the GHL workflows to manage automations.
How does Rep360 AI work?
GHL admin sets up the workflow with the BotId as a parameter created inside their Rep360 account. When the workflow is triggered against a selected lead (channel: SMS or email), a webhook endpoint is triggered on the Rep360 end with the WorkflowId, BotId and lead data passed into it as arguments. The magic then transfers to Rep360’s end, where it creates a new thread in OpenAI assistant. We create a prompt with all the FAQs (knowledge database), scripts, booking conditions, follow ups and which data to extract from the selected bot and ask OpenAI’s selected model to generate a message for the user, which is then sent to the lead in response handled at the GHL level. As a result, the selected lead gets a new AI-generated message on their phone.
Example: Hi Jorge, this is Jorge from Renewal by Andersen. I just wanted to quickly check in after your installation. How did everything turn out?
When they reply back to the message, a webhook on Rep360 is called again with their reply and other required arguments. Since this time, the thread already has context or prior messages, it understands what’s happening while generating the reply.
Lead Example Reply: Hi Jorge Thank you for checking in. We are very pleased with the way the windows reduce outside noises and moderate the temperature. A couple of the windows have grids that don’t line up. It’s a manufacturing defect that’s very noticeable. We would like to get those defects corrected. Otherwise, the project went very well. You have a very good crew
The extract data section comes in handy when the user shares any information that we want to extract. If the bookings are enabled and the booking condition is met based on the agent’s availability, a booking is added to the GHL calendar. Similarly, a follow-up is scheduled if the conditions are met. We also have the stopping conditions at the bot level, which, when met, stop the bot for any further communication or activity. The stopping conditions are handy in situations like when the customer isn’t interested in the offering or has already bought the product or the service.
Whenever the extraction conditions of data are met, the system adds the specified tag to the lead. To understand this, here’s a condition specified in the bot for the variable name “Issue”
Set to True if the client spontaneously reports a current, unresolved problem with their units, without bot prompting. Set to False if the issue is prompted, past, resolved, or not mentioned.
When the prompt is executed and a response is received, if the above condition is met, a variable named “Issue” will be set to true and as a result, the variable “issue” in this case gets added to the lead as a tag in the GHL. As a result, another workflow is executed inside the GHL automatically, where it was specified to run this workflow when the “issue” tag is added to a lead.
The Challenge:
The challenges during the development and deployment of Rep360 were by far the most we encountered in any application because to make it 100% work, it had to succeed on a lot of different areas in parallel. GHL continuously updated their APIs and infrastructure so working things broke quite a few times without making any changes. A few important challenges and milestones we achieved in the development were:
- GHL admin account connection with Rep to synchronise all subaccounts/locations.
- The passing of information TO and FRO from GHL to Rep360 and back. The multiple things that needed to be checked were if the booking conditions are met and if they are, pass the agent’s availability on the selected calendar. Give users 3 times from the available slots in the selected timezone (which caused a lot of issues). Once everything was met, a booking would be added to the GHL’s calendar of the agent. Similarly, stopping conditions, scripts, follow-up messages and times, issue extractions and tags management on the lead were a few others that should get a mention here.
- At the time of development of Rep360, GHL didn’t provided a way to directly fetch the “From” number (from which the messages would be sent) so we had to establish another route to pick that number from Rep360 admin screen.
- Identifying the right variables. This was one of the benchmarks of this product if it was successful or not at the time of delivery. All variables had a descriptive condition and an outcome value. For example, here’s the condition “Set to the client’s follow-up date in MM-DD-YYYY format if they provide a specific date or timeframe (e.g., “03-15-2025,” “6 months” = 6 months from conversation date). Default to 6 months from conversation date if unclear. Leave unset if no follow-up is requested or declined”. If it is met, set the value in a variable called “Follow Up Date” which will then be added as a tag on the lead for further processing.
The following attachment shows how a bot could be edited in the Rep360.ai. A bot has a name, a unique name, a business name and a type, which are used when sending the initial message. You also have to define which GPT model you want to use that is GPT 4o in this case followed by the base instructions for the OpenAI assistant. The last thing the user can set is the response delay which is between 1 to 300 seconds (up to 5 minutes) to give it a more realistic human reply. The BotId is what will connect the Rep360.ai with the GHL workflow so keep an eye on that.
A bot can have what we call a knowledge database of FAQs to help assist in structuring better responses. These FAQs are passed to the OpenAI model so incase the customer asks a similar question, AI has a reference in its reply.
The following attachment shows the booking conditions that the bot has. A bot can have multiple booking conditions which are evaluated at the time of executing the prompt by OpenAI model. The user has to select a GHL calendar from the list from which the agent’s availability will be read from. The customer will be given a few predefined booking dates from this calendar incase any of the booking conditions are met.
The screen allows the agent to define the most critical configuration of the bot which are instructions. The bot is required to follow these instructions and all major cases should be covered. The bot is intelligent enough to generate the wording of the message based on the instructions as its context to lookalike human.
The follow ups are next thing in this configuration puzzle. The active hours are the hours for this bot in which it will be active so in the given screenshot, the bot will only reply or generate messages between 7 to 9PM PST. The follow ups defined in the second half of the screen gives users the ability to set the frequency and the instructions. For example, send the following message after 7 days of no-reply from the customer. User can define multiple of these follow ups.
This is the last step in the bot configuration which opens up a whole new dimension of linking the outcome of this workflow with other GHL workflows. In this section, the user defines when, which and how the data will be extracted and added to the customer/lead as the tag inside the GHL. The description is the condition of how and when and the variable name is the name of the tag that will be added to the customer’s GHL entity. The value of this tag will be extracted by the OpenAI model itself and provided in the response.
The following screen shows the conversation happening with different customers or leads using the application.
After we have configured everything inside the Rep360.ai, its time to now setup the GHL workflow. For that, we created an application with a custom action. The inputs of this action is the BotID which is the ID of the bot in Rep360 and the list of communication channels which in 99% of cases will be SMS. The action’s configuration in the development console allows you to configure the webhooks and other important things behind the screen.
