A suggestion for automating Personal Tax payment reminders

Glide's e-mail and SMS automation system is designed to automate the sending of routine messages for which a template can be created in advance of sending.

We have seen several customers successfully use this to automate Personal Tax payment reminders - both for the 31 Jan payment and the subsequent 31 July payment on account (POA).

We share below one way in which you might set about achieving this. This particular solution adds a separate sub-system to your tax return workflow system and also caters for scenarios where your clients have refunds payable to them. Neither of these two aspects are crucial to sending the e-mail and as ever there are numerous other ways to achieve the same - we just happen to like this particular approach.

1 - Set up a new sub-system within your tax returns workflow system called 'Payment/refund' [or something similar]

I like the idea of housing all payment/refund aspects in a separate sub-system. There are a couple of reasons for this:

1. You can progress this separate to the main tax return which becomes useful should the tax return become late etc. For example if the tax return is stuck on 'Awaiting client approval' then you can still progress your payment workflow to confirm you have sent out reminders etc.
2. You can get the satisfaction of completing the tax return workflow ASAP following 5th April. It does not have to stay open on a final stage such as 'Confirm POA made' as responsibility for this is handed over to the new sub-system.
3. As with any supplementary sub-system you will benefit from both sub-jobs being visible on the same job card as well as the payment/refund sub-job having its own job holder, current stage, next target date etc.

The image below demonstrate an example workflow, this screen shot is taken from the workflow configuration area. As ever the blue rectangles represent the stages our job might occupy and the grey rectangles represent the steps that will take the job from one stage to another. 

In addition to the payment reminder, you'll see how the job has the option to track payment of a refund as well as an option to close the job. The latter option would be relevant if there were no balance payable or if you did not complete the return for the customer for any reason.

The annotated notes explain some of the key features which we expand on further down this article.

Incidentally here's how this sub-system would look when you are looking at its progress monitor widget.

When setting up the new sub-system follow these tips:

• I recommend having the stage bar and deadline bar positions set to left for your main tax return workflow and right for your payment/refund workflow. This creates a nice distinction with one sub-job on each side of the screen.
• Additionally I would recommend changing both colour settings on the tax returns sub-system to something other than the standard blue and both colour settings on the payments/refunds job to something different again. This helps make the screen visually easier to follow. An example screen grab of this setup is included at the bottom of this article.
• Can be disabled? We recommend setting this to 'Yes', especially if you want to be able to deactivate the system for some clients, on a client by client basis. This might be relevant to say partnership and trust returns.
• Default status We recommend setting this to Active for all INVD clients. This would mean that all individuals on the system default to being active (you would need to deactivate any that do not have the tax return service). It would also mean that organisaitons default to being not active, this seems logical.

2 - Link in to progress on your main Tax Return sub-system

You can not send out automated payment reminders unless you have accurately completed the tax return. Therefore the payment/refund job should remain firmly routed on that 1st stage 'Tax return not yet approved' until such a time as you are happy the return and associated liabilities are not going to change. For me the logical point is when the return is approved by the client. When we come to setting up the automated e-mails we will ensure they only send for jobs that have reached the stage 'Approved - payment due' on our payment/refund workflow.

This builds extra control into the system to ensure e-mails are not sent out with incomplete data.

