Communication through electronic mediums can be treacherous. Current estimates say that we get as much as 80 percent of our information through non-verbal cues. That means that when our communication is limited to written word only, both the communicator and the receiver are at a disadvantage.

This disadvantage can be especially pronounced when you’re communicating with your customer through email. Typically, the customer wants something from you or you want something from the customer. It goes without saying that the stakes are higher for the business. Unhappy customers can leave a trail of negativity that stretches from Facebook to Tumblr.

If only there were some way you could avoid email blunders. Some place you could go, for a quick summary of email best practices. Perhaps a blog written by the support specialist at a company that’s been in the tech business for close to 20 years…

Never fear! Mercury’s got you covered! Here are our top four tips for effective customer service emails.

Shore up the basics

Of all the email faux pas you can make, many customers find spelling and grammar errors to be the most offensive. How can they trust you with their money and business when you insist on butchering the English language in front of them? Luckily for you, it’s easy to make sure your emails are up to snuff. Here are a few things that you can do to make sure your emails sound professional.

Proofread

  1. Paste the body of the email into Microsoft Word. Not only will it show you spelling and grammar errors, but it will tell you what those errors are. If you pay attention to the kinds of errors you make the most often, you can learn from your mistakes and avoid making those same errors in the future.
  2. Read the email aloud verbatim. That’s right! We’re going all the way back to English Composition 101. Your brain is very good at filling in gaps and identifying patterns, especially when you’re reading silently to yourself. Reading an email out loud can sometimes help you catch things your trying-to-be-helpful brain would otherwise overlook.
  3. Run it past a co-worker. Despite our best efforts, everyone occasionally needs a little help. As in most things, the eyes have it!

Use clear, precise language

Now is not the time to break out your Shakespearean prose. Complicated sentence structures and verbose phrasing are tried and true ways of confusing your customers. Here are some handy ways to make sure your emails are clear and polite.

  1. Make a conscious effort to use active voice, rather than passive voice. An easy way to tell which voice you’re using is by placing the phrase “with zombies” after the verb. If the sentence no longer makes sense, then you, my friend, are an active agent.
    • This is active (because the sentence makes no sense): I ate (with zombies) an apple.
    • This is passive: The apple was eaten (with zombies).
  2. Mirror your customer’s language. Who cares if your customer calls them TP-thingies rather than TPS Reports. A customer’s phrasing and overall composition tells you how they’re most comfortable communicating. Pay attention to what they’re saying and how they’re saying it, then try to communicate on their level.

Let’s get visual, visual!

Email is a visual medium after all. You can use a lot of the same principles that are used in other web communication platforms to clarify your meaning.

  1. Use whitespace to highlight what’s important. In a nutshell, whitespace involves arranging your document so that it’s easy to see what’s important. Pay attention to your fonts, your line spacing, and how easy it is to find the main points of the email.
  2. Use pictures, graphs, or videos when appropriate. You’d be surprised what a screenshot, Microsoft Paint and a few helpful arrows can accomplish. Even if a picture isn’t actually worth a thousand words, it’s certainly worth a thousand positive customer experiences.

Know when to fold ‘em.

There’s a fine line between an engaging back-and-forth and a communication conundrum. Even if an idea is very simple, if your customer doesn’t understand you, it may be time to pick up the phone. Here are a few signs you can use to determine when a phone call might be in order.

Hand picking up telephone

  1. You’re having a hard time summarizing the information in 2 – 3 small paragraphs. No one wants to open their email and see a book. Even if your email is crystal clear, your customer may not have the patience or the time to read it all. If you can’t concisely convey your message, your message may be too complicated for an email.
  2. Your customer has asked you the same thing multiple times. This is a clear sign of a communication disconnect. You could continue to find new ways of saying the same thing, or ask clarifying questions find out exactly what the customer is confused about. There’s nothing inherently wrong with beating a dead horse. (A jk from legal, there are several moral, if not legal, issues raised by the propensity to beat dead horses. Mercury in no way condones the abuse of animals, regardless of their life status). You could also avoid the likely mounting frustration that both you and your customer feel, and give them a call.
  3. Your customer has asked you to do two things are inherently opposite in the scope of your business. This usually means the customer is not sure what they want, or they’re not sure what the scope of your business is. This is an opportunity for you to have a genuine, sales-leaning discussion about your client’s goals and expectations. If you can help them reach their goals, great! It’s the start of a beautiful relationship. If not, perhaps you can steer them towards someone who can. Either way, you’ve left the customer with a positive impression of your business.

All good things…

