The MessageID precision issue is a great catch; it's the kind of bug that never shows up in testing with three rows. One more pitfall worth checking with LockService: a run that dies mid-batch (the six-minute execution limit is the usual culprit) leaves rows stuck in SENDING forever. Storing a timestamp alongside the claim lets a later run or a small daily report surface rows that have been SENDING for more than, say, an hour, so a person can check the provider log instead of guessing. Processing in small batches and calling flush after each claim also keeps you well clear of the time limit.