Have you tried putting a deadline on the task, either explicitly or implicitly? Instead of saying "Will you buy a card for someone?", try saying "Will you pick up a card for coworker by Friday?
It sets the expectation that you expect the task will be done in a certain amount of time, instead of leaving it open-ended. It's less ambiguous.
I have used this technique many times in work situations. As a developer, I frequently service requests from non-technical end-users. i.e. "can you add feature X to the application". Once the work is done, I would let them know "hey, I have added it, can you go test it out in Development and let me know if its working for you?" What would happen is I would never get any feedback and/or they would never test the feature. The feature would end up getting pushed to production anyway. To compound matters, they would come back to me weeks and months later saying "feature X didn't work."
In this case, I'm required to have them complete their task, because I can't do it for them. Only they can tell me if the feature is working as they expect.
So, what I started doing is saying things like "hey, feature X is completed. It needs to be tested by Friday or we'll assume you are signing off on it." When I started doing this, I noticed that they would start marking the "due date" in their calendars or otherwise getting back to me fairly quickly, often the same day or the next.
By setting an arbitrary deadline, you are communicating, in no uncertain terms, the time frame in which you expect this task to be completed. In my case, I was also able to communicate the consequence of NOT completing the task within that time frame, which was they would be signing of on something they hadn't tested or even looked at.