Today's post was written by Trent Bell, Principal Consultant at Sonoma Partners.
Usability is “king” when it comes to CRM because the biggest killer of CRM is lack of user adoption.
It is a self-perpetuating reality. If it becomes difficult to enter data, then data will not be entered properly, if at all. If good data does not exist or is incomplete, then your CRM can no longer be trusted, thus having no value. It is vitally important to take “ease of use” seriously as you design your CRM solution.
So, how does this relate to Microsoft Dynamics CRM's business process flows? There are a few usability concepts I would like to call out that are potentially affected by BPFs.
Concept #1 - User-guided Process
One might argue that the BPF concept’s main goal was to assist/guide users through the input or absorption of data as part of a business process for a particular record. If the business has a defined process, then this can be a big benefit. The use of BPFs breaks down in the case where an organization does NOT have a well-defined process around the particular data. This one is somewhat obvious.
Concept #2 - Good Form Design
Most of us know the importance of “good” form design, where we try to strike the right balance between having an ample amount of fields on a form to be valuable while not over-cluttering it or creating a data-entry chore. The BPF concept can be a great tool to assist with this idea by allowing you to get creative with the placement/usage of fields either in the BPF bar or in the body of the form…or both.
Strategy – The Checklist
While this is not the “end all, be all” answer, one strategy to consider that incorporates the concepts listed above is to simplify the user experience by only placing “checklist” type fields in the BPF bar. This means all fields with real data values would be placed in the body of the form. For example, instead of having a “Key Strategy” long description field in the BPF bar, place that field in the body of the form and create a new “Yes/No” field called “Key Strategy Determined?” that will go into the BPF bar. The basic idea is to create “checklist” type fields for the key milestones or key data captures relevant to the ideal process you want your users to follow. While it requires the creation of extra fields in the entity, the consistency and predictability that this approach provides to the BPF bar and body of the form can create clarity for the end user.
A few pros and cons that come to mind with this strategy include the following:
- BPF bar has consistent and predictable entry/feedback
- “Data completion” status within a record is easily determined
- Reporting is more simple (advanced finds can be done eliminating left outer-join issue)
- Form body for data entry is more traditional
- Creation of extra fields (checklist fields) to be managed
- Need space to place all data entry fields in the form body (could be an issue if many fields exist)
I want to make it clear that I am NOT advocating for this to be the one and only approach to configure BPFs, but I do believe it can be an effective strategy for some situations. Some key factors that may make your organization a candidate for this approach are:
- You have defined processes
- You need to report on your users’ data entry practices
- You want to highlight key data milestones
When business process flows were first introduced, I loved the idea of bringing certain fields up from the body of the form into the process bar, allowing attention to be focused on key fields. The BPF feature also provided the opportunity to decrease form length. With that said, I've seen users get confused or reluctant to embrace the BPF concept like I expected. My hunch as to why this is has to do with mixing data entry and checklist type fields within the BPF bar and form body. While it seems intuitive enough, I have found that this specific inconsistency can throw off some users. While this “checklist” strategy may not work for everyone, I do believe it to be an effective and viable approach.