Onboarding – Manager of First Impressions

This is the first in a blog series about onboarding; to read along and get updates, follow us on twitter, LinkedIn or Facebook. To join our quarterly newsletter fill out the form in the right margin of this page ->

In this blog series we are going to focus on practical advice for one of the most complex, yet most common business processes.

Onboarding starts a new relationship. This is usually done in reference to a person or a business. And just like any relationship, this first experience accomplishes a lot. It sets expectations, communicates value and helps move the relationship along during the first critical moments.

The same can be said for business-to-business (B2B) companies. You will need to onboard new clients, customers and partners regularly. The trust and collaboration will be based on these preliminary transactions.

Being able to onboard well is a symptom of high performing organizations.

First impressions last forever! The onboarding process sets the expectations of the new employee, client or company. If it goes smoothly, they think things will go smoothly in the future.

Having the discipline, resources, foresight and leadership to make onboarding go smoothly is no simple feat. Oftentimes the complexity of a person or company destroys our ability to build something that works for every situation.

Nonetheless, through trial, error and sheer perseverance your teams can achieve an acceptable and delightful experience.

So how do we start?

Most designers agree that a map is a decent place to start talking about processes. Mapping out the workflow will help people understand what is being discussed along with the upstream and downstream impact. For example, if an HR role enters in a new hire name into a form; don’t make anyone type it again.

This might seem obvious, but if you’re drowning in paper forms you might not be able to see the forest through the trees.

Onboarding is a living and breathing process. It is always changing.

What happens prior to the on boarding process starting? Literally. What is the trigger to start onboarding? Did they accept an offer? Did they sign a contract? That’s a great place to start!

When they signed the contract, is that the last thing you need to get started? If not – work upstream to that contract or agreement so that you can gather the necessary information required to take on a new client/customer or teammate.

Next, how much lead time do you need?

If someone just signed a contract, how long until they have products in their hands? How long do you have to set up a new employee and prepare for their arrival? How long until they are trained?

When the first order of business is to do “all those things we didn’t do last time”, it looks like you are disorganized, your teams are disorganized and you can’t be bothered to make things better.

The stream of tasks and workflow to onboard a new employee should go as fast (or faster) than you expect the employee to also produce and contribute to the teams’ success.

And this is the most basic of all requirements for an onboarding process. You see the process should right-fit your culture and organization. Go as fast as needed for success. Not faster, nor slower. Both will cost you more than is necessary.

So hopefully mapping out the processes and seeing what needs to happen and when will start to make you look more organized. Like you care about this new relationship!

So how much of the experience of a new employee should we consider “onboarding”?

This is one of my favorite questions and it’s one of only two places left to innovate most onboarding programs. Many organizations already get the process of intake of personnel along with assignment of security and tools. Companies and teams looking to take onboarding to the next level, add security training to match their access and tool training as well. Then start career path activities and mentorship programs.

Putting these talent management basics in place at the onset of a relationship will help in very valuable ways. Things like attrition avoidance and risk mitigation. This isn’t just an investment in security, efficiency and recruiting; it’s also an investment in protecting intellectual property and talent retention.

The management of any relationship is, in entirety, onboarding.

From the moment a new relationship is formed, to the time professional ties change or sever, onboarding is happening.

If an organization has excellent ownership of internal and external processes, specifically in learning and development, there will be a continuous effort to grow and nurture relationships with and between staff.

This is also why it’s so hard to make improvements to onboarding as a process. You have employees, partners and clients participating in the process at all times.

The only time onboarding ends is when you complete offboarding. Lest we forget; if it’s important to give people access and tools, it’s probably just as important to remove their access and collect their tools.

This brings us to the next biggest innovation gap of most organization’s onboarding process.

Knowing what access, tools and skills each employee, customer or partner company has is an extremely valuable set of data. This value extends to multiple departments, processes and systems. It also keeps the information up to date for audit and reference within other processes and applications.

The easiest way to manage your most valuable assets (your people) is to capture their context when they start. Then manage the lifecycle to continue to keep this information up to date.

