News

It happens. You planned and perfected an amazing Service Portal in ServiceNow. You followed every best practice and met every requirement that was asked of you, and then some. It’s beautiful. It’s modern. It’s intuitive.

And no one is using it.

The benefits of a well-made Service Portal are HUGE! Enabling your users through self-service saves tons of money. But if adoption is low, that return will never be realized. So, let’s talk about some things you can do to increase your Service Portal adoption and make that investment worth it.


#1 – Articulate the Benefits

Let’s start with the most important step. Users will not adopt a new tool unless you can answer one question for them; “What’s in it for me?”

Portal users will inevitably question whether this is just a tool you want them to use, or this is something that will truly add value to their lives. Can you effectively articulate what that value is? Here are some sample questions you can ask yourself to start visualizing the value your portal can provide:

  1. Why would a user prefer to submit an issue or question through the portal, when they can just call or email us?

  2. How much time do my users spend on the phone requesting more information and providing status updates?

  3. Are users happy to perform basic troubleshooting to resolve their own issues? (Hint: Yes, they are. Fact.)

  4. Do managers and team leads sit in meetings all day without the ability to communicate with the help desk?

  5. How many people still use ineffective equipment or applications just because they don’t know they can request it?

When you know your portal’s value and you’re ready to get the word out, don’t be cheap. You invested in something great, but that investment isn’t over. You still need to maintain it and of course, market it. Check out suggestion #3 for tips on getting the word out. But what is that word?

Try to avoid using clichés like “HR at your fingertips” or “Service at the click of a mouse”. Ugh. Gag me with a portal widget. Instead, give realistic examples of the practical, tangible benefits. If you need some one-liner examples, try:

  1. Get help, answers, and updates wherever you are

  2. Request upgrades and replacements from the road

  3. Live chat support – 24/7 – Anything you need

  4. Looking for some wordier verbiage you can slap on a sign?

Looking for some wordier verbiage you can slap on a sign?

  1. Tired of calling the Help Desk? Order new stuff and get your old stuff fixed any time of day. Visit Cerna Self Service from any company device to get started.

  2. Wouldn’t you rather fix it yourself than wait on the help desk? Find quick solutions to your most common problems by visiting Cerna Self Service.

  3. Get answers faster and track live ticket progress from your desk or your phone using the new Cerna Self Service portal.

If you’re still having trouble determining this yourself, use these next six suggestions for finding value to add.

BOTTOM LINE: If you can’t tell a user what’s in it for them, then you can’t tell them to use your portal.

#2 – Talk to Your Users

We can’t even begin to strategize portal adoption until we talk to stakeholder numero uno; the end-user, your customer. We must have a relationship with them if we expect to provide them value. Relationship means talking – or so my girlfriend wants to believe…

This may sound like a time-consuming activity, but a small sampling is all you need. In fact, you can learn over 60% of what you need to know from just talking to two users.

Getting your sampling is easy. They’re calling the help desk, sending emails, and stopping by all the time. Follow up with these users and find out why they didn’t. Maybe there’s a technical problem, or a usability flaw. But most likely, there is a shared uncertainty among your users of what the portal is capable of.

Be brave. Seek disapproval. Find out what stinks. But learn what they like too. Then you can better articulate an acceptable answer to this elusive WIIFM question.

BOTTOM LINE: You can never know why users don’t adopt your portal if you don’t take the time to chat with them.

#3 – Make it Easier to Get There

You’d think this would be an easy step, but you may be surprised at how many employees are expected to go remember https://www.companyname.service-now.com/sp/terrible_portalsuffix. You can create a custom URL in ServiceNow that is easy enough to remember, such as support.companyname.com, or you can buy a unique domain that redirects to the service portal. This gives you a chance to brand your service and remove all remnants of the name ServiceNow (no offense, Fred).