Your main tax return workflow will inevitable have a stage called 'Awaiting client approval' and might currently just have the one step called 'Return approved by client'. If we want to automate the progress of the refund/payment job onto the appropriate next stage (you'll see in the top image (above) that we suggest 3 stages) then we need to tell Glide which situation applies. We therefore recommend you have three steps to confirm that the return has been approved, one for each possibility. Providing this greater clarity in the main tax return workflow allows you to automate the progress on the payment/refund job; however, there is another nice alternative which I discuss in supplementary note 2 below.

In the screen shot below you can see how I have changed the steps that lead away from my 'Awaiting client approval' stage - to confirm this is happening on the main tax return sub-system, i.e. your existing workflow that tracks progress of the return.

Here's how this would look on a tax return job card.

Now that you have these three steps we can add an Auto job progression workflow action to each. This will mean that when a user clicks on the 'Approved by client - payment due' button the system will automatically progress the payment/refund sub-job down the 'Payment due' step we have set up.

If you are not sure how this ties in look back at the 1st screen shot at the top of the page to see the grey 'Payment due' step. Pushing the 'Approved by client - payment due' button on your tax return sub-job will move the payment/refund sub-job from the stage 'Tax return not yet approved' to the stage 'Approved - payment due'. When we come to set up the automated e-mail we will ensure it is only sent in relation to jobs that are on this stage. Therefore if the user presses the buttons 'Approved by client - refund due' or 'Approved by client - no balance' then the e-mail will not be sent.

Of course if the user presses the wrong button then they can manually change the current stage of the payment/refund job to avoid the e-mail being sent.

When setting up the Auto job progression workflow actions you'll see 3 drop down boxes for settings. In these make sure that you:

• In the first drop down choose the 'Payment/refund' sub-system. This confirms that we want to automatically progress that part of the job.
• Change the 'Move it wherever it is' filter so that the action only moves the job where its current stage is 'Tax return not yet approved'. This provides more control because someone may have already progressed or even completed the payment/refund job manually because they know there is no balance due etc. We do not want to drag these jobs back onto the key stage which will ultimately send the e-mail.
• Link the button to the correct step so that the auto progression goes down the correct step and places the payment/refund job on the correct stage.

3 - Capture liability/payment data in your job via job fields

Depending on the level of detail you plan to include in your e-mail template you will most likely need some job fields to capture the information.

If you simply plan to send a very generic "You may have a tax payment due on the 31st January, please check previous correspondence." then you might not need any.

To maximise the benefit of the automation you might well wish to convey information in the e-mail such as the payment amounts, this will require job fields. Examples we have seen are listed in the table below.

Here's some guidance on how to add a job field. For all of these suggested fields we recommend the data type String (short). They are all less then 20 characters and by using a string you can control the format of values such as £0.00 how you desire, e.g. n/a or £-. You could alternatively use the currency data type for those holding an amount, this would work fine too.

4 - Make entry of the above fields mandatory BEFORE your job can reach the stage that will trigger the e-mail

Wherever your e-mail templates include merge fields you need to design the workflow and e-mail triggers in such a way that makes it completely impossible for a message to send where the merge field is empty.

In our example, thinking specifically of the 'Payment reminder' e-mail, we shall make all of the above job fields mandatory before the user is allowed to click the progress button 'Approved by client - payment due'. If you were also automating an e-mail in relation to the refund then you would likely have different job fields designed to merge into your refund e-mails. You would then make completion of those refund job fields mandatory before you can click the button 'Approved - refund due'.

To achieve this mandatory status we need to add workflow actions, one for each job field, to the relevant buttons. The workflow action we need is called 'Traffic light - field completed'. You add these workflow actions to the relevant progress button. The affect will be that it becomes impossible for users to click the button unless they have completed the fields. In turn, given we are only going to send our e-mails when the job is on the stage 'Approved - payment due', it becomes impossible for the e-mail to send without these data fields being populated.

Here's a reminder on how to add a workflow action to a step.

5 - Design your workflow template(s)

Next you'll need to create the templates for your e-mails. You'll be able to include any of the job fields created above.

Guidance on how to create an e-mail template is available here. You would choose to make a job template(s) that is linked to your Tax Returns workflow system.

6 - If you haven't already tagged contacts - get this set up now

When ever an automated e-mail or SMS is configured for external sending you can choose one of two methods for how the system should decide who to send the message to. These options are described here.

Option 2 (contact tagging) will take time to setup if this is your first automated message; however, it is a far better solution because it ensures you can use the 'first' and 'last' name merge tags in your template, it allows you to filter which clients/contacts you wish to receive the message and it allows you to send the message to multiple recipients per clients. The latter point may be less relevant for personal tax e-mails but will make a big difference when sending e-mails in relation to organisations such as Corporation tax reminders etc because you can e-mail multiple directors etc.

If you choose Option 2 and need to set up your tags now this article describes how to apply contact tags. If you need a new tag for this purpose this article describes how to create a new tag.

Note that the 'first' and 'last' name merge tags will work on option 1 where the clients are all individuals. This option might therefore suffice for Personal Tax payment reminders and of course you can always use option 1 where you avoid the recipient merge tags.

7 - Finally -> set up the automated sending of the e-mails

Automated e-mail and SMS that are created via a job template can be sent in one of two ways. Either by a workflow action or by an alert.

Both of these options can work in this case, we describe how you would set up each below.

Workflow action

Under this option you would trigger the creation of the e-mail when a progress button is clicked. For example the 'Payment reminder sent' button that we can see in the workflow image at the top could both send the 31/7 payment reminder e-mail and complete the payment/refund sub-job. Assuming this tax return sub-job was also complete (seem likely given the earlier deadline) then the job would at this point be fully complete.

Follow the guidance here to set up the sending via a workflow action.

Make sure you choose the correct template and the correct tag - these are the only settings you need to make for this option.

To send the e-mails via this method you would be fully in control of the timing as it requires a user to click a button. For example, for the 31 July POA reminder e-mail you might decide to click the button on the 30 June so that they are sent 1 month ahead. Be sure to bulk progress jobs ( guidance here) so that only one click is needed as opposed to one click per client.

Under this method we would recommend having a stage for the 31 Jan payment reminder (not shown on our example diagram). Pressing the progress button on this stage would both send that e-mail and progress the job onto a stage for the sending of the 31 July payment reminder. Pressing this button would both send the 31/7 reminder and complete the job.

You can manage with just one stage, but having two seems a lot more controlled as a user would never see the wrong button and therefore it would be impossible to click the wrong button.

Alert

With an alert the sending of both e-mails would be fully automated. This saves the single bulk click required in the above method. That said you would at some point need to do a bulk click to complete the jobs. Therefore this method likely only saves time for the 31/1 e-mail and not the 31/7.

We are looking to automate job progress based upon an alert firing so this may become the logical option in the future. In addition you can do this already if you have a Zapier paid plan, you can use the Glide progress button to trigger a webhook, which triggers a Zap, which then progresses the job!

Follow the guidance here to set up the sending via an alert.

Here are some important settings:

• The logical 'linked to' setting would be Job date - this will be the tax year end e.g. 05/04/20 for the 19/20 year.
• For release filter choose Only send if the stage order value = x. Enter the stage order value for your 'Approved - payment due' stage and also ensure no other stages use this order value. Release filters and stage order values are explained in more detail here. This will ensure the e-mail only sends in relation to jobs that are on this stage. As we have used traffic lights we also know that all jobs on this stage will contact the necessary job field data we have merged into our e-mails.
• The offset would be a positive number and would be the number of days after the 5th April you wish the alert to send. So for example:
  • Sending on the following 10th January would be 280 days.
  • Sending on the following 10th July would be 462 days.
• Choose your template and the contact tag and set the send method to E-mail.

8 - You're all set - here are some other tips and testing ideas

• Remember to decide whether to set the templates to queue or send immediately. If you queue then you can look at a few of them before deciding to bulk send those messages in the queue.
• Check your from / reply to / signature / auto bcc / server settings.
• Consider including links, dynamic links and images in your template.
• Set up a test job and send a test message. You can easily simulate a test via a workflow action send. If you set up an alert you would need to tweak the offset and wait until tomorrow for it to come through (unless you did the test first thing - alerts end at 09:30 each day). When testing on a fake customer use a personal e-mail address as opposed to your work e-mail. If you use your Glide login e-mail then the first name and last name merge fields will not work.
• Please get in touch by clicking support (towards the top right of this screen) if you need any help.

Some supplementary notes to the guidance:-

1. When you set up a new sub-system a sub-job will be added to all existing jobs; however, it will be in a deleted state. If you happen to add a sub-system just after your tax return workflow system has created all of your jobs for the new tax year then this will mean you need to activate the sub-job on each of your existing tax jobs. You can do this in the edit job area; however, if you have lots of jobs the Glide team can do this in bulk for you too. We shall be looking to create the ability for you to do this in bulk too. If you activate the sub-job via edit job then the creation step will be run which might be useful if you have this set to create targets, update the job holder etc.
2. If you do not wish for your main tax return sub-job to auto-progress your payment/refund sub-job then you can of course just ask users to pres the progress buttons on the payment/refund part of the job card. In this event we would recommend you use a workflow action that blocks those buttons until the tax return sub-job has reached a stage that means the job fields must be completed. This is the traffic light (min order) workflow action.

Example job card

Here is an example job card with our two sub-systems and the layout recommended above.