Leading Beverage Company

Leading Beverage Company


PowerObjects engaged with the customer through Microsoft to complete a CRM online implementation for their call center. The call center handles customer service tickets from some of their large chain brands/stores, so based on what the product is, who the customer of our client is, and what their issues are, different information is displayed on the support case to ensure proper routing for escalations. Some examples of the kinds of calls the call center receives include out of product, out of promotional product, RSR issues, no service (missed schedule day), equipment issues, new store opening or closing, billing issues, etc.


PowerObjects built out solutions for their needs in CRM and used custom pieces to satisfy the requirements. PowerObjects installed CRM and assisted the customer with setting up the infrastructure; helped the customer outline their business process and documented them via flow charts and word documents; and then utilized a Secure File Transfer Protocol 000(SFTP) between the customer and their third party appeals generator in which the third party would upload documents and the .NET code that PowerObjects created would fire every night to check for documents in the SFTP.

If the code found SFTP, it would run the document through a series of logical checks. If it triggered on one of the logical checks, the code would take the appropriate action on the document, read the document, parse out the information into an appeal entity record in CRM, and then create the appeal entity record. Next, the code PowerObjects wrote would move the document out of the SFTP folder into a “processed” folder.

Additionally, PowerObjects built a case stage and case structure entity for each appeal. Each appeal could be in a single case stage and a single case status at any given time. JavaScript checks the case status and stage onload of the form and also checks the logged in users’ security role and team. If a user had the appropriate team/security role combination, as per the case stage/status, they would be able to edit and see fields. If the user did not have the appropriate team/security role combination, they would either not be able to see the record or they would not be able to edit the fields and would only be able to view limited fields. This was laid out in their business process by PowerObjects.

Key Benefits

PowerObjects built buttons that would route appeals to users. PowerObjects created separate buttons for each “Group” that the customer had. For example, if you were in Group ABC, you could click the “Assign me ABC Appeals” button. Once clicked, code would fire and find the oldest possible appeal and assign it to the user. PowerObjects also built custom buttons for the user to click when they were ready to move the appeal to the next stage. Once clicked, the appeal would be sent to the next feasible stage, based on what information was entered. in the form. Button display/enable rules were utilized heavily to drive what each user could view and edit in terms of buttons since different privileges existed for different roles.

PowerObjects built a random-number generator for unique ID numbers and built code that would push 20% of appeals that were marked as “Complete” to a QA bucket, where the appeal would then get reviewed by the QA Team. The QA Team had separate set up buttons and viewing rights that PowerObjects had to construct. Once an appeal was finalized, a plug-in was built that would transfer the information into a PDF letter format and store it in SharePoint. From there, code would fire each night to look for Documents in the SharePoint folder. The code would take the found PDF documents, run them through logical checks, and uploaded them to an outgoing SFTP folder. This process sent files back to the third party after they had been run through the business and appeal review processes by the customer’s users. If the third party approved the results, that appeal was completed. However, if the third party determined that changes needed to be made, they would send the file back with an “R” appended to it. Code checked for documents marked “R” in the SFTP, find the existing Appeal that had been previously completed in CRM, and re-open it with the “R” appended and with the “R” reason uploaded. The main integration methods for this project were .NET applications and plug-ins.