In conclusion, not everyone is going to be a communications savant. That doesn’t mean you can’t provide positive experiences that endear you to your customers. Just follow these tips and keep your customer’s needs in mind, and you’re sure to have happy, well-cared for customers.

This is the third post in a series about SQL Server Reporting Services (SSRS). I will be picking up where we left off in the project that was created in Part 2.

One of the other important topics of SSRS is adding parameters to a report which lets you filter the data down to a smaller group. As with many things, parameters can be simple selections or can be more complicated with cascading selections that depend on other parameters. We’ll keep things relatively simple here.

Reviewing what the report looks like now, we have the Sales YTD and Last year by rep grouped by their country.
SalesYTD

What we want to do now is to add the ability to filter the report. We want the ability to see all countries or just a single country’s data. The place we need to start is the query in our Shared Dataset (SalesPersonData.rsd).

Query Updates

Right now the only filter is to now pull any of the sales reps that are not part of a territory. We need to add a couple more expressions in the where clause to allow us to filter the data more.

SELECT BusinessEntityID, Title, FirstName, MiddleName, LastName, Suffix, JobTitle, PhoneNumber, PhoneNumberType, EmailAddress, EmailPromotion, AddressLine1, AddressLine2, City, StateProvinceName,PostalCode, CountryRegionName, TerritoryName, TerritoryGroup, SalesQuota, SalesYTD, SalesLastYear FROM Sales.vSalesPerson WHERE TerritoryName IS NOT NULL

The CountryRegionName will be what is filtered on and it will be set to the name of the country we want to view. In the actual query we won’t know what that name will be so we need to set a placeholder. The format for placeholders is the @ symbol and a meaningful name. I’ll go ahead and use @CountryRegionName

CountryRegionName = @CountryRegionName

The other check we will need to make is, if the value that gets passed to the query is empty then it means we should display all countries. The TerritoryName check should be applied regardless of the country selected so the full WHERE clause will end up like this:

WHERE TerritoryName IS NOT NULL AND (@CountryRegionName = 'All' OR CountryRegionName = @CountryRegionName)

When you update the Dataset query select the Refresh Fields button and then in the side navigation for the Dataset select Parameters.
Shared_dataset

SSRS recognized that we have a placeholder in the query and want a parameter option for the report. Here we can set various options including the data type and if it can include multiple values. Using multiple values, our query would have to use IN instead of the equality sign.

Set the data type for the parameter as Text.

Now we need to update our report in a similar manner. In the Report Data window open the SalesPersonData properties. On the main window select Refresh Fields and select OK.

In the Report Data window you should now see a CountryRegionName parameter under the Parameters folder. Opening the properties for it you can see that it kept the data type of Text that we set in the Dataset.
report_data

Closing this window, opening back up the Dataset properties and going to the Properties tab in the navigation you will see that the parameter that was written in the query is now set to match up with the new Parameter Value. In more advanced scenarios you can set this to a specific value or, by using the function (fx) button, an expression.
data_properties

If you preview the report now, you will notice a new area at the top with the label Country Region Name and a textbox. This is where we can enter in the information we want to filter on. Enter in the text United States and select the View Report button on the top right (my screenshot has some bad text coloring) to see the report filtered to only this region.
view_report

While it is great that we have the filtering working, it would be very cumbersome to have to remember each region in order to filter the report. Which is why there is the ability to set selectable options for the parameter and a default option.

Available and Default Parameters

Back in Design view, in the Report Data window, open the properties for the CountryRegionName parameter. A couple of the navigation options on the side are Available Values and Default Values. Selecting Available Values you can see the options for having no values, which is the default; you can specify your own values, including the Label and Values for the options; and you have the option to get the values from an existing dataset query.

choose_parameter choose_parameter_2

While we know now what the available options for the Country Region will be, it is unknown whether these will change in the future so the query option will be a better choice for the report.

The first step is to create a new Dataset that just pulls back the country regions. (This would be a good candidate for a Shared Dataset because it would have a high probability of being used for a parameter in multiple reports)

Checking the Person.CountryRegion table, there are many more options there than what is actually in the report so we will build our list off of the same View as the main Dataset. The first select statement also UNIONS a row with the value of ‘All’ that will be used to display all of the regions.

Select 'All' AS CountryRegionName UNION Select DISTINCT CountryRegionName FROM Sales.vSalesPerson

After adding the new Shared Dataset (I named mine SalesPersonCountryRegionList) to the report we can go back and update the parameter’s available values.
report_parameter

We can also set the default to ‘All’.
report_properties

Now the report will default to all regions displayed…
regions_display

and when selecting a specific region and clicking the View Report button it will filter the data shown.
report_filter

