Like podcasts? Find our full archive here or anywhere you listen to podcasts: search Community IT Innovators Nonprofit Technology Topics on Apple, Spotify, Google, Stitcher, Pandora, and more. Or ask your smart speaker.
Carolyn Woodard talks with Joe Robbins, Chief Product Officer at Food Rescue US, about a real-world AI project built from the ground up: a predictive model that flags volunteer pickups at high risk of a last-minute cancellation.
Food Rescue US connects volunteers with food donors and receiving agencies through an app similar to a delivery service, coordinating about 150,000 pickups a year across 27 states. When a volunteer cancels within 24 hours of a pickup, site coordinators scramble to cover it or risk the relationship with the donor.
Joe and his team partnered with a supply chain researcher at Michigan State University to build an algorithm that predicts cancellation risk and flags pickups at high-risk for cancellation. Rather than automating any decisions outright, the AI triggers an alert to the site coordinator, who checks with the volunteer about confirming the pickup or cancelling early. During the pilot and rollout the AI tool flagged thousands of rescues that would have been last minute cancellations.
Joe shares the practical lessons from a project that took a full year to scope, pilot, and improve: why good data capture has to come before any AI project, how a tightly scoped pilot funded through a grant reduced risk, and why keeping a human in the loop kept the tool trustworthy for staff and volunteers alike.
He also offers a framework for nonprofits without an in-house AI researcher or technical staff to get started using AI for more than productivity tools.
What’s next for Food Rescue US? Using AI to take logistical pressure off site coordinators so they can focus on building community relationships. That is, letting the AI do what it is good at, freeing the human volunteers to do human oriented tasks instead of keeping on top of paperwork.
Joe Robbins is the current Chief Product Officer at Food Rescue US. Joe attended Gustavus Adolphus College on a National Merit Scholarship, and graduated with a degree in philosophy. He promptly put that degree to use as a technical designer for a startup solar company in Washington state. Since then, he has worked as a product manager for startup companies in the financial services and e-commerce industries. He has experience managing technical teams, leading product development from early stages to release, and delivering value to product users and stakeholders. Joe is passionate about food insecurity and immediately jumped at the opportunity to join the Food Rescue team in 2023.
Carolyn Woodard is currently head of Marketing and Outreach at Community IT Innovators. She has served many roles at Community IT, from client to project manager to marketing. With over twenty years of experience in the nonprofit world, including as a nonprofit technology project manager and Director of IT at both large and small organizations, Carolyn knows the frustrations and delights of working with technology professionals, accidental techies, executives, and staff to deliver your organization’s mission and keep your IT infrastructure operating. She has a master’s degree in Nonprofit Management from Johns Hopkins University and received her undergraduate degree in English Literature from Williams College.
She was glad to have this conversation with Joe Robbins and learn about Food Rescue US, what a Product Officer does, and about this Nonprofit AI Case Study in Food Rescue.
Community IT has been serving nonprofits exclusively for twenty-five years. We offer Managed IT support services for nonprofits that want to outsource all or part of their IT support and hosted services. For a fixed monthly fee, we provide unlimited remote and on-site help desk support, proactive network management, and ongoing IT planning from a dedicated team of experts in nonprofit-focused IT. Our clients benefit from our IT Business Managers team who will work with you to plan your IT investments and technology roadmap if you don’t have an in-house IT Director.
Being 100% employee-owned is important to us and our clients. It is an important aspect of our culture as a business serving nonprofits exclusively for 25 years.
We constantly research and evaluate new technology to ensure that you get cutting-edge solutions that are tailored to your organization, using standard industry tech tools that don’t lock you into a single vendor or consultant. That’s even more important now in the age of AI. And we don’t treat any aspect of nonprofit IT as if it is too complicated for you to understand.
We think your IT vendor should be able to explain everything without jargon or lingo.
If you can’t understand your IT management strategy to your own satisfaction, keep asking your questions until you find an outsourced IT provider who will partner with you for well-managed IT.
More on our Managed Services here. More resources on Cybersecurity here.
If you’re ready to gain peace of mind about your IT support, let’s talk.
Carolyn Woodard: In the webinar that I went to, that story about being able to predict what donations were likely to get canceled, I thought was such an amazing little case study…
Joe Robbins: But we had an opportunity, and we figured we were going to learn so much more this way, and it was going to equip the team to really approach bigger, more integral projects in the future. So it did that. It was tough sledding, but we have a much better grasp on what it is, what it can do, and what the limitations are. It was a learning experience that was incredibly valuable.
Carolyn Woodard: Welcome everyone to the Community IT Innovators Technology Topics podcast. I’m Carolyn Woodard, your host, and today I’m really excited to be talking to Joe Robbins from Food Rescue about this really interesting example of using AI that I heard about.
So, Joe, would you like to introduce yourself and Food Rescue? What do you do?
Joe Robbins: Thank you, Carolyn, for having me here. I love the podcast. I’m really excited this is a resource that folks have; I could have used this a couple of times, I think.
I’m Joe Robbins. I’m the chief product officer for Food Rescue US. We’re a nonprofit that’s been around since about 2011. What we do is we have a volunteer network that recovers surplus food from food businesses and then delivers it to what we call receiving agencies. That could be a food bank, a pantry, or somebody who’s doing distributions.
The way we do that is we link these volunteers together with our native app. It works kind of like Uber, or Uber Eats, but for food donations. We have networks across the country; we’re in 27 different states right now, and we do about 150,000 pickups a year. Last year we recovered close to 37 million pounds of food. It’s a huge network. The concept is pretty simple, but the actual day-to-day gets pretty complex.
Carolyn Woodard: Can you just talk a little bit more about the app? Full confession, we have Food Rescue where I am.
Joe Robbins: Oh, cool.
Carolyn Woodard: I have friends who have talked about it and do the volunteering for it. So tell us a little bit more about how the app works. If it’s a restaurant or a grocery store that made 10 pizzas and it’s almost time to close, can they get on the app and just say, hey, can someone come get these pizzas?
Joe Robbins: Yeah, that’s exactly how it works.
There’s a portal for the food donors, the receiving agencies, and the volunteers.
For the volunteers, they can log on and say, all right, I want to do a pickup this Saturday. They can find pickups near them, in their area. We show vehicle sizes and what’s going to be in the pickup so they can make a determination on what they want to do, and then they can claim it and add it to their schedule. They also have reports and achievement badges and things like that. That’s how it works for the volunteer.
For the food donor, they can sign up. There’s a vetting process to make sure they know what to expect, what condition the food needs to be in for it to be donatable. Once they’re on, they can log a donation in the app.
And then we have site coordinators who go in and assign those donations to volunteers.
That’s similar to how the agency portal works as well. They’re able to look at their upcoming pickup schedule, and they can put in food preferences. Some agencies handle canned goods and dry goods; they take stuff in, store it, and hand it out. Some folks are completely repurposing food, taking raw ingredients and actually cooking meals and serving them. So they can put all that context in.
And then our site coordinators use that when they’re routing the donations. It gets pretty complicated pretty quickly, but that’s kind of how it works for each of the stakeholder groups.
Carolyn Woodard: One thing we’ve been talking about with IT at nonprofits in general, but definitely with more forward-looking or closer-to-the-cutting-edge IT, is that nonprofits that start out with a technology app, where what they do is very much related to technology, are often pretty well positioned to take advantage of new technologies that come out.
And other nonprofits, no shade, but if you’re a more traditional nonprofit doing something a lot more traditional, sometimes your IT is a bit of an older legacy setup, and your cultural values aren’t as IT-conscious.
So one thing I thought was so interesting about your organization is that clearly it was started with this app very central to how you do what you do, but it’s such an interesting bridge, because a lot of food banks are more in that old-school area of tech-friendliness among nonprofit organizations. I find that so interesting.
I’d like to hear a little bit more about you. Your background is as a technologist, and you’re working at Food Rescue. Can you tell me a little bit about your career?
Joe Robbins: Yeah, absolutely. And I’ll say, I think like many folks, I’m a sort of accidental technologist. I double majored in philosophy and theology in school, which is maybe the worst possible starting point for technology you could take.
I will say, though, my primary role as a product officer is value creation: understanding what our value propositions are and how we get there with these functionalities, and using that to prioritize the roadmap. I’ll shout out my philosophy degree there; I think it helped a little bit. So I worked in…
I was an array designer for a startup solar company in Washington State, which was really exciting; it was a kind of booming industry. Then I went from there to a small startup nonprofit technology company and worked with them.
The way that worked was: we had clients, and we’d build a product around a client, and then once we rolled it out, we’d spin that product off as its own company. So I really did almost nine years in startup technology roles, completely by accident.
I’ll say the startup world and the nonprofit world have some overlap, some similarities, in terms of, first, the severe resource constraints that are just table stakes day to day. And also, because of those resource constraints, on-the-job training and talent really matter. You’re not going to be able to afford people with decades of experience, so there’s a lot of: if you can do it, we’re going to let you do it, and if you can take on more, we’re going to give you more.
So that was really my path in, working in startups. My role at the solar company was also a more technical role, so I had that in my back pocket. But my first…
The first tech startup I worked for, they were hiring a scrum master, and before the interview I had to look up what that was and try to figure it out. But that was a great company, and, especially for a startup, they had really good professional development programs.
I did get professional certifications from MIT in some basic coding and programming, but my role has always really been managing the teams. We do software design, and I do all the prototyping myself; we don’t have a UI/UX designer, so that’s me. The database and analytics are also grouped into the role.
So you become a jack of all trades pretty quickly. And I think, even for people coming out of college with a computer science degree, especially now, what matters is whether you’re up to date on the most recent material UI package or whatever it is, and some of those things you learn, and then a year later they’re already outdated.
So I think anyone in the technology community knows you’re learning all the time; you’re going to be a lifetime student. I got a late start, but I’ve caught up pretty quick.
Carolyn Woodard: So you moved to Food Rescue and into this technology role. In that role, what do you do? You support the app, and what else do you do? And how did you get interested… well, I mean, everyone’s interested in AI right now, but what was your path into seeing this AI opportunity?
Joe Robbins: So I started at Food Rescue about three years ago. And I’ll say something my fellow product managers will understand: every company has a different idea of what a product manager does, and I think no matter what, you end up doing a little bit of everything.
When I got hired on, the previous version of the role was really a management role, maintaining the workflow: you accept user feedback, design that into features, and ship those features. We changed that up pretty quickly. We built in discovery processes, so we have feedback loops from all 50 of our sites.
You talked a little bit about the diversity we have in the field, which is super valuable for feature design because you get feedback from so many angles. When we build something, we have to design it for all of those groups, even if they have very different operations. That’s a fun challenge.
That’s the starting point of my role: making sure we’re taking user feedback in, keeping people in the problem space, and then designing the solutions. I build the prototypes myself, and then we scope those with the team, get estimates, build them into sprints, and we’ve got QA and stuff on the back end too.
Outside of that, we’re doing all the reporting tools and analytics for the organization. We’re doing marketing right now for a feature launch coming out at the end of this month. We also shipped our native mobile app last week, actually, so that meant figuring out new deployment processes and new code infrastructure. A little bit of everything.
Joe Robbins: We had a research opportunity with Dr. Stanley Lim, who’s a professor of supply chain logistics at Michigan State University, and that was really cool. They wanted some of our data; they had a proposal in mind.
We got to the end of that and started talking about additional projects. He has a background in AI, and he asked us if we’d thought about integrating AI into our app.
AI is at different points of development in different sectors, I think. Supply chain logistics is ahead of the curve right now; a huge amount of resources go into that field. So we knew there was going to be some overlap in what was possible and what we could do. His skill set is really in designing these from the ground up.
When you integrate AI, you can take existing tools and put your own business context into them, then plug them in. Not easy, but easier than building from scratch.
He was proposing that we build from scratch. So we met with the team and determined that, as long as we could scope this project correctly, the value of the experience for us, for me and for the developers, was going to be massive. So we sat down to do that; we started last summer.
The project we came up with was a tightly scoped research question, and one we had really good data coverage on. I think that’s key for folks thinking about dipping their toes into this: it’s really hard to try to solve a problem first and then build the data capture after the fact. I said really hard, it’s basically impossible, and it gets very inefficient very quickly.
So that’s something I learned on the fly: your data is part of your product.
For previous clients that was really important; we were working in the health insurance industry. For any feature we designed, one of the first questions was: what’s the data capture? What kind of analytics are we going to need once this gets out? We’ve been doing that since I started here.
The problem we landed on was volunteer cancellations. Right now, volunteers claim a pickup at a specific day and time, and if they cancel within maybe 24 hours of that pickup window, it creates a real problem for our site managers, many of whom are also volunteers. Typically, either the site manager has to go cover it themselves, which is disruptive, or we run the risk of not conducting the pickup at all. It’s a free service, and we don’t have service level agreements with our donors, but because we’re recruiting them, we have to protect that relationship. So it creates a real problem for us.
So that’s what we set out to predict: can we predict when someone’s at a higher risk of canceling within 24 hours of the pickup? We had a good scope of data around rescue or pickup history, and things that might affect a pickup window.
Obviously these are volunteers, not paid employees, so there are a lot of factors that could go into a cancellation decision, like someone has soccer practice running late. But we knew enough about it that we felt confident we could put something out to test.
So we sat down, scoped that out, built the data features, built the algorithm, and then launched a pilot with 17 of our sites in January of this year. We’ve been looking at the results and fine-tuning the model.
We have about 12,000 pickups a month typically; that’s about the average. Depending on the site, anywhere from maybe seven to twelve percent of those end up needing a last-minute substitution. Not an insignificant number.
The first version of the model we put out had about a 12% hit rate, which, if you think about it as a letter grade, sounds bad. But given what we were asking it to do and to predict, 12% was maybe ten times where we thought we’d be in the first version. We’ve continued to improve it with every update we’ve pushed out.
We’ve pushed out about three or four major updates. Right now it’s predicting at about 15%, a little higher depending on the site.
It’s based on pretty straightforward data points: rescuer history, days of the week (some days get canceled more frequently than others), and the weather. We pull weather data in from a third party. Interestingly, we learned people are less likely to cancel when it’s cold and more likely to cancel when it’s very hot outside, which you wouldn’t necessarily think. But that’s how it predicts.
The way we built it, and I think this is important for other folks looking to do something similar, is that we’re not automating any decision-making with the tool. It runs the algorithm, assigns cancellation-likelihood scores to each rescue, and if a rescue is over a certain threshold, we create a to-do item for the site coordinator that says: this is a higher-risk rescue, let us know if you want us to send a confirmation.
When that to-do item is reviewed, we send a confirmation to the volunteer: hey, just so you know, you have a rescue in a couple of days; if you’re still going to make it, let us know, and if not, please cancel now so we can find a substitute.
In the last six months, this has caught thousands of rescues that, without this tool, would have been a last-second cancellation, where we’d be finding out day-of and scrambling. Instead, we have a three-to-eight-day window of notice where we can assign a substitute. Really fantastic results.
I talked a lot there, so I’ll let you get a question in now. But yeah, it’s a big project, a lot going into it.
Carolyn Woodard: No, when I heard you talking about it previously, it’s so fascinating, because I think for a lot of nonprofits, the way in to AI is you start using those productivity tools. It helps you draft an email, or it helps you with your inbox.
I found this was so interesting as a way to think about what AI is good at doing, like predicting patterns from data you already have and putting that to use in a way that’s very practicable for what your nonprofit does. That’s another thing that was so fascinating about this story.
I’m sure people have questions about the security piece, and how you manage that. You said the AI doesn’t make any decisions itself; it’s giving the decision to the people involved.
Can you talk a little bit about your design process around that aspect of it?
Joe Robbins: Yeah, absolutely. We approach it kind of the same way we’d approach more straightforward forms of data analytics.
When we’re building, we can create an analytic and trigger actions based on that number. So if the pickup window is coming up and there’s no one assigned to it, we can trigger an action off of that data.
The way we make decisions for standard data analytics is: is this something we’re extremely confident in, in terms of what the analytic is telling us, or is it something that’s going to be valuable context for a person who then needs to be the one who makes the call?
We approached it the same way, and we also picked a research problem that could be answered in that same way. I think that’s really important; software in general, not unique to AI, hides a lot of the mechanics of what’s being done. So there’s always going to be a decision about what to surface to the user and what’s going to detract from the user experience.
That decision-making process let us think about it in a very similar way to how we think about the rest of our software. The unique concerns come in when you’re using a third party, because then you’re sending data to a system outside of yours; we didn’t have to do that, luckily. But that’s a really big challenge, especially for nonprofits that are already under-resourced. A lot of the time you’re not going to have a compliance officer or someone on staff who’s going to write those policies.
So we did put together an AI governance policy. We grabbed a template we found; it wasn’t anything new, but we had meetings with the whole team, even people who weren’t involved in the build, to make sure we all understood what this was going to do and how the data was going to be used.
Similar to standard data analytics, we don’t send any personally identifiable information into the algorithm. It’s all ID codes and things that are useful for us in answering the question.
That’s dictated a bit by the functionality we needed. There are projects where you can’t avoid using PII, and then you really have to make sure you lay the groundwork for safety and liability.
For the most part, I think the best way to approach it is to start with your standard data capture processes, making sure you have the right data usage policies and that everyone on the team understands them. I think that’s the most critical piece: a lot of times, especially if you’re SOC 2 compliant, you’ve got a policy for everything, but only one person has actually read those policies, and everyone else is kind of shooting from the hip. So visibility is key. And then make sure you understand what you’re doing, what you need to accomplish, and that you have those bases covered.
Carolyn Woodard: I feel like, correct me if I’m wrong, but it seems like this part of the tool is using AI in a way that’s maybe similar to your GPS telling you how to get to a location. So there’s maybe a lower risk of the user thinking, what is this AI doing in my app?
Joe Robbins: Yeah, and that’s kind of the same approach we take to data usage and data capture anyway. If it’s about how a user is using your tool, and it’s information specific to those use cases that’s making the tool better, then it’s fairly straightforward how you handle it.
We also don’t have any financial information; we don’t fall under PCI compliance. The sensitive information we have is names, business addresses (which are pretty public), and contact information. That stuff is pretty simple, and it’s never really going to be important for an AI tool.
So I think that’s the key thing: start with the data policies you already have in general. AI doesn’t have to complicate those drastically.
Same thing for implementation: in general, you wouldn’t want to take a metric you’re not super confident about and make decisions for users based on it. You want to implement it into the context the user is in when they’re taking action. I think that’ll get most folks pretty far in the process.
Carolyn Woodard: I have another question, maybe a couple more, for you. Your organization is clearly very tech-forward. Do you have advice for anyone listening whose organization isn’t quite at that cutting edge, to think about, once you’ve used AI for those productivity gains and you’re getting more conversant and comfortable with what AI can do and what it’s good at…
How do you think about a project you could try with your organization, tied to your mission, if you don’t have a researcher coming to you with AI expertise who can help you with the logistics of it? Do you have a framework, or some prompts, to think about where AI could fit into your mission?
Joe Robbins: Yeah, and I think you framed this the right way too.
I think the right entry point, especially for an organization that’s maybe less tech-forward, is that all of these assistant tools have free versions, and using those heavily teaches you the basics of AI instrumentation.
Context is really important; that’s the biggest limiter. Even the best AI tool isn’t going to be able to help you unless it knows what you know, in terms of how to make the decision. So I think that’s the right entry point.
And then, I think there’s a lot of hype and excitement about AI tools. I’ll say, at least in my experience, not just in nonprofits but in the for-profit sector too, data capture, database storage, and data structure are things that are really easy to lag behind on until someone asks you for something.
And then there’s a lot of going back and cleaning up. So I think making sure you have a healthy data capture system is really step one, because AI assumes all your data is correct: that it’s all clean, all being stored and updated properly. That has to be the first place to start.
I don’t want to sound harsh, but I think you’ve got to start there. Especially if you’re a more technically limited organization, you have to have the data first before AI is going to be useful for you.
That said, there are use cases that are less predictive, like maybe you have a knowledge base and you want people to be able to interact with it instead of searching for an article and reading it. There are things AI can do before you get into predicting things and heavy data analytics.
But I think that’s the place to start: use the tool, get a basic understanding of how it works.
And then I think you’ve got to start with an audit: what data do we have right now in the organization, and what needs to happen with that data before it’s usable, before we can connect it to an algorithm or an AI tool and have that tool look at the data.
Sometimes you also need to build new features. If you have a journey you want to make a prediction about, and you have holes in your visibility on that journey for your users or stakeholders, those holes are going to limit the accuracy of any predictive work you do on that journey. So I think that’s the place to start: an audit of your data capture and data storage mechanisms.
From there, you’ll come out of that process with a to-do list: maybe we need to build a data lake, we need to clean this data, we need fact tables in addition to functionality tables. And there might be new features or new data capture mechanisms you need to bring in.
I keep saying features because I’m assuming you have in-house software. If you’re using third-party tools, most of them have export options and ways to get data out: webhooks, integrations. So that’s another good place to start. If you’re using Salesforce or HubSpot, there’s already a rich data set living in there that’s going to be pretty clean in terms of how it’s stored and how you can pull it.
So starting with that: see what we have in inventory, see where the gaps are, and then you can start planning your AI project. Those have to happen first.
Carolyn Woodard: That makes sense. I love something else you said too, about piloting: you were very careful to have the algorithm and the data it was using only in certain sites to begin with, and then see what happens: is it doing what you think it’s going to do, what are the impacts, how are people reacting to it. And then with what you learn, you can make it better and expand it.
That’s something I think, unfortunately, a lot of nonprofits don’t have a lot of time to play around with, piloting for technology. They might pilot a program they’re going to start in one school before rolling it out to 50 schools, but they often don’t use that same logic toward IT systems or tools. A lot of times they don’t have the luxury of doing that, because they got the grant to do the product that does the thing. They can’t play around with, well, let’s just use the CRM on two of our sites instead of the whole thing.
I think AI tools themselves also lend themselves to doing pilots, seeing how it goes, and asking the AI, how did it go? Give me the results and the analysis, and then taking it to a larger audience. So I like that you said that too.
Joe Robbins: Yeah, a pilot can be tricky, because you’re already investing in a new tool, you’re changing operations for people, and that’s a lot of investment already. Then delaying the return on that investment to do a pilot can be tricky.
I’ll say two things. I learned, since we’re grant funded, that if you want to do a pilot, build the pilot into the grant. A lot of funders are open to that if they know upfront that it’s going to be part of the process. So that’s a good tip for folks.
The other thing I’ll say, and this isn’t best practice, but it’s something from the startup world, and I think sometimes in nonprofits it’s the best option you have: if your users understand where you’re at, sometimes you can get away with putting something out without pilot testing it, but labeling it and saying this is a new feature or a new tool, and making sure your users understand that their feedback is what’s going to make it better.
That can allow you to move faster. I’ve worked on teams that have four or five QA engineers, where everything is really well vetted, prepped, and researched before I see it.
And then I’ve worked on teams where I’m doing all the QA myself, and the results are going to be different. Sometimes that’s just the environment you have to work in. So that’s an option, as long as you have the user feedback loop set up; that’s the critical part.
If you can’t do a full pilot, as long as your users understand this is a new thing, that we’re relying on you to help us get it dialed in and get to that final version, and they can be stakeholders in that process and not just end users, that can be really helpful. You’re going to make a better product that way. Even if you have a huge team and all the resources in the world, you’re still assuming what users are going to need, and you could build something that’s perfect…
…and if users get confused on page one and can’t interact with it, you’ve still missed the mark. So I think, for smaller groups, if you can’t do a full pilot, see if you can let users know it’s new, maybe call it a beta phase, so they’re motivated to give you that feedback. They understand that’s the ask, that it’s not a final version. That can be really helpful too: kind of an on-the-fly pilot.
Carolyn Woodard: Yeah, I think that’s true. I think a lot of nonprofit users, constituents, and volunteers will give you a lot of grace if you’re transparent: we’re in this together, we’re trying to make this better, can you help us?
Joe Robbins: Yeah, and it seems like, if you ask someone for feedback, they give it to you, and you fix the problem, that’s a really positive experience. If you send something to a user, they find a problem and tell you about it, and you fix it, it feels a little different for them; it’s a funny bit of psychology you kind of learn on the job in product. But yeah, frame the release…
…frame the release with where you’re at, be transparent about that, and most of the time you’re going to get really good results.
Carolyn Woodard: Yeah. Okay, I have a last question for you, because I do appreciate your time and I know we’re running out of time. What’s next? Do you have an AI project you’re thinking about now, now that you’ve done this one, where you’re like, oh, I’ve got an idea…
Joe Robbins: Yeah, so, not giving too much away, we’ve got some things coming out this year that are going to add pretty significant data capture to what we have now, on a couple of really important parts of our workflows. So we’re going to be in a position, like I said earlier, to tackle a couple of problems that are maybe out of our reach right now.
But I think our focus is on the site coordinator role. Right now there’s a huge amount of pressure on that role. Those people are managing pretty complicated logistics, but they’re also recruiting across all three of those stakeholder groups, keeping everyone engaged. They’re really – we’re asking them to be community leaders and supply chain logistics experts.
So I think there’s a huge opportunity for us in helping to not automate their role, but automate some of the trickier decision-making components of that role.
If we ended up in a situation where our site coordinators are fully focused on maintaining those relationships and building those communities, and they’re not thinking about how many rescues they have on the schedule and who’s going where, I think that’d be a really good position. So that’s the area of focus for us, and we do have some new things coming out, so stay tuned for that.
Carolyn Woodard: I love that, because we’ve been saying for a while now that the humans need to do the human stuff. I think the potential of AI in the nonprofit sphere and in philanthropy is that we’re so understaffed and under-resourced, or the resources are just too expensive. We can’t hire a fancy consultant to tell us about our supply chain problems; it’s just out of reach.
So having AI handle the logistical stuff it’s pretty good at, like scheduling or predicting those sorts of things, the busy work you don’t want to be spending all your time on as a volunteer, filling out forms for example, and letting the volunteers focus on the human side… I really think there’s a lot of potential there.
So thank you so much for sharing with us all these ideas and your experience. I really appreciate it.
Joe Robbins: Yeah, thank you for having me. It’s been a pleasure.
As advocates for using technology to work smarter, we’re practicing what we recommend. This transcript was drafted with the assistance of AI, and is not a verbatim transcript. The content was edited for clarity, and was reviewed, edited, and finalized by a human editor to ensure accuracy and relevance.
Photo by Klara Kulikova on Unsplash
Wednesday August 19th at 3pm Eastern join Erik Solce and Carolyn Woodard from Community IT for a case study on actually using AI.
Fill out the form below to request a quote. We’ll be in touch shortly to discuss your needs and take the first step toward better nonprofit IT.