Sales has taken several steps to setup their IA following best practices for Office 365 and SharePoint. That is, defining the Intranet site hierarchy, site content types, site columns, lists, views, and so on. This foundational work was necessary in order to improve discoverability, usability, and re-usability of data that is important to successfully executing Sales Contract Lifecycle Management (CLM) as well as generally improving collaboration internally and business management development with team members in other divisions. The next few posts are going to elaborate on these various topics. First, let’s see how sales is going to leverage their improved re-usability of data that drives the CLM with a Document Library Template.
They’ll do that by creating a standardized Microsoft Word template for their contracts that specifically addresses a pain point that was covered in one of the first posts in this series, “In the current state, it’s almost impossible to run any real metrics against sales contracts and performance. All data critical to effective mining and analysis is embedded directly in the documents”. Also, that same post highlights, “…there are multiple versions of the sales contract template that have been used over time – there is a learning curve, cognitive dissonance, frustration, and yet again lost productivity as sales team members manage contracts in their various formats”.
Getting at the Document Library Template with SharePoint Designer
Now that Sales has consistent data published outside of contracts (i.e. the actual body of the document) by building their Sales Contracts document library on a standardized site content type, they’ll continue to build-upon that framework. They’ll integrate that structure into the default Sales Contract documents by tying their content type and site columns directly into the body of the contract. As mentioned before, TMTOWTDI in SharePoint. What we’ll demonstrate here is setting a standard template for Sales Contracts on the library itself instead of the other common way, which is to define the template on the site content type. With the latter, every library built on the content type will always have the same template, but there are outlier cases for Sales Contracts where different templates will be needed for different document libraries built on that content type. For example, those not included in the formal Contract Lifecycle Management (CLM) process. Therefore, Sales will create the custom template directly on the Sales Contracts document library. Here’s the steps they take, starting with launching SharePoint Designer and connecting to their O365 SharePoint site (if you’re following the series, you’ve learned how to do this in previous posts). Note, there’s even multiple ways within SharePoint Designer that Sales could follow to do this, but here’s what’s recommended in this scenario:
- Launch SharePoint Designer
- Click “All Files” in the Navigation task pane
- Drill into the Sales Contracts Library
- Drill in again until you find template.dotx under, specifically, the Sales Contract folder
Promoting Document Library Properties into the Template
Now, click on the template, and it will open in Microsoft Word. Once there, build out your starter template.
*In advance, note that “Sales Contract Title” is not going to be available in the Quick Parts UI you see used to build out the template. Calculated fields require more advanced work-arounds to get them to show-up in the Quick Parts picker, and the ROI will probably not be worth it…maybe Sales will update the template in the future.
Validating the Document Template Properties
With that done, let’s look at creating a new contract for the Contract Lifecycle Management (CLM) process with the new template. Sales will specify some basic properties, and then, when they open the template, they’ll be ready to go with certain information already present and other placeholders ready to guide them through the authoring process. Remember, this is a simple example. You could have multiple pre-drafted paragraphs, custom headers and footers, more properties, etc. already in place to ensure consistency, accuracy, and greatly reduce the amount of time it takes to find, author, and update sales contracts.
*In advance Quick Parts will not be populated in the Microsoft Word Online interface. At this point, the contract effectively needs to be opened in the Microsoft Word desktop client. You’ll see this (and how to launch the Microsoft Word rich client) in the demo. I can definitely imagine this changing in the future as Microsoft continues to improve fidelity between the Microsoft Word Online interface and the Microsoft Word desktop client:
Almost 100% – the formatting disappeared on the Customer Name (I’ll investigate that). But, regardless, prepopulated information directly in the document that is also available to filter, sort and search with. You’ll see how Sales approaches all of that in upcoming posts.