Templates can be authored in different ways and still arrive at the same outcome, however there are normally a few design decisions that they share on a given implementation. These ensure a consistent experience across templates and allows for maximum reuse of elements across templates.
Best practice would be to start with the Model Implementation template () and extend on it to meet the specific requirements of the customer. However, for completeness, the areas to cover are:
- Inbound data dependencies (i.e. when the interview launches, there is a set of data points passed in. Be consistent with which of these will/won’t be used)
- Outbound data dependencies (i.e. data points which are either used mid-interview to lookup data from other systems, or data points which need to be stored as required by downstream system(s) when accessing contract data via API)
(For both inbound/outbound dependencies, ensure the owner of the technical design/integrations are aware/consulted.)
- Stylesheet (i.e. adoption of company house styles, for all templates or only some, etc.)
- Look and Feel Guidelines:
- Multi-list selection (e.g. radio buttons if only 2 options, dropdown for > 2 options)
- Question convention (e.g. when requesting a datapoint, specify the question as “Effective Date: _______” or “Please specify the start date of the contract: ________”
- Limit questions in topic to avoid scrolling, or reduce the number of topics?
- Topic Order
- Output Document Format (i.e. DOCX or PDF)
- Document generated is client ready or a good first draft
Most of the design decisions will be new to the customer (unless they already have contracts automated). You will have a lot of influence to guide the design, so come prepared with your recommendations.
Although customers want a ‘client ready’ document generated, if the contract has many complex elements, it may be better to recommend going live with ‘a good first draft’ and then automate more and more of the requirements over time. This will ensure they are able to go-live quicker - though take the ‘first impressions’ of end-users into account to ensure it’s automated enough to be received positively by the end user community.
Things to avoid
Although templates can be produced in PDF, if there is a chance of them being negotiated, avoid generating them in PDF. The reason is twofold: 1) Every edge case will need to be catered for in the template. And I mean every single edge case. This is often more of a hindrance than a help. And 2) negotiation updates will need to be done through the interview. For users used to working in MS Word, this is often a bridge too far and leads to a negative response / adoption rate.
Only documents like a ‘Supporting document’ (e.g. brochure / prospectus / Terms & Conditions), where the content will not change, will make a candidate for being output in PDF. For the contract itself, the strong recommendation is to always output to DOCX format.