Even if you don’t use the custom URL feature, you can still name your portal something friendly. Some rules of thumb:

  1. No underscores

  2. All lowercase

  3. Less than 8 characters

  4. Nothing that could be spelled a variety of ways

So, we’ve articulated our message in suggestion #1, and now we’ve got a sharable URL. Where can we post this puppy?

  1. Other intranet sites

  2. Posters

  3. Email campaigns

  4. Email signatures

  5. Bathrooms

  6. Helpdesk

  7. Cafeteria

  8. All hands meeting

  9. You get the idea…

BOTTOM LINE: Don’t underestimate your user’s ability to quickly forget that your awesome portal ever existed.

#4 – Fresh Content

I heard a joke the other day.

“What do you call a service portal with old content? A CMS portal.”

Now I’m pretty sure I’m the only nerd laughing at that (and I admit I made it up), but the truth is real. Old content equals extinction. You’re lucky you get people using it at all.

One of the primary purposes of Service Portal (if you built it correctly) is to provide a simple way to publish current content. Therefore, difficulty of content maintenance and publishing is not an excuse I’ll accept here. It’s got to be fresh, and here are some pointers.

Adding New Content

  1. Make your portal the go-to location for all the latest information relevant to your users. Company announcements, potlucks, holidays, everything.

  2. Add new catalog items constantly. Don’t make stuff up just to add it, because there’s always something that could be more efficient if it had a proper catalog item. Go ahead, get crazy, add a new category to your catalog.

  3. Don’t have a knowledge base? Stop what you’re doing right now and write a list of 5 frequently asked questions and their answers. Now make it a KB article. Do this once a week for eternity. Now you have a knowledge base.

  4. Allow users to suggest new content.

Add Self-Publishing Content

  1. Include some feed in your portal, like your company’s twitter feed, something humorous, or inspirational. Use your imagination.

  2. Consider using the Social Q&A features of the portal to let users chat it up.

Keeping Old Stuff Fresh

  1. Feature new and useful content regularly

  2. Ask users for feedback on existing articles and item forms. Yes, ask for feedback on forms, unless you know they stink and want to ignore it.

  3. Remove old stuff. Purge!

  4. Watch trending incidents and proactively feature a KB article that mitigates the issue. Also consider giving your content personality. Even if it’s just featuring a hello message from members of your help desk, personalized content goes a long way in improving user experience.

BOTTOM LINE: Fresh content is living content, and users will want to eat it. If it’s not fresh, well, you know.

#5 – Put a Tablet at the Desk

Other than nerf ammo whizzing around, the first thing your help desk visitors should see is the service portal on a big tablet. This accomplishes several things:

  1. Gives your visitor another service option while waiting in line.

  2. Can potentially free up your help desk to help people with more serious problems.

  3. Reminds people that you have a portal after all.

  4. Shows people that your portal looks great on mobile devices.

I’m not suggesting you shirk your customers to a faceless portal when there’s a warm body behind the desk. Nothing beats personal service. I am advocating that you encourage self-resolution, streamlined communication, and all-around time saving features through your service portal at every opportunity.

Keep in mind that you’ll either have to provide a guest experience or give visitors an easy way to login, such as via badge. And of course, the walk-up experience in London does a pretty good job at managing a help desk experience. Still, your portal will be a great supplement to it, because walk-up doesn’t do everything your portal does. Walk-up experience or not, it doesn’t hurt to show off your portal around the office with some well-placed (and securely fastened) tablets.

BOTTOM LINE: Never leave your customers without a fallback, and a simple fallback is your portal on a tablet in an easily accessible place.

#6 – Make it an Onboarding Activity

A great way to instill good habits in your team is to get them started early. It’s likely that you already have a short introduction to your service portal as part of onboarding activities. Is that enough to make a lasting impression or demonstrate real value?

