II. DROZ BOT IMPLEMENTATION - LEVEL I

Scope

• Configuration of up to 3 chatbot flows with up to 20 blocks for WhatsApp and/or Web channels in total;
• Configuration of handoff to Zendesk Suite (Licenses and contracting are separate);
• Configuration of up to 10 native connectors already available and operational;
• 1 Remote training session of up to 2h with focal points defined by the contractor in a remote model;
• 1 day of remote monitoring during the Go Live of the Chatbot service flow.

Methodology

• Kick-off: Initial meeting for the presentation of the contracted scope, teams, project methodology, and next steps;
• Workshop: Agenda to present an overview of the platform(s) to be implemented in the project to those involved, to facilitate understanding regarding the necessary implementation requirements;
• Discovery: Agenda(s) to understand in detail the needs and priorities for the implementation or development of the platform(s) we will work on in this project. In this stage, we will have the requirement documents filled out by the CONTRACTING party and by our projects team;
• Setup: Configuration of the contracted platform(s);
• Validation: Validation activities and adjustments after the delivery of the setup and/or development. Validations must be carried out by the CONTRACTING party according to the dates planned in the schedule, and adjustments must be carried out by our projects team as planned in the schedule. There may be agendas for joint validation and adjustments (CONTRACTING and CONTRACTED parties), however, agendas will be limited as described in this project scope;
• Training: Training agendas for the service team or platform(s) administrators according to the project scope, which may have 1 (one) or more classes depending on what is described in the project scope;
• Go-live: Monitoring by the project team (CONTRACTED) during the day of the switch to production and 1 (one) or more days of monitoring after the Go-live, depending on what is described in this project scope.

Premises

• All contracted hours must be transformed into projects with a closed scope, and hours cannot be used for loose demands, without planning or a schedule;
• All hours consumed by the projects team will be deducted from the hour package, i.e., hours consumed for scope survey, planning and re-planning of activities, schedule updates, alignment meetings (internal or with the client), project documentation, status report (internal or with the client), study of solutions, configurations, and developments;
• The number of hours offered in this proposal does not guarantee the completion of all projects/needs presented by the client; the hours for each project will be informed at the beginning of the project after the scope survey carried out by our projects team; if necessary, more hours may be contracted to finalize the scope;
• The client must provide a professional as a focal point dedicated to the project;
• For projects involving products, configurations and features are restricted to the contracted licensing and their respective permissions;
• Availability of those involved, on the part of the client, to participate in mapping agendas, work meetings, and validation and presentation agendas, according to the schedule and alignment of previously agreed dates;
• Collaboration of the client's IT team in resolving doubts and/or requesting information;
• The implementations of the flows will follow the characteristics and functioning of the Droz Bot solution, and there may be limitations and/or distinct functioning from what was defined in the flow agreed upon with the client;
• All and any necessary adjustments in internally developed integrations will be the responsibility of the client;
• Integrations will be made via connectors using the platforms' Rest API;
• For the configuration of the integrations, the client will need to provide updated Rest API documentation, access credentials, and dummy data for testing and validation;
• Calls outside of business hours or on non-working days (we consider weekends, national holidays, and bridge days) are not foreseen;
• Sharing of process documents (flowcharts), when available;
• The client must validate and approve the chatbot flow document (conversational tree) presented by our projects team;
• Up to 3 client feedbacks regarding adjustments to the chatbot flow document (conversational tree) are included, i.e., the client must consolidate the adjustments and send them to the projects team up to 3 times during the validation period as planned in the project schedule;
• Once the chatbot flow document (conversational tree) has been validated by the client and passed to the team to implement, new adjustments to the chatbot flow document (conversational tree) will not be accepted;
• To implement the WhatsApp channel, the client must already have the number released and registered in the Zendesk instance;
• Only numbers registered in the Zendesk Suite and in operation will be accepted;
• Conversational flows in other languages: the translation of texts used by the Droz bot must be provided by the client;
• For integrations, the endpoints must be in REST API format;
• Documentation to start API testing must contain the following information (for each endpoint):
  • Authentication method;
  • URL;
  • HTTP Method;
  • Request payload (header and body fields, which values and which formats the parameters should be sent in, etc.);
  • Return response (which fields are returned, error status, etc.);