The opportunity cost of capturing what tools, access and skills an employee has during onboarding is too great for any organization to overlook.

As your team diversifies the skillsets needed to design and deliver great onboarding efficiency, content and procedures; the onboarding process will continue to improve. And so will your employees.

Stick with this series as we continue to explore on boarding. We’ll cover a myriad of related subjects on this topic.

Better Service Visibility = Better Delivery!

Service disruption occurs when change and release management collisions occur.

How do we prevent these collisions from occurring in the first place?

Even the most sophisticated teams are subjected to these problems; why?

No matter how much planning and automation you have, there are still outages!

Now the service desk is getting hammered with calls and a VP is irate over not being able to reach his “key” system. No one is happy. The world is on fire!

We planned. We strategized… We have GREAT tools! We have GREAT PEOPLE! We AUTOMATE!!!

Why? Why me? Why us?

While you may have planned accordingly, followed the good practice handbook to the letter and thought you understood the decisions in the CAB, you still had collisions. Why?

Because you made decisions based on incomplete information.

There are MANY systems of record that hold critical information related to service delivery. That information is often not all in a single database — such as your ITSM system.

Vacation and business event information? It’s in your messaging system (Exchange).

Customer specific case information? It’s in your CRM (Salesforce.com).

Release information? It’s in your ITSM system (ServiceNow).

If key data related to change/release decisions is not all in the same system, the effort to correlate it may be painful and time-consuming, but; ultimately it is worth it if service is improved. Figure out how to get it correlated — even if it is a spreadsheet. Reduce the risk by knowing what is what.

calendar-video-preview-1
1:56 — A demonstration of a unified calendar view.

We built Kinetic Calendar to enable real-time visibility into key data from multiple applications. it’s more important than ever to be able to cross reference data from those systems. Request a free demo here.

Be a Provider… NOT a Broker!

At Kinetic Data we’ve been talking for years about Service Integration and Automation (SIAM) and building software products to enable Service Providers to deliver at scale.  Understanding the SIAM concept has real value for enterprises looking to achieve successful delivery where service models are distributed across fulfillment silos, and customer experience is of paramount importance.

For Shared Service IT organizations, most have an understanding of the Handshake above 2brokering concept with respect to infrastructure delivery.  In this context, the brokering concept is often referred to as the Hybrid Cloud infrastructure model. In this model, Corporate IT is typically the central provider of infrastructure services, while the actual components making up deployed technology stacks live both internally (corporate data centers) and externally (partner provided, Cloud-based data centers).  Often, Corporate IT may involve many back-end partners in providing those infrastructure components.

At a high-level, the Service Brokering concept appears to solve challenges associated with delivering enterprise IT service in the complex world of today’s global economy. In this model, services are made up of component functions where fulfillment tasks are sourced to provider-partners responsible for delivering their individual part.  While this may seem like a broker model, the reality is that if you view things from the customer’s perspective, the “Service Broker” concept doesn’t make sense at all.  

When I think about my experiences with brokers, some are great and some are not.  Regardless of how good the broker, I’ve ended up (as the customer) having to directly interact with downstream providers to resolve issues related to the service I’ve procured.  I’ll spare the gory details, but offhand I can think of examples with healthcare, investments, house-buying and home repair that make up my experiences.

Each time an issue came up in the delivery of a complex service (home-purchase) and I had to get involved in solving them, it was time-consuming, costly and frustrating. More than once, I decided that regardless of how good the broker was in my initial interaction, I would not use them for the same service in the future as it was easier for me to handle things directly with the downstream provider.  That’s an anecdote for IT outsourcing if you are keeping score at home!

Ultimately, the underlying issues with all of any of these challenging “Service Broker” experiences I have lived were due to the difference between my perception and the reality of the service model I was procuring.

As a customer, I expected an experience where the service being provided was truly integrated end-to-end regardless of who was doing the fulfillment.  What I got was a disparate and distributed service experience that was notintegrated and left me looking for an alternative provider for the future.