Rather than a short demo or explanation, during orientation give your new team members something real to do in the portal. Consider these ideas:

  1. Order first-day services and items themselves.

  2. Instead of printing out new hire packets/books, use the knowledge base to publish instructional documents, policies, FAQs, etc. that will be used.

  3. Submit a “Hello” incident to the help desk. Your help desk responds by welcoming the new hire and introducing themselves personally. P.S. I know you’re worried about creating fake incidents, but there are simple ways to keep these out of your reports.

This is guaranteed to increase adoption among your new hires. You can probably simplify and streamline many of your first-day activities this way too. You have a portal don’t be afraid to use it!

BOTTOM LINE: New-hire orientation is your only chance at first impressions. Make it interactive and valuable, or else it’ll be forgotten.

#7 – Incentivize Them

If you’re struggling to get the attention of your audience, be prepared to offer them something of real value in exchange for their attention. In this case, I’m not talking about the value of the portal itself, like I talked about in our first example. My focus here is on increasing portal visibility through temporary and indefinite perks and rewards.

These ideas are great for initial portal launches, but don’t hesitate to run short campaigns on a regular basis. However, please note my number one caveat: Don’t be cheesy, and don’t give away things nobody wants (and we all know what that stuff is).

Try some of these short-term ideas:

  1. For 20 days, give a $5 gift card to everyone who submits their incident through the portal.

  2. Hide Easter Eggs in knowledge articles that you want people to read, and give prizes to those who find them. Just be sure to switch them up frequently

  3. Give away t-shirts, but the only way to get one is to order it through the portal.

  4. Have a secret help desk pizza party. Put an invitation request in your service catalog but don’t tell anybody about it, just hint about it.

Or consider some more long-term ideas:

  1. Offer priority response time to tickets submitted through the portal.

  2. Offer live chat with no wait.

  3. Allow knowledge base suggestions and reward them for submissions and accepted ideas.

We obviously don’t want to incentivize people to make submissions and requests for things they don’t need. So be careful with submission related incentives. Use forethought with any of these and be prepared to mitigate abuse.

BOTTOM LINE: Don’t underestimate your target’s susceptibility to immediate gratification.

I’ve provided here just a short list of ways you can increase adoption. You know your organization, so you’ll know what will be most effective. Use my ideas as a starting point, then be creative and think of what would really excite, engage, and entrust your customers.

Here are some honorable mentions:

  1. Put your company swag store in your service catalog.

  2. Publish fun stuff in your KB, like a help desk blog written by your team.

  3. Push icon links to your user’s mobile devices.

  4. Get thousands of chocolates or mints with custom wrappers that promote your portal. Put them in bowls everywhere all year long.

You don’t need to employ every trick in the book to increase portal adoption, but you do need to consider a multi-faceted strategy if you want to make a dent. If anything, you’ve got to start with these two:

  1. Know your users.

  2. Know what value your portal can give them.

After that, it’s up to you to get creative, have fun, and watch your portal traffic stats grow.

If you’d like to start a conversation about Service Portal consulting, or other ServiceNow needs, send us a message, and we’ll be happy to connect with you as soon as possible.



It’s a developer’s worst nightmare.  You’ve spent weeks, maybe months perfecting your latest roll-out.  You’ve got your workflows, forms, and fields all in order and everything works perfectly in dev.  You push your sets and do a couple of tests and…wait a minute.  Why isn’t anything assigning to the right groups or people?  All of that work down the drain!  How could this have gone so wrong?

It’s a scary-looking problem with a simple solution.  Your core data is not in sync!

So… What is Core Data?

Core data is a set of tables with user, group and organization data that ServiceNow uses to assign and route tasks and other records.  What is considered core data will be slightly different in different implementations depending on which tables are being used, but it will generally include the following tables:

  1. Users [sys_user]

  2. Groups [sys_user_group]

  3. Group Members [sys_user_grmember]

  4. Locations [cmn_location]

  5. Companies [core_company]

  6. Departments [cmn_department]

  7. Roles [sys_user_role]

  8. User has Role [sys_user_has_role]

  9. Access Control (ACL) [sys_security_acl]

