RSMUS.comEven though electronic signatures were established in 2000 by the US Federal government’s ESIGN Act, there are still relatively few e-signature options specifically designed to work with Microsoft Dynamics CRM. Not surprisingly, each of these tools takes a slightly different approach to generating the document and managing the subsequent approval process.
Some are strong on the document-generation side, while others use fixed templates on top of an un-editable XML document base. Other products leave it to the Dynamics CRM end-user to drag-and-drop signature locations when initiating every document. And, when a document is complete, some tools move that document into Dynamics CRM while others make it available from within their cloud.
Given the lack of standardization in this space it’s important that you carefully understand your company’s unique requirements and choose a tool that best meets your special approach. In this blog, I’ll present some tips for that selection and implementation process.
Don’t forget the document
The general concept of an e-signature is easy to understand: an email is sent to the signatory with a link which, when clicked, takes the user to what is most often a site hosted by the e-signature service. There they can preview the document and indicate their agreement by typing their name or, in some instances, actually signing the document with a touch-enabled device such as a smartphone or signature pad.
The generation of the document, however, is often more complicated. Some Dynamics CRM ISV e-signature products rely on documents written in SSRS. Other products require the Dynamics CRM user to drag-and-drop signature fields onto each document prior to distribution. Another service requires that templates for each document be generated in their own, proprietary editor, in which you paste the Dynamics CRM fields and e-signature locations on top of an XML document.
When evaluating an e-signature add-on, make sure you understand the specialized skillset required for generating and maintaining the documents needing signatures prior to making your final selection.
Mind the Entity
Regardless of the tool you choose to use, remember that the actual initiation of the document generation and e-signature distribution takes place within Dynamics CRM from the specific entity your user has open. This means you’ll need to choose carefully the entity from which your document is built and the e-signature process initiated.
In some cases this may seem like a no-brainer. For example, if you’re using Dynamics CRM for sales automation and the document to be signed is a quote, then the process should be initiated from Dynamics CRM Quote entity. But, as is often the case in Dynamics CRM for customer service, the selection may be less intuitive.
Consider the scenario for a social services agency. A prospective customer might contact the agency, be assigned an agency representative like a caseworker, walked through an application process over the phone and then required to electronically sign the application before proceeding. In this instance the Dynamics CRM fields you might want included on the application could be the customer’s name, address, date of birth and social security number. This might lead the designer to build the template and e-signature process from the Contact or Account entity. However, such an application would likely also need to have some type of case number on it as well as information about the caseworker assigned to the prospect. Over the prospect’s lifetime, they might require more services from different agencies and be assigned different caseworkers for each. Therefore, if our form were built off the Account entity, Dynamics CRM wouldn’t be able to tell which case number or caseworker should be used – meaning the Dynamics CRM user would have to enter this information by hand, creating opportunities for error, lengthening cycle times and hampering adoption. If, on the other hand, our form was built from the Case (Incident) entity in Dynamics CRM, the software can definitively determine the case worker’s identity and contact information, as well as the case number. And, because there’s an out-of-the-box 1:N relationship between Account and Case, our process could also gather the necessary contact information for the prospect.
Your e-signature process is only as sophisticated as your least sophisticated signatory
What’s the key Dynamics CRM field needed for any e-signature process? The signatory’s email address, of course. Without it, there’s no way to let them know a document is ready for their signature. And, since the link sent via email is unique to the recipient, the signatory’s email address also serves as a sort of virtual identification that it is the intended signatory who is signing.
In a B2B environment, such as our quote example above, one can safely assume that each customer is going to have an email address. But, such an assumption can’t be made in a typical B2C customer service scenario. In fact, revisiting our social services example, we can’t even assume that the customer has access to a computer. You can certainly use an e-signature solution for those customers that have email addresses. However, you’ll need logic that uses document templates without e-signatures and routes those documents to snail mail to accommodate those customers without email addresses.
Don’t confuse e-signatures with simple approvals
As with any other automation project, the temptation may be to simply roll-out e-signatures for any Dynamics CRM-produced paperwork that gets signed by anyone today. But, if you take that approach, you may be over-complicating your new automated e-signature processes (and overspending while you’re at it).
Why? In a paper-based process, the only way I can give my approval is by signing something. Now that you’re rolling out Dynamics CRM, getting someone’s sign-off could be as simple as approving the corresponding entity in Dynamics CRM. For example, if a customer quote required your salesperson’s signature, followed by his/her supervisor’s, prior to submitting to your client, those first two steps can be effected through Dynamics CRM, leaving your customer’s signoff as the only one necessary in the e-signature process.
Where’s my executed document?
What happens when your document has been signed? Typically, the e-signature software will send an email to the originator telling them the process is complete. This message also provides a link to the executed document which, most often, is the hosted service of your e-signature software.
But is that the final resting place you really want for completed documents? How are you going to find that link three months later? Or, if you’re like me, three days later? And how could any other Dynamics CRM user possibly find it? The fact is that not all e-signature tools for Dynamics CRM provide a convenient way to retrieve completed documents within Dynamics CRM. Therefore, when implementing e-signatures in Dynamics CRM you should be prepared to develop some basic integration so that an executed document is easily retrievable within Dynamics CRM. One common integration we use at RSM is between Dynamics CRM and an enterprise content management system such as SharePoint or OnBase. When the e-signature software returns a message to Dynamics CRM that a document is complete, this integration retrieves the document from the hosted service, deposits it into the enterprise content management system and places a link to it in a subgrid (call it “completed documents”) off the originating entity.
If you are interested in implementing e-signatures in your Dynamics CRM solution, RSM can help. Our Dynamics CRM specialists implement solutions from basic ‘out of the box’ model to complex architecture. Contact our professional for more information at crm@rsmus.com.
By: Daniel Meindertsma –Illinois Microsoft Dynamics CRM partner