So, with respect to Enterprise IT and the idea of “Service Brokering”, think about:

  • A customer procures (requests or buys) a service and expects delivery of it, not just “part of it”.
  • That customer has an expectation (SLA) for that service with corporate IT.  It’s not the customer’s responsibility to coordinate sub-contractor agreements (OLA’s) between back-end fulfillers that comprise the component Sub-Services, nor is it their interest to have any complexity added to their experience.
  • They don’t care if Vendor A is responsible for Sub-Service 1, and Vendor B is responsible for Sub-Service 2.  All they want is simple access to the service and a great experience in it’s delivery.   

If there’s an issue with a downstream fulfillment by Vendor B, it’s ridiculous to expect a customer to care about a missed OLA or further, to get involved in the resolution of a stalled service.  When they come to get service from Corporate IT, they expect a great experience by a Service Provider, not a Service Broker.

If you understand what goes into end-to-end service delivery where there is afocus on customer experience, Service Brokering is nothing more than marketing-speak. Another attempt by industry vendors to try to re-label what already exists and sell it to you as “new.”  The multi-sourced delivery model has existed for decades.  It is not new, and there are real Service Providers out there that truly understand the value of Service Integration in driving excellent customer experience!


Remember:  What matters most is customer experience.  Be a ServiceProvider NOT a Broker!

Kinetic Process Options: Creating Work Orders with Kinetic Fulfillment

Kinetic Data developer/analyst Brian Peterson is  presenting “Kinetic Process Options (Work Orders / Fulfillment)” today at the 3rd annual KEG (Kinetic Enthusiasts Group) Conference.  For those of you who couldn’t make it to the Denver event, or just want to review the session, here are some highlights of his presentation.

Brian is also the coordinator of Kinetic Community and would love to hear your feedback about the site.

Until now, many organizations have had to rely on complex forms with generic fields to assign actionable tasks to their Support Groups.

Just say no to complex, rigid applicationsActionable tasks are actions that need to be assigned to and completed by a person.  These can be actions such as create a user ID, modify access or purchase a tablet. Clients have had to assign actionable tasks using forms and applications that do not effectively capture the important information upon completion. They contain a large quantity of fields which become noise to the users. Generic text fields such as “Notes” or “Resolution” rely on the person completing the task to know what information to put in the task.

There is no simple or effective way to validate the information in a free text field. If information needs to be extracted from this “Notes” field by a workflow process or reporting, the field needs to be parsed.  Parsing a text field for specific information is always complex and problematic.

The workflow process behind these forms are complex and attempt to be “one size fits all.” Modifying the workflow process behind these applications is discouraged by the vendor, and if you do make modification it is very difficult and at times similar to playing Jenga—take out the wrong piece and comes crashing down.  They do not enable  “Your process your way.”

Our clients need more. They have encouraged and challenged Kinetic Data to provide them a solution to these issues within the Kinetic Request product.

Introducing Kinetic FulfillmentOur response to their needs and requirements is Kinetic Fulfillment.

It’s flexible, lightweight and clean with minimal fields.  It is simple and similar to other web forms which users are familiar with and comfortable using.  It can be easily branded and styled to match your company’s standard colors logo.

When automation isn’t possible, our clients need an application to manage and assign actionable tasks to groups or to individuals within groups.

They want it built on Kinetic Request so that it uses a common and consistent application throughout the lifecycle of the request.

It needs to have a workflow engine behind it to  meet their workflow process requirements.

They need a lightweight, clean and flexible solution that is easy to use.  It needs to contain targeted, specific, and relevant completion questions to get the important information upon completion of the task.

Kinetic Fulfillment meets these requirements.

Structure of Kinetic Bundles and Bundle PackagesKinetic Fulfillment is an application built on Kinetic Request.  This type of application is what we call a Bundle Package. Bundles install into Kinetic Request and Bundle Packages install into Bundles.

As defined on Kinetic Community “Bundles are web-based add-ons to Kinetic Request which allow you to quickly create a web interface to your request catalog.”