These are the ones that hold the data on your employees and locations, their roles, what groups they belong to, and what information those groups get to access in ServiceNow.  This is the glue that holds all of your processes together, and keeping this data in sync between instances will allow your developers to build and test with the confidence that the thing that works in Dev will work just the same in Prod.


Going with the (Data) Flow

So how do you begin?  Start by determining the way you want the information to flow.  There are multiple ways to go about it, each with their own pros and cons:


OPTION 1: From Dev to Prod

Say we consider Dev to be the source of truth.  That means that all of the core data gets entered and manipulated in Dev and then those changes get pushed to the other instances.  It seems legit, right?  Your developers are used to making changes in Dev and pushing them up to Prod, it’s a familiar way to work.  You don’t want them messing with live data in PROD, do you?

Well, maybe.  One of the problems with flowing information from Dev to Prod is that so many people have access to that data in Dev.  It’s hard to trust data that everyone has had their hands and their test uploads and their data dumps on.  Can we really be 100% sure that the spreadsheet of new asset tags that were uploaded last week didn’t make any changes to our core data?  Do we want to have to do all that double-checking all the time?  Maybe.  Maybe not.


OPTION 2: From Prod to Dev

Ah Prod.  The clean instance…the one that contains only the stuff we really want to put in it.  Surely that’s the best place for your source of truth when it comes to core data.  After all, only a handful of people have access to make changes in Prod, and less access means less chance of questionable data.  The thing is, Prod is LIVE, meaning people are actively using the system and will absolutely notice right away if something goes sideways due to a change in core data.  Making changes directly in Prod is like working fifty feet in the air without a net and for that reason, it makes many developers very, very uncomfortable.  Are you feeling lucky?  Maybe.  Maybe not.


OPTION 3: Both/Neither/Hybrid Option

Because Prod is the cleanest, happiest, and BEST place to use as a source of truth, and Dev is the friendliest, safest, and BEST place to make changes, it’s possible that a hybrid option is the way to go.  It’s like this:  Prod is your source of truth.  It holds all of your beautiful, precise, correct core data.  Which is why when you want to make a change to it, you could pull that information down to Dev, overwrite the messy, picked over swampland that is your Dev core data, and have a fresh, clean, set of data that matches Prod that you can now make changes to.  Make your changes quickly, verify them, then push that data back up to Prod and… voila!  Could it work?  Absolutely!  Will your developers remember to consistently pull down fresh data and push it right back up after making their changes?  Every time?  Maybe.  Maybe not.

The truth is, there is no one best way!  It’s up to you to weigh your organization’s needs, consider the precision of your development team, and come up with a data flow that works for all of you.  Then all that is left is to decide how often you need to refresh that data from your source of truth, and that will tell you whether you can do it manually, bundle it into a clone or set up a scheduled job to run in the background and do it for you.

So, my friend, you’ve got a few decisions to make.  Setting up a process to keep your core data in sync now can save you months of reworking and extra development time.  It can even spare you that little jolt of panic you get when the thing you built-in Dev doesn’t work in Prod.  We’ve all been there.  So do yourself a favor and get that core data in sync!

Author: Carrie PadianSr. Technical Consultant

Carrie is a self-described process nerd with almost 20 years of experience in the Information Technology space. She is a frequent blogger, presenter, and podcast panelist for Cerna Solutions, with a unique gift for creative problem-solving. You can also find her on Twitter at @ITSMcarriep.

Have questions?  Feel free to contact us to talk about how you can get the most from your ServiceNow practice.



We’ve all been there. You’ve done all the work, you’ve debugged and perfected your code, you’ve collected your precious updates into an update set and moved it to the next instance up and then… BOOM! Your ServiceNow update has problems. Fear not! The truth is, most update set problems look scarier than they are. In this blog, we’ll examine a few of the most common problems that occur, and show you how to fix them.