• For the returns, we need to know: Which fields will be used; The conditions and treatments of the information in this field; What should be presented to the user and how.
• The client needs to provide test credentials so that our team can validate and use them during the development of the application;
• The client must provide use cases (data that allow for queries that bring the expected return values from the API);
• Droz recommends as a best practice that a homologation environment for the endpoints also be provided;
• For WhatsApp bots and/or other social networks (e.g., Facebook, Instagram, Twitter, etc.) that include integration with Zendesk, each channel needs to be registered within the client's instance. Once registered in Zendesk, in the “Conversations API” section, credentials must be generated for activation in Droz. If the aforementioned section is not enabled in the instance, the client must request the release of this feature from Zendesk support via email;
• Activation of the Droz instance for the client and creation of an admin user for the Implementation Consultant;
• The transfer of the conversational flow must be sent in an unaltered file. (If the client needs to change it, the original flow must be validated).

Method

• Together with the client, we will review the entire flow sent, along with the API documentation, and validate if they are in accordance with the features of the Droz Bot platform;
• Agendas for understanding the flows must take place with the client, as they are the ones who have the business knowledge.

Configurations

• Configuration of the self-service flow on the Whatsapp channel;
• Integration for handoff in Zendesk;
• Configuration of templates for active (outbound) messaging;
• Configuration of connectors for integration with other platforms.

Validation/Adjustments

• Joint agendas with the client, in which the flows and their integrations will be presented for client validation. If necessary, refinement adjustments can be made;
• After the material/document is validated, no changes to it will be allowed;
• After the Droz Bot platform configurations (Setup), we will have the validation and adjustment phase, remembering that we will follow the flow documentation validated by the client.

Out of Scope

• Design of AS IS and To be;
• Integration architecture;
• Playbooks of the service processes;
• Texts that will be used in the Droz bot;
• Creation of templates for active (outbound) messaging in Droz Bot;
• Configuration of Droz Base and Droz AI;
• Configuration of NLP;
• Material for technical training of the Droz bot;
• API development.

Configuration of standard connectors

• Connector for integration with Zendesk Support: Through this connector we can create a ticket in Zendesk;
• Connector for handoff to Zendesk Chat: Through this connector, it is possible to hand off the service to a human and define the operation hours directly in the bot before transferring to the Widget.

Configuration of self-service flows (Blocks)

• Flows containing a decision tree, i.e., automated question and answer flows, being able to use content from articles or direction to content links;
• Smart flow containing integrations with other platforms and automation in the service through artificial intelligence and/or NLP (Natural Language Processing), i.e., flows that allow the client to consult information in different systems automatically, write questions or make requests and have answers quickly and assertively, without needing to interact with a human.

Chatbot configuration for active (outbound) messaging

• Configuration of templates to actively send mass messages on the WhatsApp service channel, acting in an efficient and automated way.

III. DROZ BOT IMPLEMENTATION - CUSTOMIZED

Scope

• Detailing of the Customized implementation scope is detailed in the SO document, according to the survey and analysis carried out by the Droz team.

Methodology

• Kick-off: Initial meeting for the presentation of the contracted scope, teams, project methodology, and next steps;
• Workshop: Agenda to present an overview of the platform(s) to be implemented in the project to those involved, to facilitate understanding regarding the necessary implementation requirements;
• Discovery: Agenda(s) to understand in detail the needs and priorities for the implementation or development of the platform(s) we will work on in this project. In this stage, we will have the requirement documents filled out by the CONTRACTING party and by our projects team;
• Setup: Configuration of the contracted platform(s);
• Validation: Validation activities and adjustments after the delivery of the setup and/or development. Validations must be carried out by the CONTRACTING party according to the dates planned in the schedule, and adjustments must be carried out by our projects team as planned in the schedule. There may be agendas for joint validation and adjustments (CONTRACTING and CONTRACTED parties), however, agendas will be limited as described in this project scope;
• Training: Training agendas for the service team or platform(s) administrators according to the project scope, which may have 1 (one) or more classes depending on what is described in the project scope;
• Go-live: Monitoring by the project team (CONTRACTED) during the day of the switch to production and 1 (one) or more days of monitoring after the Go-live, depending on what is described in this project scope.

Premises