A Bundle is a deployment or installation which includes shared functionality and branding for a Kinetic Request catalog.

Bundle Packages are similar to a Bundles, but they are narrower in scope and more focused on adding specific functionality. They also includes the elements and processes necessary to support their own features

A Bundle Package may still leverage features and styling of its parent Bundle.  It can dropped into a Bundle and retain the branding and styling as the rest of the catalog with minimal or no effort.

Kinetic Fulfillment is comprised of two major components: Work Orders and the Fulfillment Console.

Creating Work Orders in Kinetic FulfillmentWork Orders are the actionable task records which are assigned to groups or users.  Work Orders contain all of the information necessary for the fulfiller to complete the required task.  The Kinetic Fulfillment application contains all of the logic and events necessary to manage its lifecycle and state.

A Work Order is a Service Item in Kinetic Request. Service Items are the front-end request forms which are built by Kinetic Request.  Service Items are where the questions are presented to the User.

Because Kinetic Fulfillment is built on Kinetic Request, Service Items are used as the framework and delivery for Work Orders.  Specialized features and functionality have been added to a Work Order Service Item.

Developing and maintaining a Work Order involves the same skills, tools and applications as working with requests.  Request developers no longer need another application or additional skill set to create and assign tasks.

This also helps provide a consistent UI and branding with the rest of the service catalog.

Work Order Fields DetailAll Work Orders contain several unique fields which help define it and identify its state.  These fields are located at the top of the Work Order. Your workflow process will give these fields their initial values and assign the Work Order to the correct group or user.

Status is used to communicate the state of the work order.  It tells others and the workflow process what stage of the lifecycle the Work Order is in. Many organizations have their own requirements and ideas of what values should be in a status menu.  We’ve made this list of values configurable so that clients can create status list that meets their needs.

A Work Order has a Company, Organization, Group and User Hierarchy. It can be assigned to an entire group or to a single user in a group. Out of the box, Works Orders can use groups from ITSM or from Fulfillment’s own data source.  However, it is flexible enough to use groups from an alternate data source.

Work Order AcknowledgementsDue Date indicates the date on which the Work Order is due to be completed. The date picker is displayed when clicking on the calendar icon

Priority indicates the Priority of the Work Order: Low, Normal or Urgent. Acknowledged allows the Work Order to be acknowledged without modifying the status.

Entering Work Information on a Work OrderThose of you who use BMC ITSM are familiar with Work Information. In Kinetic Fulfillment, Work Information is used to share information and attachments with the Requester and other Work Order Fulfillers. Work Information may be flagged as public (intended to be shared with the Requester ) or private (intended to only be shared with the Fulfiller). Multiple Work Information records can be added to a Work Order

Example - Tablet Request Workflow ProcessHere is an example process for Requesting a tablet.

  • The tablet is requested.

  • The manager approves the request.

  • The tablet is procured and delivered.

Each Request, such as a request for a tablet or a request for a user ID, can utilize a different Work Order  or multiple Work Orders in their workflow processes.

In other instances, the Work Orders may need to be the same.  The Network ID Request and the Database ID Request may have the same Work Order requirements.  If so they can both use the Work Order.

When multiple Work Orders are created, each can be designed to target specific completion information by including questions unique to their process and requirements.

A Request for a Tablet may need a Work Order to capture the tablet make, model, and serial number upon completion.  A Work Order for a new User ID may only require the ID of the new user to be provided.

Creating a request-specific Work Order can ensure quality data is captured by including specific, targeted questions.  Targeted questions tell the user precisely what information to provide; a field labeled “Resolution” or  “Notes” doesn’t.

For example, a question labeled “Tablet Make”, “Tablet Model” or “Serial Number” tells the user exactly what information is needed.  The workflow process also now “knows” where the Model and Serial number are stored. The information can easily be accessed by the workflow process without needing to parse a generic text field.  This enables workflow automation.  The workflow process can easily update a CMDB or other asset repository with information provided in the Work Order.