⚠️ Error type: Missing object

Example: “Could not find a record in sys_ui_policy referenced in this update”

What’s going on:

Have you ever created a bunch of records for a build, made some changes, and then deleted one that you didn’t need? Unfortunately, that seemingly harmless change is what’s causing your error. ServiceNow is expecting a record in this instance that didn’t make it into the update set, usually because it was deleted in Dev. This also might happen if the table the record is in isn’t captured in the update set.

How to fix it:

Click “Find missing record” and see what happens. If it’s a record you deleted, you’ll get a message that says, “Record not found”. At this point, your best bet is to just skip that update. You don’t need it.

If it’s a record that just didn’t make it into the update set, “Find missing record” will pull it up. At this point you have choices. You could export the record from Dev and import it into your current instance, or you could go back and set the record’s table to be captured in an update set before creating a new update set to capture it in. Both options require you to remember which action you’ve taken so that you can upload the record or apply the new set when you get to the production instance.

⚠️ Error type: Collision

Example: ”Found a local update that is newer than this one”

What’s going on:

This can happen when there are multiple people working in an instance and using their own update sets. One makes a change to a record or workflow that the other has modified and then pushes their update set first. The other is left wondering why anyone is making changes to the thing they are working on.

How to fix it:

Click “Compare with Local” and you’ll get a list comparing the two versions of the item. If you see something in the list that is in your older version but not the new one, you may want to select “Accept Remote Update” to go with your version. If there are things in the new version that are not yours, choose the new version by selecting “Skip Remote Update”

⚠️ Error type: Uncommitted update

Example: “Could not find a table field (u_case.u_reference) referenced in this update, but did find it in another uncommitted update set”

What’s going on:

This one happens most often when you have several uncommitted update sets for the same component or multiple copies of the same uncommitted update set on an instance, perhaps after a clone down.

How to fix it:

If you’ve got multiple sets for the same component, the best way might be to go back to your development instance and merge those sets before pushing to your next instance. If the problem is a duplicate set after a clone, you can either remove the duplicates and run the preview again or accept all the changes and then verify with thorough testing that everything committed correctly.

⚠️ Error type: Table to be deleted has data

Example: “Found a row in the table that is going to be deleted”

What’s going on:

If your build included deleting a table, ServiceNow will check before deleting to make sure there isn’t data on that table that will be lost. If there is data, you’ll get this error.

How to fix it:

Verify that you don’t need the data in the table. If you do, skip this update and leave the table as is. If you don’t need that data, accept the update and ServiceNow will delete that data as well as the table that it’s in.

⚠️ Error type: Application scope validation issue

Example: “Could not find a record in sys_scope for column sys_scope referenced in this update”

What’s going on:

If you’re working in a scoped app and that scope doesn’t exist on the instance you’re pushing to, you’ll get this error.

How to fix it:

Only apply sets on instances that contain the scope you’re working in.

So that’s it! Not so scary after all. But what common errors did we miss? Feel free to contact us to let us know what ServiceNow error messages keep you up at night, and we may address that in a future post.

If you have other questions about Cerna Solutions and what services we offer for ServiceNow, enter your information below, and we’ll be happy to speak with you about how your team can take ServiceNow to the next level.


Have questions?  Feel free to contact us to talk about how you can get the most from your ServiceNow practice.



Start Now

Security & Risk Solutions
IT Solutions
Business Solutions
HR Solutions
Customer Solutions
CS 2020 LOGO - solutions tagline (white)

Email:    info@cernasolutions.com

Phone:  +1 844 804 6111 (US)

               +44 (20) 33254077 (UK)

  • White LinkedIn Icon
  • White YouTube Icon
  • White Twitter Icon
Company
Insight
Products
ServiceNow Services

© 2020 Cerna Solutions, Inc. All Rights Reserved. 2056 Palomar Airport Road Carlsbad, CA, 92011.