Conditional Visibility

One last touch up to the report is the Grand Total data on the filtered views has become redundant so we just want to hide it if the report is filtered.

In Design View, right-click on the thick border next to the Grand Total row; one of the menu items is Row Visibility. Select that item and we will want to Show or hide based on an expression. Select the fx button to open the Expression window.

We need to write an expression that when true will hide the row. The parameter will be our point of reference for the expression and we can add it to the expression by using the GUI at the bottom of the screen or by writing the appropriate syntax. (If you type it out, do not delete the equal sign ‘=’ that has been set).
query

Parameters!CountryRegionName.Value

We want the row to be hidden when the report is filtered and we know that all the countries will be displayed when the ‘All’ option is selected so we can use:

Parameters!CountryRegionName.Value <> "All"

Now the Grand Total does not show when filtered by a specific region.

Wrap up

Over these past few posts we have gone through some of the basic, but important, concepts for building SSRS reports. There are of course many more topics that could be covered so let me know if there is anything else you would like covered in the comments.

A development trend over the last few years has been utilizing JavaScript task runners to automate front-end development. Some of the big names that have gained widespread use are Gulp, Grunt, Cake, and Broccoli. Task runners can do magical things like compile SASS/LESS into CSS, lint your JS and CSS files for validation and proper formatting, optimize images and SVG files, minify your code, and much more. This blog article will cover Gulp, which is a fast and plugin-rich task runner that is quick to get up and running.

Another benefit of using a task runner such as Gulp removing dependencies on Visual Studio plugins to handle your automation. Not every designer or developer may have access to paid plugins or familiarity using or configuring certain plugins.

Once you have Gulp set up, any designer or developer can gain the benefit of the automation Gulp provides, since it lives with the project and is always watching for file changes and/or file additions. You can also integrate Gulp into your build pipeline to via build definitions.

In this article, we’re going to cover adding SASS compilation via Gulp. Let’s get started!

Step One: Add a package.json file

In the root of your project, create a file named “package.json”. This file is used by NPM (a package manager for JavaScript) to add and track any dependencies you Gulp plugins may have. This file is a basic JSON file with minimal configuration.

gulp-package-json

Add the code above and save, and in your Output window, you’ll see NPM reaching out across the inter-tubes to add the dependencies required for Gulp.

Gulp Output Window

Let’s add our first plugin – we’ll add gulp-sass (check the link for documentation and more information beyond this article). Adding a plugin is as simple as adding another line in the package.json file, like so:

Gulp SASS

You’ll notice above that VS 2015 is nice enough to give us a hint as to the latest version of this plugin that’s out there. Add the latest stable version and save the package.json file.

In your Solution Explorer, you’ll see NPM adding these plugins and dependencies in a node_modules folder. Make sure to include these files in the project, and include them when committing and syncing to your repository for source control.

Gulp node_modules

Step Two: Add a gulpfile.js file

In the root of your project, create a file named “gulpfile.js”. This file will contain the task runner pipeline and any commands and configurations for your automated tasks. Add the code below to get Gulp set up to compile any .scss files found in the /Content/SASS folder, which it will output into the folder /Content/CSS.

Gulp SASS gulpfile

Step Three: Add A .SCSS File

Next, let’s add some folders and a basic Gulp.scss file, like so:

Gulp SASS Folders

Inside of Gulp.scss, we’ll add some basic SASS to set our body background to white via a variable. Add the code below, but don’t save quite yet:

Gulp SCSS 1

Step Four: Run Your Tasks

Here’s where the magic comes together. Open up the Task Runner Explorer window, and you’ll now see two tasks for “sass” and “sass:watch”. These are the names of the tasks we added in gulpfile.js.

Gulp Task Runner Explorer

The task “sass” task does the compiling and writes out the CSS file. “sass:watch” is set up to look for any changes or additions, and if it detects a change, it calls “sass” and recompiles and re-outputs the CSS file.

Let’s right click on “sass:watch” and run it, like below (you can also double click to run)

Gulp sass watch

You’ll notice a tab was added to the bindings pane for “sass:watch”, which is now running and waiting for us. Go ahead and save your Gulp.scss file.

If everything went according to plan, you’ll now have a CSS file in your project that was compiled and created by Gulp. Awesome!

Gulp CSS

Conclusion and Continued Reading

You’ve now passed Gulp 101! We’ve only scratched the surface of what Gulp can do, but you now know the basics and have the knowledge to start using other Gulp plugins for even more automation. Adding new plugins and running new tasks works in the same manner described here for SASS. Try out some more useful plugins below!