Work Orders are built on Kinetic Request so they can leverage other features of the product. As an example, events and dynamic menus can be used to further refine the completion information that is provided to the Work Order, such as: the Nexus 7 is specific to the Google Tablet.  If a different Make is selected, the menu changes to list only the models which relate to the selected make of tablet.

We can also apply data validation to the questions.  Data validation can be used to ensure a valid phone number, username, email address, or IP address are provided.  It could also be as simple as making the answer to a question required.

Work Orders can also be shared by workflow processes. Sharing Work Orders reduces the need for maintenance.  If a change is needed or a bug is discovered, the changes or corrections only need to be made to a single Work Order.

Reusing a Work Order also decreases development time.  When Work Orders are reused, users are already familiar with them.  This provides a consistency to the to workflow processes.

Fulfillment includes the flexibility to use either Shared or Targeted Work Orders.

Work Orders can also be cloned, which makes creating a new Work Order quick and easy.

A Work Order is just a type of Service Item in Kinetic Request.  The same tools and methods are used within Kinetic Request to quickly and easily create a new Work Order to target specific completion information.  A Work Order Service Item Template can be quickly cloned, then have targeted questions added  The use of the Work Order is then defined in the appropriate workflow processes.  The built-in functionality of the Work Order hides these questions until the fulfiller is ready to answer them.

The Tablet Request example shown earlier was simplified; there is more to the processes than this.

In real business scenarios, much more happens than just creating a Work Order. Multiple processes can happen during the lifecycle of the Work Order.  There are email notifications to be sent, SLA Flags to be set, a CMDB to be updated, and perhaps updates made to a customer’s ticketing system which is monitoring progress.

Tablet Request Workflow DetailIn our Tablet Request example, its workflow process creates the Work Orders.  When a Work Order node executes, it creates the Work Order and pauses; the Work Order has its own workflow processes to execute, in this case Assignment and Complete.

Work Order Workflow ProcessA Work Order can have several workflow processes to execute. In a Work Order, there are several triggers which can execute a one of many workflow processes.

Now we have introduced new hooks to executing workflow processes in between the time of creation and completion. Workflow processes can be grouped by event or action, which makes them reusable.

Re-using and sharing Work OrdersNot only can Work Orders be either Shared or Unique, but so also the Workflow Processes can be.

The Purchase Tablet Work Order may have a unique workflow process for Completion.  However, it may share a Workflow Process with Create ID.  Either scenario can be accomplished.

We have created these reusable pieces that can be used to create workflow processes and meet a variety of requirements.  Pick an existing Work Order and Workflow Process  or create new ones and the process for your request.

A Workflow can be executed before Submission. Example uses of this include:

  • Send emails – On Reassignment
  • Set SLA Flag – Modify Values to indicate In Progress
  • Request information from the requestor or another individual – Common requirement to have a request for more information
  • Update an external system – Update with status change

If you can put it in a workflow process, it can be run.

Worflow Automation with Kinetic TaskAll of these Workflow processes are made possible by the Kinetic Task Product.  Kinetic Task is Kinetic Data’s Graphical Workflow Process Builder. The Developer builds a Task Tree to define the workflow process.

Nodes in the tree represent Task Handlers.  Task Handlers are the building blocks of a Task Tree.  Handlers execute the actions and make the decisions in the Task Trees.

Many core handlers are included with Kinetic Task, but we also have a library of useful handlers available on Kinetic Community to perform tasks such as sending approvals and emails; retrieving personnel information; and reading data from / writing data to external applications like Remedy, Salesforce and ServiceNow.  And of course we have a handler to create Work Orders.

The Handlers are dragged into the Task Tree from a list of available handlers, configured and then connected to other nodes.

Process Fulfillment ConsoleThe second main component of Kinetic Fulfillment is the Fulfillment Console.

The Fulfillment Console is the Work Queue for Work Orders.  It allows fulfillers to see what tasks are assigned to them and to manage and view the Work Orders which need their attention.  It is an important tools for managing and prioritizing Work Orders assigned to fulfillers.

Fulfiller can prioritize work queues by:

  • Assignment;
  • Priority;
  • Due Date; or
  • Status.

