Mar 27, 2023 12:10 PM
I am new! Been watching and reading lots of tutorials but I just can't wrap my head around this one... I am a flower farmer and I deliver to a set of customers twice a month. They are not always the same day. Last year, I looked at everyone's requests for the month, manually put it into a google calendar and manually emailed each customer each month.
I have all my customers in a table, then I tried building out a 'tasks' table and using calendar view. I see that each record is considered a 'task' and can have one date on the calendar.
If I enter each customer and give it a label of what delivery they are on, I can create one task per delivery, but that means I am entering each customer twice a month (see screen shot)- this seems like a lot of redundancy (and room for human error). There must be a better way to set this up! I would love the help!!
Once I get it set up, I'll automate it to email the customers their delivery dates for the month
Mar 27, 2023 03:03 PM - edited Mar 27, 2023 03:19 PM
This is a great use case for Airtable.
I've strayed away from my tendency to build full bases for people on the forums, but since you're brainstorming, I decided to hop back on and see if I've still got it.
Since I don't have many details on the structure of your overall data, I went ahead and just filled the gaps with how I might imagine your data structure. There's also a lot of stuff I've just made up that may or may not interest or be applicable to you.
(Forgot to include the shared base link. Feel free to pop in here, duplicate the base, and do what you might please with it.)
I built a base with five tables. The first table contains records for each customer. It's important to note that all the data here is generic, sample data.
The table is very straightforward and there's nothing you haven't seen before here.
The next two tables I created are called Subscriptions and Services.
This one might not be relevant at all for your use case. I have included it simply for the sake of this demonstration, as it showcases how one might be able to scale this structure to accommodate a growing set of needs.
We'll start with service records. You can think of these as operating similarly to templates. More specifically, each record here represents a unique "service" that you might offer for your customers. As you can see below, I've simply created three services for monthly, biweekly, and weekly delivery services.
Now that we have the service object, I'll go ahead and create the Subscriptions table.
A subscription is a junction between a service and a customer.
At this point, many people would ask: "why wouldn't you just link a customer to a service?"
Let's presume you have a customer that you have been working with for a couple of months. One day, that customer decides to cancel their account and no longer wants to receive flower deliveries.
Okay. Simple enough, right? All you have to do is something simple like mark the customer status as "Cancelled" or just unlink them from any service records. You're not hurting much at first because you still have a record of their past deliveries.
Now, what happens if that customer comes back to you a few months later and decides to not only begin taking deliveries again, but wants to upgrade from a monthly cadence to a biweekly cadence?
You're going to struggle to keep track of the historical context of your business interactions and your customer history. For many, this seems like a small or non-existent price to pay, but this is a valuable set of data that could provide powerful historical business analytics and reporting.
You suddenly have the ability to report on metrics like the average amount of time some customers go before they cancel. You can track how long a customer has been an active consumer of your services despite putting their agreement with your business on hold a few times over the years.
You can granularly track business and financial performance per subscription.
From a data governance perspective, if you need or want to delete your customer records after a certain amount of time, you can preserve all your delivery records and business history and not sacrifice consumer data protection and ethics.
The next big table is what we've been building up to: Deliveries.
You've already pretty much got this part down. Each record is a unique delivery for a given customer.
I won't dig into the details here since it's pretty self explanatory.
But what we can do is dig into how to automate two actions.
The first set of automations we can configure is email notifications. For the sake of demonstration, we'll assume that we want to send an email notification to our customer when they are one week away from their delivery date.
To do this, I'll create a simple formula on the delivery object that tells us how many days are left until the scheduled delivery date. If the delivery date has passed, then it'll return blank:
Next, we can configure a trigger to fire each time a delivery record's Days Until Delivery field returns a value of 7. I already have the full name of the customer on the delivery object, but I specifically want to insert their first name in the email body, so I'm going to do a quick search for the full customer record.
Now all we have to do is craft a quick little email:
Boom. Again, I'm intentionally keeping this simple for the sake of showcasing the overall structure.
You could set up your automated emails to satisfy almost any requirement here.
Our next set of automations is to handle the automatic creation of our scheduled delivery records so that we can worry about the business and not have to dump time into manual data entry.
If I were actually doing this, I would script it, but for the sake of keeping this a bit more open to people reading that might not be comfortable with working with scripts, here's a no-code way to approach the automatic record creation.
I'll start by creating a scheduled automation trigger that runs weekly on the day of my current week's deliveries. So if I make my weekly deliveries each Monday, I'll have the automation create next week's deliveries today.
I'll then search for any weekly delivery subscriptions that are marked as being active subscriptions:
Next, we can iterate through each subscription and create a new delivery record for each subscription we need to fulfill, and since we are exactly a week away, we can insert the Next trigger time output variable as our delivery date since we know that the next delivery day is also the day that our automation will run.
One issue with this approach is that if you have a rather large number of variances in your schedule, you may end up with an overwhelming number of automations depending on how flexible you want your automated communications to be with your customers, but I digress.
Now, I said that I created five tables, but I've only shown four of them.
I also have a Month table that contains records for each month.
I originally created this table out of your description of working with monthly batches, but once I played around a bit, I realized that there's not really much value added by having this table.
That's not to say that there are none. In fact, if you were doing any sort of financial tracking and reporting, this would prove infinitely valuable in many scenarios.
There's not much reason to keep it, but I don't currently have a compelling reason to axe it from this demo... so it'll stay for now.
Mar 28, 2023 04:38 AM
wow @Ben_Young1 - I am so appreciative of what you have put into this for me. It shows that you love data and Airtable and I'm grateful for your gift! I run my flower farm as a 'side hustle' among my other demands of life and family and I will comb through this as soon as I get some dedicated desk time. I'll provide some specific feedback then, but in the meantime, just wanted to say thank you. I'm grateful to the Airtable community!!!
Mar 30, 2023 11:53 AM
I'm taking some time to go through this step-by-step. Keep in mind, my background is natural resources and now farming... so learning this is challenging, albeit rewarding, endeavor for me. I'm learning a whole new language here! First, I love the way the data is structured with the services table. You make an excellent point about historical data and I plan to set up my master customer data this way.
What is the advantage of using a single select field for city and state? This would work fine for me since I deal only with local customers, I would have a limited amount of cities. Is there a particular advantage to setting it up this way over text?
I also think the month table is helpful! It would be extremely relevant in doing crop-planning for the next growing season! So glad you left it in there! 🙂
Still having trouble wrapping my head around the calendar portion right now. I suppose a formula could be used repeat the deliveries on a certain day. My deliveries have a lot of variables. People ask "I'm having company, can I get this week's delivery a day early?", etc and I try to accommodate in the name of customer service.
Is there a way I can populate records in a new table that will pull several others? Such as, populate the records with all the customers that match the criteria of monthly delivery, are active and paid in full, for example? That way, I could see the list populate, then drag and drop each one into a calendar date in calendar view for example. Want to make sure no one gets missed. I would rather have these records populate rather than me linking tables and the customer out of a list each time. I hope that makes sense.
Thank you for your time, I really appreciate it!