Mike Smick UX Sketch Sub Page Image

Graybar Outlook Sidebar App

Project NameGraybar Outlook Sidebar Product Order App
TaglineQuick supply order plugin
Project SummaryDesign an outlook plugin that allows Graybar electrical customers to quickly send supply re-orders to their local reps.
ClientTDK / Graybar
Date or TimeframeOctober 2019
Tasks & ResponsibilitiesResearch electrical supply customer, work on user persona, develop concept that could integrate with TDK / Graybar API, design UX screens, simulate workflow.
PlatformsOutlook
Design Tools / UX MethodsFigma, Outlook 365, UX Component libraries
KPIs / AnalyticsCompleted orders, re-orders, plugin downloads
Team / CollaboratorsMike Smick, Tim Saunders, Adam P.

Graybar came to the team at TDK to work on a concept that could improve the customer / sales rep relationship by streamlining transactions but utilizing existing paperwork process. After the initial meeting, we got together to discuss the potential for the system. Realizing some of what could be done, could be simplified in an Outlook plugin, I sought to reach out to the customer base and utilizing the current Microsoft UX component library, created the screens towards a workflow. Once completed I presented the work to Graybar for continued evaluation.

For the presentation to Graybar, I highlighted two methods or workflows.

Fortunately I have a few colleagues and relatives that work in the electrical business I could reach out to for some research. The service model Graybar had was utilizing reps assigned to customers for order fulfillment. Because of the volatility of supply quantity and all things financial around the client relationship, it was critical to maintain that service model using the plugin.

These screens represent the customer view, but I explained the administrative requirements that the sales rep or customer service rep would be required for the product order to work. In order to bypass a search with degraded response time, model # confusion and convenience, the products would be assigned to the client so they could quickly be re-ordered.

A note about Outlook plugins. There would be a constraint on versioning both client and server. In my research and discussions with the team, we evaluated the SalesForce plugins for outlook to see what functionality and design references were available.

Method #1 Generate Order PDF – Auto-Compose Email to designated recipient

I rendered the complete outlook screen in Figma in order to present in context how things would work. A customer with the plugin installed could enable its view, then it would be persistent. From there they would be given a predetermined list of products they could generate an order. This would replace many phone calls but would not require the customer to utilize a website. The sales rep could assist in plugin installation and config.
In this first method, the order is generated by automatically composing an email, taking the generated order PDF and dropping it into the message as an attachment. The advantage here, as I indicated to the client, the customer could request additional ‘off-book’ items in the body of the email that might not be available in their order form. A manual request yes but it allows for the sales rep to look at inventory, quantity and price considerations and follow up the same as they have been, as well as add that product to the customer’s order sheet. Because this generates an email, a dialog in the form reminds the user they must send that email. They are also able to reset the form here if they wish.

Method #2 Prepare an order and automatically submit in background as webform

The next two screens are the second method of ordering which generates and sends the order as a webform post. In discussions with the team, this would require more infrastructure on the back end to form process and and integration with inventory API. This would allow the customer to potentially pull up their records of orders as well as order modification and more direct customer service.

Similar to method #1, the customer can choose quantity of product and prepare their order. In order to reduce the opportunity for mistakes, accidental sends, I’ve added a second step in the screenshot below.
Here the application is showing the confirmation of the products and quantity so the customer can submit. This confirmation is helpful the more products that might be available on the customer’s list. It reduces accidental sending of an incomplete order and gives the customer a chance to cancel and rework the quantity. The app remains fairly simple nonetheless.

Next are a couple of configuration and help screens that are helpful for the sales rep. The initial setup of the plugin after installation requires the customer to identify their sales rep so they will be designated recipient. This could include an automatic assignment of their account manager / CSR at Graybar as well.

The Settings link is accessible at the bottom footer of the plugin sidebar. These setup configurations can be done once and mostly ignored afterwards. If the rep is on the phone or in-person with the customer they can put in the information for the customer. The toggle switches I added were a reminder to Graybar that if there are additional configurations, plugin options, they could be included

The final screen is the Help screen. In my work I like to include that in most of my design proposals if they don’t exist already. Sometimes help can be integrated with instant messaging, support contact and more. In this case, I wanted to provide a couple potential FAQ items and provide a way to submit a support email to the sales rep / CSR.

If the help screen needed to grow it could be made scrollable, but the important thing is trying to alleviate calls to the sales rep when documentation could be explained / written one time and responded to when the rep is free from other calls.

Administrative Screens

This last slide was part of our discussion regarding potential additional screen views and requirements from the admin side of things. Also other functionality that would grow the complexity of the application. Because these were unknowable at the time, they were instead just explained as project considerations to be discussed. They also helped open up for questions and comments from the client, and our developer and architect and sales manager.