Additionally, Work Orders are categorized into different tabs such as:

  • “My Work Orders”
  • “Open Work Orders”
  • “Unassigned Work Orders”

The Fulfillment Console includes an additional tab for Searching Work Orders. Work Orders can be opened and assigned from the Fulfillment Console.

Work Orders in Kinetic Fulfillment are lightweight, clean and flexible, with no extraneous fields.

A Work Order can display only Targeted Questions that are required to complete the specific assigned task.  These dedicated fields can also be used to better direct the user to provide specific information needed.  This also gives provides better event management and data validation.

With Kinetic Fulfillment, you’re no longer slave to large applications which attempt to conform their workflow process to fit everything.  You have the flexibility to create workflow processes to meet your unique requirements.   If you want an email notification to be sent, add that to the workflow process. It’s your process.

Each of these processes is reusable.  Build it once and include it in other Work Orders.

Reuse these workflow processes when you can or create new unique workflow process where the requirements are different.  The workflow process executed upon a status change for the Tablet Work Order doesn’t need to be the same as on the Create User ID Work Order.

Execute the workflow process at any point in the lifecycle of a work order.  If you can do the workflow in a workflow process, you can run it at any time in a Work Order.

Thank you!

What’s next?

The Architecture of Enterprise Service Catalogs: Forrester Research, Part 3

The technical architecture of a business service catalog or enterprise request management (ERM) implementation encompasses a system of engagement (user interface), systems of record (underlying ITSM, ERP and other enterprise platforms) and an orchestration engine to manage communication between systems, as well as reporting and analytics tools to help manage and optimize service fulfillment.

Kinetic Request Portal Architecture

Part one of this blog series defined the business service catalog; part 2 detailed the benefits of taking the service catalog beyond IT. This post defines system architecture based on an organization’s current request management maturity level.

In the Forrester Research white paper Master the Service Catalog Solution Landscape in 2013, authors Eveline Oehrlich and Courtney Bartlett define three levels of service catalog maturity. At the most basic level, organizations are focused on “delivering IT services to consumers through a standard set of choices and/or requests.”

At level two, the service catalog automates enterprise services, and at level three it acts as a “service broker.” The ERM concept operates at the intersection of these levels. For example, new employee onboarding is a process—but one that includes much more than just IT services (important as those are), also invoking required services from human resources, accounting, facilities, office management and potentially other functional groups.

According to Forrester, the highest level service catalog architecture comprises the demand side from the business and the supply side capabilities of IT (and other functions and departments). The “demand side” component is defined as “the highest level of the service catalog. It’s the front end, the portal, or the menu that presents only services that solve business user problems…It should be simple, intuitive, and in layman’s terms–too much detail complicates user experience. Less is more.”

That definition correlates nicely with the description of the ideal ERM front end: simple and intuitive (so it requires no training to use), web-based (so it’s accessible anytime, anywhere, from any device), and comprehensive (so it provides “one-stop shopping” for enterprise services, regardless of the department[s] responsible for service fulfillment).

Among the four components that comprise the “middle level” of the service catalog architecture are consumers of the service catalog and interfaces. It should be noted here that the “interface” need not be identical for all users. That is, while the fundamental look and feel is consistent, users can be presented with different service item choices based on their login (e.g., line employees can’t requisition a new hire; sales and other employees who spend a great deal of time traveling may be presented with different hardware options than those who work primarily in an office; etc.).

Finally, among the components of the “lower level service catalog” architecture is “integration with IT systems and business applications.” This is where an orchestration engine, or workflow automation software fits. It eliminates  the need for redundant manual data entry into multiple systems by passing information securely as needed between different enterprise software systems and automating tasks such as management approvals and resource scheduling.

Oehrlich and Bartlett conclude that “In the future, the term ‘service catalog’ may be rendered obsolete, as a service catalog initiative is so much more than just a catalog—it’s the management of the life cycle of various services demanded and consumed by the business users.” This is achieved by an ERM strategy: business users get the intuitive service request, status tracking, and personalization of a site like Amazon.com, within the context of enterprise business service management.

