Suresh work

[sojharo]

I am opening this to discuss what we can give to Suresh. Here is the email of Suresh.

Hi Sojharo Here are the scenarios I have attached. Our goal is to initial do batching.

1. All CRM Chat Reps maintain Kibo keys, so when we click Kibo admin console, it won’t prompt user for login.
2. We will have a sync button or windows service, we periodically call for all the incidents in Kibo. a. Need all new incidents with activities (chat conversation) b. Any existing incident with return user chat conversation c. Need by Unique ID or time to get the delta.
3. Ability to create new Group and Sub-Groups.
4. Ability to create a Kibo Support user from CRM

Once this is completed, eventually we can focus how to enable web hooks from your app, as soon as chat is ended you can call our webhooks.

Our goal is to compelte this prototype in a weeks time. So please let us know whether it is realistic timelines? If so lets work on this timeliens.

[sojharo]

Response:

1. All CRM Chat Reps maintain Kibo keys, so when we click Kibo admin console, it won’t prompt user for login. (This part would require additional work on our side, one week deadline would not be sufficient. The main work would be to know which role is logged in from your CRM and what resources should be authorised for such role. Current API has the scope of admin.)
2. We will have a sync button or windows service, we periodically call for all the incidents in Kibo. (We can allow a generic webhook defined on your server that our server will call to notify about incidents, it would contain the "type" parameter to let you know what type of data it is sending. There are several types of incidents happening on kiboengage. i.e. customer asked for help, customer session was resolved, customer session was assigned an agent. Therefore, need to discuss this more and need more clarification on this) a. Need all new incidents with activities (chat conversation) b. Any existing incident with return user chat conversation c. Need by Unique ID or time to get the delta.
3. Ability to create new Group and Sub-Groups. (We have API endpoints for both of them and we can expose them in the documentation)
4. Ability to create a Kibo Support user from CRM (We have the API endpoint for this and we can expose this)

FROM DECK Click to Chat – when is in offline – we need copy of the email sent to appropriate queue (eg: Sales, Service, Real Estate)

(We currently send email only to admin for such incidents. We can call webhook of CRM with required information and CRM manages to send email to appropriate queue.)

[sojharo]

I have completed the work on this and have made the following document that we can send to them. Please review.

https://docs.google.com/document/d/17kFFK1RgJFf4S-0r4DK5f48NNfh8glFMexZwQHujEm8/edit

[sojharo]

I have started work on this and it is under construction. I have made endpoints to setup the webhook. The part to doing authentication with their CRM is under construction. Also, I am working on endpoints to call their webhook whenever an incident happens. It will take me 2 days to complete this work. Some tasks are defined in the document above and some tasks are discussed in the email.

Following are discussed in email:

• We need to find a way to store the session id in Kibo, whenever the CRM is unable to reach.
• Need webhook to retrieve the undeliverable session id's from Kibo.
• From CRM, We will be providing one web hook, using that Kibo can communicate the session id.

[sojharo]

I have worked more on this task yesterday. I wrote the logic to use the webhook in some places where it should send info to CRM. I had to spent some time on this issue as headers authentication was crashing the application for other clients. I am trying to make authentication such that it works both for CRM and kiboengage as well. This is the final task in this issue which I am trying to solve.

[sojharo]

I have completed the work on this and now completing the document. I will send the email to Suresh today IA.

[jekram]

Thanks