Feasibility is the process of searching for available boxes at an address to make a new sale. Feasibility is typically conducted using a search standard based on poles (adjacencies), where you first select the pole and then the box. However, it can be set to perform feasibility by radius or manually, as you can see in this tutorial. For sales in condominiums, please refer to this other tutorial.
Below, we will provide examples to teach you how to check the feasibility of a specific address to complete a sale using the OZmap API.
From here, we will assume that you understand the difference between these two feasibility types. If you have any questions, don't hesitate to contact the OZmap support team.
To make it easier to understand, we will create an example scenario.
Initial scenario
According to the example mentioned above, you want to make a new sale and need to check the available boxes that serve the customer in that region, and the sales team from the ERP already has all the necessary data of the new customer, including the address and name of the customer
➡️ Example
A customer who wishes to sign a plan with the provider access the portal and contact the provider’s support.
The provider's chatbot will request all the necessary data from the customer to complete the sale since it is a new customer.
After collecting the data, the chatbot will contact OZmap to check the customer feasibility at the address.
Below there's a flow to facilitate the understanding:
...
Using the information returned by OZmap, the chatbot can decide what to inform the customer.
🔗 API
The next step is to figure out how to call OZmap and get the feasibility information at a specific address.
Here is an example:
After identifying the customer as new, we have the customer’s address. For this example, let’s assume the address is: 720 Michigan Avenue, Chicago, IL -- 60605, United States
. However, the API only accepts latitude, longitude, and radius, so they must be provided.
To get the latitude and longitude of an address, click on this tutorial.
The latitude and longitude being: 41.87252057124877, -87.62489949084207
, and radius: 100
, the query to OZmap would be made like this:
Code Block | ||
---|---|---|
| ||
curl -X
GET "https://sandbox.ozmap.com.br:9994/api/v2/ftth-viability?radius?lat=41.87252057124877&lng=-87.62489949084207&radius=100" /
--header 'authorization: AUTHORIZATION_TOKEN' |
The expected response for this lat and long is:
Code Block | ||
---|---|---|
| ||
{
"viable": true,
"boxes": [
{
"distance": 30.41,
"name": "CTO 22-05",
"id": "5dc06d1275fc7d0006732521",
"project": "5d51a87046cbe700148328bf",
"lat": 41.87252057124877,
"lng": -87.62489949084207,
"implanted": true,
"availability": 6,
"horizontal_condos": []
}
],
"refused_boxes": [],
"properties": [
{
"id": "6168210a1692a900135b628d",
"address": "720 Michigan Avenue, Chicago, IL -- 60605, United States",
"observation": "This property was disconnected when a new client was created in this box. The previous connection for this property, identified as 'SS 22-05 - Port 2,' now belongs to client 38742|217968.",
"lat": 41.87252057124877,
"lng": -87.62489949084207,
"box": "5dc06d1275fc7d0006732521",
"project": "5d51a87046cbe700148328bf",
"horizontal_condos": []
}
]
} |
Note that in response the viable information is marked as “true”.
With this information, the Chatbot could, for example, give a standard response to the customer, indicating that there's availability to sign up for a plan at their address. If they are interested, they could be directed to contact the provider's sales department or make a reservation using the viable options.