For more on this topic:

Delight Customers and Slash Costs with Enterprise Request Management

In most large enterprises today, shared services are delivered through functional silos: IT provisions equipment and software access, HR manages PTO requests and new-hire processes, Facilities manages space planning and allocation, etc.

If you need one of those services, you work with that group’s systems. If you need multiple services—for example, to reserve workspace, hire staff, and install phones and computers for a project—you’ll likely have to work with multiple systems, obtain multiple approvals, manually schedule tasks, and juggle all of the pieces to coordinate activities with target dates.

Manual Request Management

 

 

 

 

 

 

It all makes complete sense from the standpoint of each individual department. Internally, they may even have optimized certain standard processes (e.g., ordering and provisioning a laptop). Each department is well-versed in and very efficient at using its own software.

The problem is, these processes often make no sense from the standpoint of the (external or internal) customer. How do you determine which group delivers the service you need? (It’s not always obvious.) Why do you have to learn and use different systems to make simple requests? Manually ask for approvals (and create reminders to follow up if an approval isn’t obtained promptly)? Who decided that the “standard” delivery time for a new laptop was X number of days? And for requests that cross departmental lines—why do you have to enter the same information into multiple applications or online forms?

In actuality, those “optimized” intradepartmental tasks often entail processes that waste time, cost more than necessary, frustrate customers, and lead to error-prone duplicate manual data entry. The customer is forced to consciously and actively manage the process, when all they really want is to place a request and receive a service.

Enterprise request management (ERM) is a better approach to managing service requests and fulfillment. In the ERM model, customers can request any type of enterprise shared service (including, most importantly, services that span different functional groups) from a single, intuitive web-based and mobile-friendly portal interface. One front end to use regardless of the type of request, with little to no training required.

The portal routes the request to an automated task management “backbone” application that can automatically manage approvals, scheduling, and fulfillment by securely communicating with and between existing departmental software systems. No one on the service delivery side has to give up the software they are accustomed to or make major investments in implementing and learning new systems.

Enterprise Request Management Approach

Information is entered once, validated, then shared as needed between federated data sources. This saves time, reduces customer frustration, and virtually eliminates errors, enabling consistent first-time fulfillment. Elapsed time, costing, user satisfaction and other reporting elements are automatically logged throughout the process.

This approach also provides complete visibility into the status of a request at any time (similar to online package tracking), so the customer never has to call or send an email to find out “where things are at.” Instead of asking “how long does it take to get a new laptop?” managers can ask “how long should it take?”

The end result is a delighted customer, who now has a single intuitive interface for requesting services and checking on delivery status, and who gets services delivered promptly and accurately and with less effort. The enterprise saves time, reduces the cost of service delivery, and eliminates data errors and rework through automation. Visibility into processes supports continuous process improvement.

To learn more about the ERM approach, download the whitepaper Enterprise Request Management: An Overview.

How to Create a Consistent User Experience (And Why You Should)

What makes Facebook a success?

Obviously it provides a way to communicate with friends and acquaintances; but it’s unlikely it would have been as successful if it had followed the design methods that can be found in too many corporate intranets.

One of Facebook’s major features is “consistency.” Consistent styling; consistent behavior; consistent look-and-feel.

Consistency is paramount to the success of all successful social networking sites. In fact, consistency is such a hallmark of these sites that ANY change to the design makes headlines or at least millions of wall posts!

But even when Facebook does introduce updates and new features, it keeps enough of the fundamental functionality and navigation consistent that users are able to fairly easily roll with the changes.

Consistency and ease of use have driven Facebook’s success. From the beginning, the company knew it wouldn’t be able to scale rapidly if it had to hire a huge support team to help users utilize the site. (Ever tried to reach human support on Facebook? Good luck.)

So they focused, relentlessly, on keeping it simple–so simple that even grandmothers (and grandfathers) with almost no computer experience could figure out how to create a page and share photos of their grandchildren.

