Automatic generation of letters
This is part 2 of 2 on text generation. This builds on part 1, so to get the full picture, I recommend reading that post first.
In essence, we generate letters in the following way: The system selects the appropriate letter template for the situation, uses information from the case file to determine whether certain phrases should be included in or excluded from the letter for this specific case, and fills in merge fields to customize the phrases for the specific case. Finally, the letter can be sent to the recipient, either through Altinn or by printing it out and mailing it.
To generate letters automatically, I will use a letter template and a document template. The letter template contains standard phrases and rules that determine which phrases should be included in different situations. The document template defines fonts, font sizes, line spacing, margins, how we number pages, etc. The advantage of having both is that you can define a document template once, and then anyone who wants to follow that same document template can simply specify that their letter template should use a certain document template. It’s faster to create new letters when you don’t have to figure out all those details, and the letters look consistent without everyone having to go out of their way to get it right. You simply say, “This letter template should use the standard document template,” and you’ll get the organization’s preferred font sizes, fonts, etc.
Letter templates define the content of a letter. You can have a letter template for multiple situations and control the content using various rules. In that case, a single letter template can include text for both approving and rejecting an application. However, if most of the content for the two situations differs, it may be wise to have two letter templates: one for approval letters and one for rejection letters.
A letter template can be created by including some standard phrases and some phrases that are only included in certain cases, depending on the nature of the matter. For example, a letter template might look like this:
Document template = Standard letter
Application Processing/Grant Letter/Heading
Application Processing/Grant Award Letter/Introduction
Application Processing/Grant Letter/Justification
<SpesiellSak == true> Søknadsbehandling/Innvilgelsesbrev/EkstraInformasjon
General/Right of Access
General/Relevant Rules for This Letter
General/Contact Us
General/Signature
Here we have many standard phrases, and one phrase that depends on the “SpecialCase” field being set to “true.” In other words, a phrase that only appears in some approval letters. More on this field and similar ones in the next chapter. We have some phrases that are specific to this grant letter, and some phrases that are common to other letters. The phrase Common/RelevantRulesForThisLetter will have different content from letter to letter, since what it actually contains are the legal references to which the letter’s phrases are linked. Nevertheless, it is a common phrase that contains the logic for compiling the legal references for each individual letter.
Using the letter template
When you work on case processing, you make certain decisions. We need to communicate some of these decisions in a letter. Some cases are unique in themselves, for example, due to the applicant’s circumstances. How will the system know which phrases to include in a letter? We need to define some rules for selecting which phrases should be included in the letter. For example, we could have a rule that says “Given that the applicant is under 18, text regarding minor applicants must be included in the letter,” or “Given that the case worker selected ‘Yes’ on screen 4 (‘Is this a special case?’) then text regarding special cases must be included in the letter” or “Given that there are late payment interest charges in the case, text regarding late payment interest must be included in the letter.” In addition, there are various numbers, names, and other details that must be included in the letter. For example, the applicant’s name, the applicant’s address, the current late payment interest rate, today’s date, or the amount to be paid.
I will describe one way to structure this. I am assuming that the system has several technical components, and that the letter component is a shared component used by multiple case management components. I assume that the general letter rules are located in the letter component, while the rules for extracting the information we want to include in the letter are located in the case management component that is closest to that information and where the expertise for that case management resides. Then we must gather information about the case in the case management component and send it to the letter component.
We need to define rules for extracting the desired information and structuring it in a way that is agreed upon with the mail module. One way to do this is in JSON format, similar to what is shown here:
{
"name": "Per Persen",
“address”: “Gateveien 1”,
“late payment interest rate”: 12.5,
"specialCase": false,
"minorApplicant": false,
“Date of decision”: “October 25, 2024”
}
The letter module uses this to determine whether the phrases "Application Processing/Approval Letter/Introduction" and "Application Processing/Approval Letter/Special Case" should be included in the letter, and to populate merge fields in the phrases.
We also need to choose the language variant. We have all phrases in Bokmål, Nynorsk, and English. Which ones should be used for a given recipient? Perhaps we have a customer database or some other type of registry where we have the preferred language variants for different users. In that case, the letter component can look up the preferred language variant and select the correct version of all phrases. We should define a rule for what to do if we don’t have phrases in the desired language variant. For example, whether we want to display an error message, use the available language variant, or forward the case to a human case handler to write the letter manually.
Conclusion
There are many advantages to handling letters and phrases as described here, but there are, of course, some drawbacks as well. It takes a lot of work to get everything set up. It can be a major change from how you write letters today, especially if there are tasks that case workers currently perform manually. Such a change requires not only IT development but also change management. Case workers may feel they are losing control over the letters, and you must ensure they trust the automatically generated letters. Organizations of different sizes and with different goals and frameworks can benefit from different aspects of this. One advantage is that you can use the phrase library table to achieve a more consistent structure and text in the letters even if you don’t have any of the technical components to automatically generate letters. I’d also like to remind you that it’s possible to use this generally to generate text, not just for typical “letters.”
The most important thing is to assess whether you are satisfied with the way your organization communicates in writing. If you are not satisfied, you can start by considering what you want to achieve, and then identify appropriate measures. These may include some or all of the measures described here, or they may involve other measures and solutions.
