I make Boring CRM for solo property agents. Here's a small test I'd use for any mobile CRM, including mine.

Create a fictional buyer using your own number. Give them one awkward requirement: “Ground floor only. Call next month, after the move.”

Then test four things:

1. Close the app. Reopen it and find that requirement without digging through unrelated notes.
2. Set a test reminder for a few minutes ahead. Enable notifications, lock the phone and check what actually appears.
3. If you need access between viewings, turn on airplane mode and try reading the saved details.
4. Export or back up the test record. Check whether the notes and dates survive, and whether the file is useful outside that app. A contact list and a restorable backup solve different problems.

One fake buyer won't prove a CRM scales. It can expose a daily annoyance before your real contacts depend on it.

Which has caused you the most trouble: finding context, reminders, offline access or getting data out?

An overdue counter can make five records look like five calls. The notes can tell a different story.

Context: one independent agent, existing enquiries, manual follow-ups. These are fictional examples. Disclosure: I build Boring CRM.

My first step is to fix the queue. Mark E as do-not-contact and remove their pending outreach, keeping the preference recorded. Move C out of today's contact list and set an internal review in the agreed month. Neither needs a sales call today.

For the remaining three, I'd handle B → A → D:

• B: confirm the changed meeting point through the agreed channel. A time-sensitive appointment could otherwise go wrong.
• A: deliver the promised comparison. If it isn't ready, acknowledge the delay and give a realistic delivery time. Another generic check-in doesn't fulfil the promise.
• D: answer the actual request with the brochure. Don't turn a simple inbound request into a qualification interview before sending it.

That order assumes these are short actions. If A needs 30 minutes of preparation, send D the ready brochure while arranging a realistic completion time for A. The queue is a decision aid, not a rule that forbids judgment.

Copyable task format:

Person | What I owe them | Due date/time | Next concrete action | Contact preference/pause

Example: A | Two-property comparison | Yesterday | Send the comparison with the commute trade-off highlighted | Email preferred

A completed task should say what happened and what comes next, even if that next step is to stop. Otherwise the same vague "follow up" reminder just returns next week.

Where would you put the new enquiry relative to the overdue promise? What specific deadline or context would change your order?