The Challenge of Simply UI DesignBut if Facebook was like most corporate intranets, its doubtful users would have returned again and again.

Corporate intranets too often present different styling, navigation and features across different applications, sections and pages. Users experience a chaotic environment where they have to work at navigating through the site. Inconsistency causes confusion for users and results in incorrect choices and incomplete responses and general frustration. In a request fulfillment environment, this results in reduced usage and an increased need for ‘call-back’ from the fulfillers.

Consistency Not Chaos

The example below (one of the standard templates provided with Kinetic Request) illustrates a better approach: consistency, not just in styling but also in navigation and layout. From page to page, navigation elements and “action” links remain in consistent locations.

Consistency and clarity result in higher user adoption, faster service request processing, and smoother workflow for service delivery staff.Request Management Screen Example

With a clear and consistent design, users should be confident after the first page of a number of vital things:

  • Where to expect to find information
  • How to navigate from the page and back to the page
  • How to leave the page
  • How to get more information about an item
  • How to select an option or item

Even complex forms can be simplified by pre-populating fields with known information (e.g., if the user is logged in, the system should already know the user’s name, title, office address, phone number, email and other similar data) and keeping the layout consistent with other pages while removing unnecessary information.

Elaborate Yet Simple Request FormQuestions should be “nested” so that additional questions are revealed only if and when the added information is required.  Complex instructions can be avoided by clear and simple navigation that is consistent between forms.

Consistent site style provides a number of benefits for users: it’s easier to use, more predictable, and speeds the request-to-fulfillment process by avoiding unnecessary support phone calls and clarification emails.

In addition, consistent design benefits the organization by:

  • Controlling ‘rogue’ development
  • Enhancing corporate identity / branding
  • Lessening “silo” effects between departments
  • Unifying fulfillment – especially when it is multi-faceted

This post was based on the presentation “Creating Consistent User Experiences” delivered by Michael Poole and Shane Bush at the 2012 KEG event. You can view details of the original presentation on Kinetic Community or learn more about the upcoming 2013 KEG event.

Lotus Notes Apps Find a New Home in Kinetic Request

Microsoft and IBM have been publicly sparring over whose email/collaboration platform is winning in the marketplace.  Microsoft Exchange/Outlook is clobbering Lotus Notes/Domino in market share, Microsoft says.  Nonsense, counters IBM.  Notes/Domino is as strong as it’s ever been.

We’d have to give the advantage to Microsoft.  While market share estimates vary widely for Exchange and Notes, most show Microsoft steadily making inroads into IBM’s customer base.  A recent IDC analysis,  for example, showed IBM’s market share slipping 5 percent to 37.7 percent, while Microsoft’s market share has grown to 52 percent.

The numbers show that a significant number of large companies have made the switch from Notes to Exchange. Many more are contemplating such a move. It’s hard to blame them. Exchange/Outlook is a more up-to-date platform for email, collaboration, and business process automation. The Notes/Domino platform does a lot of great things, but it’s showing its age, and it’s getting harder to find technical personnel with specialized Notes expertise.

But before organizations make the switch, they have to answer one big question: How do you replace the functionality of all the Lotus Notes applications you’ve built over the years to automate workflows and business processes?  One large financial services company faced the question this year. While it had dozens of Lotus apps, two were especially important. These were service request management applications that automated employee onboarding and provisioning and other approval processes. The company estimated that building these applications anew would require over 2,000 hours of programming. Ouch!

Kinetic Request and Kinetic Task did the job in only 400 hours. (Read More). Now, service requesters go to the company’s corporate intranet, where they are redirected to a single company-branded  Kinetic Request portal.  Besides the 80 percent cost savings, the company got something even more valuable: a request management platform that is completely customizable and allows the company to add additional processes, forms and service items quickly and easily across the enterprise.

If your organization is thinking about switching from Notes to Exchange/Outlook, remember that you too may end up with a bunch of orphaned automated request management processes that once lived in the Notes environment.  How are you going to replace them?  One obvious solution is Kinetic Request bundled with Kinetic Task.