• All contracted hours must be transformed into projects with a closed scope, and hours cannot be used for loose demands, without planning or a schedule;
• All hours consumed by the projects team will be deducted from the hour package, i.e., hours consumed for scope survey, planning and re-planning of activities, schedule updates, alignment meetings (internal or with the client), project documentation, status report (internal or with the client), study of solutions, configurations, and developments;
• The number of hours offered in this proposal does not guarantee the completion of all projects/needs presented by the client; the hours for each project will be informed at the beginning of the project after the scope survey carried out by our projects team; if necessary, more hours may be contracted to finalize the scope;
• The client must provide a professional as a focal point dedicated to the project;
• The implementations of the flows will follow the characteristics and functioning of the Droz Bot solution, and there may be limitations and/or distinct functioning from what was defined in the flow agreed upon with the client;
• For projects involving products, configurations and features are restricted to the contracted licensing and their respective permissions;
• Availability of those involved, on the part of the client, to participate in mapping agendas, work meetings, and validation and presentation agendas, according to the schedule and alignment of previously agreed dates;
• Collaboration of the client's IT team in resolving doubts and/or requesting information;
• All and any necessary adjustments in internally developed integrations will be the responsibility of the client;
• Integrations will be made via connectors using the platforms' Rest API;
• For the configuration of the integrations, the client will need to provide updated Rest API documentation, access credentials, and dummy data for testing and validation;
• Calls outside of business hours or on non-working days (we consider weekends, national holidays, and bridge days) are not foreseen;
• Sharing of process documents (flowcharts), when available;
• The client must validate and approve the chatbot flow document (conversational tree) presented by our projects team;
• Up to 3 client feedbacks regarding adjustments to the chatbot flow document (conversational tree) are included, i.e., the client must consolidate the adjustments and send them to the projects team up to 3 times during the validation period as planned in the project schedule;
• Once the chatbot flow document (conversational tree) has been validated by the client and passed to the team to implement, new adjustments to the chatbot flow document (conversational tree) will not be accepted;
• To implement the WhatsApp channel, the client must already have the number released and registered in the Zendesk instance;
• Only numbers registered in the Zendesk Suite and in operation will be accepted;
• Conversational flows in other languages: the translation of texts used by the Droz bot must be provided by the client;
• For integrations, the endpoints must be in REST API format;
• Documentation to start API testing must contain the following information (for each endpoint):
  • Authentication method;
  • URL;
  • HTTP Method;
  • Request payload (header and body fields, which values and which formats the parameters should be sent in, etc.);
  • Return response (which fields are returned, error status, etc.);
• For the returns, we need to know: Which fields will be used; The conditions and treatments of the information in this field; What should be presented to the user and how.
• The client needs to provide test credentials so that our team can validate and use them during the development of the application;
• The client must provide use cases (data that allow for queries that bring the expected return values from the API);
• Droz recommends as a best practice that a homologation environment for the endpoints also be provided;
• For WhatsApp bots and/or other social networks (e.g., Facebook, Instagram, Twitter, etc.) that include integration with Zendesk, each channel needs to be registered within the client's instance. Once registered in Zendesk, in the “Conversations API” section, credentials must be generated for activation in Droz. If the aforementioned section is not enabled in the instance, the client must request the release of this feature from Zendesk support via email;
• Activation of the Droz instance for the client and creation of an admin user for the Implementation Consultant;
• The transfer of the conversational flow must be sent in an unaltered file. (If the client needs to change it, the original flow must be validated).

Method

• Together with the client, we will review the entire flow sent, along with the API documentation, and validate if they are in accordance with the features of the Droz Bot platform;
• Agendas for understanding the flows must take place with the client, as they are the ones who have the business knowledge.

Configurations

• Configuration of the self-service flow on the Whatsapp channel;
• Integration for handoff in Zendesk;
• Configuration of templates for active (outbound) messaging;
• Configuration of connectors for integration with other platforms.

• Validation/Adjustments

  • Joint agendas with the client, in which the flows and their integrations will be presented for client validation. If necessary, refinement adjustments can be made;
  • After the material/document is validated, no changes to it will be allowed;
  • After the Droz Bot platform configurations (Setup), we will have the validation and adjustment phase, remembering that we will follow the flow documentation validated by the client.

  Out of Scope

  • Design of AS IS and To be;
  • Integration architecture;
  • Playbooks of the service processes;
  • Texts that will be used in the Droz bot;
  • Creation of templates for active (outbound) messaging in Droz Bot;
  • Configuration of Droz Base and Droz AI;
  • Configuration of NLP;
  • Material for technical training of the Droz bot;
  • API development.

  Configuration of standard connectors

  • Connector for integration with Zendesk Support: Through this connector we can create a ticket in Zendesk;
  • Connector for handoff to Zendesk Chat: Through this connector, it is possible to hand off the service to a human and define the operation hours directly in the bot before transferring to the Widget.

  Configuration of self-service flows (Blocks)

  • Flows containing a decision tree, i.e., automated question and answer flows, being able to use content from articles or direction to content links;
  • Smart flow containing integrations with other platforms and automation in the service through artificial intelligence and/or NLP (Natural Language Processing), i.e., flows that allow the client to consult information in different systems automatically, write questions or make requests and have answers quickly and assertively, without needing to interact with a human.

  Chatbot configuration for active (outbound) messaging

  • Configuration of templates to actively send mass messages on the WhatsApp service channel, acting in an efficient and automated way.

  .