This is the next lesson in your course on Process Automation, showing you how to make your service business more efficient and predictable using ProcessKit.
So far, we've kept things pretty basic. Now let's take it one step further.
We're going to circle back to the first process we created and enhance it with some more advanced automations.
In this lesson, we'll be focusing on dates. Specifically, we'll be giving your tasks start dates and due dates so that everything stays on track and on time.
Traditional project management tools would have you manually set due dates on each and every task. You know the routine: You'd have to figure out the lead time, click through to each to do, select a date and save. Then you might do the same for hundreds of other to-dos. And oh no! Things changed! Our dates are pushed back! Now you have to go through all of those tasks again and change each of those dates.
What a pain!
Luckily, there's a better way :)
It's called dynamic dates. You can use them to let your process handle all of the legwork for you! I'm talking about those tedious date calculations-or recalculations when things change. That can be automated!
In this lesson, I'll show you:
- Setting start and due dates on process steps vs. tasks. What's the difference?
- How a dynamic date rule works and how to set one.
- How to "chain" your process steps using dynamic dates.
- Common patterns and best practices when setting up dynamic date rules
- How dates on real-time tasks get automatically calculated
- What happens if you need to change dates on the fly?
Setting dates on process steps vs. tasks. What's the difference?
As you've learned, you can create processes and you can create task lists made from copies of your processes. So naturally, steps in a process and tasks in a task list look very similar to one another.
But one thing is different between a process step and a task, and that's the way each handles its' start date and due date.
A task is a real-time to-do, and so you can say "this task should start on June 1st at 10:00 am and be due on June 5th at 5:00 pm".
Steps in a process, on the other hand, are not real to-dos. They're just templates. And so you wouldn't give a process step a real date and time as its start or due date.
Instead, steps in a process can have date rules.
What is a dynamic date rule and how to set one up?
A dynamic date rule basically says "This step should start X days before or after something else occurred" or it could say "This step should be due X days before or after something else occurred".
Let's open our "New Client Onboarding" process and set up dynamic date rules on one of its steps.
Go to your "Processes" then click into your "New Client Onboarding" process. Then open the first step and click on the calendar icon to open its date rules panel. Then click the link to "Add start or due date rules".
First, let's add a start date rule.
We want this first task to start immediately when this project starts. So we'll set up this rule this way:
Set it to "0" days and "0" hours (leaving hours blank is the same as entering 0), then select "after" (in this case, since it's happening immediately, it doesn't matter whether you select before or after, but you do need to select one so let's use "after"). Then select "the project starts". Then click "Update" to save this rule.
Once saved, you'll see the rule shown as a sentence. In this case, it says "Start after the project is set to start".
Click that sentence box to continue editing the date rules on this step. Now we're going to add a due date rule.
Let's make this step due 3 days after this step starts.
We could have set it to be due 3 days after the project starts, and in this case, that would achieve the same outcome. But I prefer to think of date rules like a chain reaction. First the project starts, then this step starts based on that, and then this step is due based on its' start date. This way, if we decide later to change the start date rule, we won't also need to change the due date rule.
Click "Update" to save this rule and now you should see both the start and due date rules shown as sentences:
Now go through the rest of the steps in your process and add dynamic start and due date rules everywhere it makes sense.
How to "chain" your process steps using dynamic dates.
A common pitfall when setting up processes in your business is that timelines that you build into your processes don't match what actually happens in the real world. Sometimes tasks take longer than expected to complete, or sometimes they happen faster.
Then all that effort that you put into making your business more predictable kinda flies out the window, if things don't always stick to your ideal timelines.
The way to avoid this common pitfall is to create a "chain" effect in your process so that one task determines the start and due dates of the next task.
So far, we've set date rules on the first step in our process, which is to "Confirm payment and signed contract". Now let's make sure that the next step's start date isn't set until this first task has been completed. We wouldn't want to kick things off the client if we haven't received payment and a contract yet, right?
Open the 2nd step, go to its date rules panel, add a start date rule, and set it to start 0 days after "another task was completed...", and then select that first task, "Confirm payment and signed contract", as the task it will base this one. Click "Update" to save this rule.
Next, give this 2nd step a due date, which will be 8 hours after this task starts. Click "Update" to save this due date rule.
Go ahead and add dynamic start and/or due date rules to any other steps in your process where you think it makes sense. See below for common patterns and best practices when setting up dynamic date rules.
I have gone ahead and added them to all but one step (I left the "hold kickoff call" step without date rules because that will depend on when that call actually gets booked).
The steps that have a start or due date rule will show a calendar icon:
Common patterns when setting up dynamic date rules in your processes:
As a general best practice, the start date should usually be based on a previous step's completion date or due date. The due date should usually be based on the current task's start date. This helps to maintain that "chain" effect.
Another common pattern, as we've already done in our example, is to have the first step of the process start when the current project starts. Or, you might have this first step start when this task list is created. That's useful when you expect the current task list would be created a bit later in this project's lifetime.
As you near the later steps in your process, you might choose to base a step's dates on the project's end date. This is useful when you're using the project end date to mark the final delivery date, or perhaps a final publication date. This way you can build steps that provide proper lead time before or after this project end date.
How dates are automatically calculated on real-time tasks
Now let's see these dynamic date rules work their magic in a project with real-time tasks!
Go to your "Boards", then go into your "New Client Onboarding" board, then create your next onboarding project, to onboard our newest client, Oceanic Airlines. Call this one "Onboarding of Oceanic Airlines".
Once you're in this new onboarding project, you'll notice that the first task has automatically calculated its start and due date based on the time you created with this project (which was just now).
However, the rest of the tasks don't have any dates set on them. Why is that?
If you remember, the 2nd task's start date rule is based on when the first task has been marked completed. We haven't yet completed the first task, so this 2nd task's dates are yet to be determined.
But do you notice the little "bolt" icons next to the blank dates on the 2nd task? This indicates that these tasks currently have date rules set on them, meaning we expect they will be filled in automatically on some future date.
Now let's go ahead and check off that first task to mark it as completed. A moment later, you should see your 2nd task's start and due dates automatically fill themselves in. They"ve been calculated based on the time you completed the first task. Pretty cool, huh?
Assuming you've built out a "chain" of date rules in the subsequent steps, you'll probably see those fill in as well. For example, in the 3rd step, I set a due date rule to say it should be due 3 days after "another step was due", that other step being the 2nd step. So now that the 2nd step had its" due date set, that caused the 3rd step's due date to fill in as well.
What happens if you need to change dates on the fly?
Now what happens if things change (as they so often do!)?
Let's play out two scenarios:
Your client verbally agreed to sign up for your service, but they said they're waiting for their funding to come through before they proceed with payment and contract. They said it'll be an additional two weeks before they're ready to start.
Since your first task in your onboarding project is set to start when the project starts, you can simply edit this project's start date, pushing it back by 2 weeks. That will cause your first task's
start date to recalculate to match that new, pushed-back, project start date. Then the other chained dates, like this first task's due date will also recalculate accordingly.
To change this project's start date, you would go to this project's "Details" tab, then click to edit the project start date and select a new date and time using the date picker. Click "Update" to save the change.
Your client signed up, paid, and signed the contract and you've checked off that first task (or perhaps that was checked off automatically when the payment landed? That's possible, ya know. I'll show you how in a future lesson). Either way, off to a good start!
But your client also informed you that they will be out of town for a week, so they won't be ready to kick things off until after they're back.
Normally, your 2nd task would start immediately. But your client is away, so you'd rather delay this 2nd task until after they're back (you don't want to bug your client with emails while they're traveling).
How do you handle this?
First, you'll want to manually change the start and due dates on your 2nd task to a more appropriate day/time, the day after your client said they would be back and ready to start. Change these dates manually, then click "Update" to save these changes.
Now your 2nd task will start when you need it to, but it didn't disrupt any of the other tasks date rules that come after it. The project will flow normally once things kick off next week.
Optionally, you can tweak the date rules on your tasks, if you need to. Any changes you make to these tasks' dynamic date rules will not impact the original process template, nor would it impact any other projects that have tasks built from that process. Since you're working within this project, you're only editing this instance of this task list.
By clicking "Manage date rules" on this task, you can see what the date rules currently are, you can change their settings, or even remove the date rules altogether.
In the next lesson...
If you thought dynamic date automations were powerful, you ain't seen nothin' yet!
Next up, we're going to add automated actions that can fire off after a step in your process has been completed. We'll cover Task Actions in the next lesson.
Have questions? Need help or advice on mapping out your processes in the right way? I love talking process! Get in touch and I'll be happy to work with you in your ProcessKit account.
Haven't started using your ProcessKit yet? Start your free trial.