Every AI assistant demo is built to wow potential customers. Maybe someone opens a crowded inbox, clicks the one gnarly email, and a tidy reply appears in the sender’s voice. Maybe a simple workflow fires on cue and files a contract in the right folder. The room nods, the trial starts. Whatever the set piece, a demo is a staged moment, and it shows the software doing something it’s known to do well. It tells you almost nothing about whether the tool still earns its keep in month three, when the novelty is gone and the work is just work.
Enjoy the demo, but evaluate the product on real data and your own use cases. Each section below is something that looks great in a fifteen-minute walkthrough and tends to break down a few weeks in, paired with a test that surfaces the problem early. Apply them to any assistant on your shortlist, including ours. The point isn’t to trip up a salesperson. It’s to know what you’re actually buying before you route a team’s messages through it.
The everyday inbox is table stakes, so test it like table stakes #
Three things will look polished in any demo: sorting the inbox, writing a reply, and reminding you about a thread. They are worth having, but they’re also what inbox tools lead with, so the demo tells you little. Broader products, the suite copilots and automation platforms, often demo something else entirely and are worth judging on their own ground. Test them the way you would test a hire, not on the easy day but on the correction and the mess.
Triage. A useful assistant decides what deserves your attention so you’re not the sorting machine. The better ones let you describe categories in plain language (“anything from a current client”, “receipts”, “cold pitches”) instead of a fixed set of labels, and mix that judgment with rules you can read for the obvious cases. The real question is whether it learns. To test it, connect a real account, let it run a few days, then correct it. Move something it filed wrong, mute a category, mark a sender important. Does the next day reflect the correction, or are you making the same fix again?
Drafting. Most tools produce a competent reply. Fewer produce one you would send without rewriting. The tell is whether a draft matches how you already write to that specific person. The length, the formality, the sign-off. To test it, pick a thread that already contains a date, a number, or a decision made earlier, and ask for a reply. A good draft uses what’s known and doesn’t invent a meeting time or reopen something you closed three messages ago. If you delete invented specifics on every draft, it’s writing generic email, not your email.
Follow-ups. Dropped balls cost more than slow replies, and there are two kinds: the message you sent that went quiet, and the one where someone is waiting on you. To test it, ask for everything waiting on a reply right now, yours and theirs. Send a message, wait, and confirm it flags the silence. Then have someone reply, and confirm the reminder cancels itself. A reminder that nags after the thread resolved teaches you to ignore it.
The real test is what runs while you’re away #
Drafting one reply is a single moment of help that still depends on you sitting there prompting, which is what separates an assistant from a writing aid. The thing that actually returns time is a standing instruction the tool carries out on its own, every time it applies, whether or not you’re watching.
Ask whether it can hold an instruction and act on it later, on a schedule or when something triggers it. Underneath, look for a few specific things: a trigger that starts the flow without you, branching so it does one thing in some cases and another in others, the ability to work through a batch, a point where it can for your approval, and connectors to the other tools the work touches.
To test it, take one recurring pattern from your own week and try to build it as an automation that runs unattended. If nothing springs to mind, the project list is already in your inbox: the repetitive slice of what lands on your team every day. A few examples, none of which should require you to be present:
- When a signed contract lands, file it, record the renewal date, and notify the account owner.
- At the end of each day, list every customer thread that has gone quiet with the ball in our court.
- When a refund request arrives, pull the customer’s order history and prepare the response for someone to approve.
If the product can only act while you’re actively prompting it, that’s useful, and a good writing aid is worth paying for. Just be clear-eyed that you are buying help with typing, not help with the work.
Grounding beats a fluent guess #
Email decisions rarely depend on the email alone. Whether you take a meeting depends on your calendar. How you answer a prospect depends on where they sit in your pipeline. What you owe someone depends on a promise made in a different thread last month. An assistant that sees only the message in front of it’s guessing at the rest, and a confident guess is more dangerous than an honest “I cannot see that.”
To test it, ask something that crosses a boundary the current message does not contain: what you last agreed with a particular customer, who owns a given account, whether a commitment from two weeks ago was ever closed out. A weak tool answers smoothly and wrongly. A strong one either draws on a maintained layer of knowledge about your people, projects, and history, or tells you plainly it does not have that context yet. Both of those beat invention.
This is the hardest capability to build and the most valuable to have, which is exactly why it is the one to probe hardest in a trial.
Trust comes from control and reversibility #
Before you let anything act on your behalf, find the governor. You should be able to run it in read-only mode while you build confidence, require approval before anything sends, move individual actions to autopilot once you trust them, and cancel a scheduled action before it fires. What you want is a dial you set per task, from watching to suggesting to acting with approval to acting alone, rather than one all-or-nothing switch.
Reversibility is the other half. You should be able to read a plain log of what it did and why, undo a wrong action, and disable a single misbehaving rule without touching the rest. Leaving the product should be clean too. Disconnect it and your original mail, contacts, and calendar remain exactly as they were.
To test it, schedule an action and cancel it, and confirm nothing went out. Put it in review mode and confirm nothing sends without your sign-off. Find the activity log and read it. Turn off one automation and confirm the others keep running. Then check the exit door before you ever need it, so a trial cannot become a tool you are stuck inside.
One inbox is not a team #
The work does not all arrive by email. It comes through chat, through direct messages, through whichever channel a given client or colleague prefers. An assistant scoped to a single inbox helps one person on one channel. The question for a team is whether it reads across the places you actually communicate, and whether it works when the whole team adopts it rather than as a personal add-on, so that triage rules, tracked work, and knowledge are shared instead of trapped in one login.
To test it, connect more than one channel and see whether messages arrive in one place with consistent handling. Then add a teammate and check whether a rule one of you writes, or a fact one of you records, is visible to the other. A tool that only ever knows what one person’s inbox knows will keep making your team re-learn what one of you already figured out.
Who has a shot at these tests #
These tests are not a maze only one product can solve. A frontier model in a chat window, Claude, ChatGPT, or Gemini, can do a version of everything above once you connect your accounts: triage on request, drafting that uses real context, even answers that cross threads. The catch is that you are the trigger and the glue. Every run is a conversation with messages going both ways, standing instructions live in your head rather than in the tool, and the unattended-automation and team layers are yours to build from parts before you can test them. That can be the right choice for a technical team that wants full control.
Other categories pass other parts. Suite assistants like Microsoft Copilot and Gemini for Workspace are strong on drafting and grounding inside their own walls, and they answer the question for teams that live entirely in one suite. Automation platforms like Zapier and Lindy pass the runs-while-you-are-away test well and tend to be thinner on the everyday inbox and the team knowledge layer. The tests exist to surface those trade-offs rather than to declare one winner. Which ones matter depends on which failures would actually hurt your team.
Where this+that lands on these tests #
We built this+that around the tests that decide month three, because that is where most tools thin out. It turns the requests and commitments buried in your messages into tracked work, and it lets you describe a recurring pattern in plain language and turn it into a workflow with triggers, branching, loops, and approval gates that runs when you are not there. It works best when everyone on the team has an account. Some assistants are strictly personal tools, but the ones a team adopts together are usually the most powerful, because rules, tracked work, and knowledge get shared instead of rebuilt per person. And it reads across the channels teams actually use: Gmail, Outlook, Slack, Microsoft Teams, Google Chat, and WhatsApp Business. Autopilot is the destination, but you choose the route, because you decide what each workflow is allowed to do: a new automation can start out only watching and reporting, then add an approval gate so a person signs off before anything sends, then run on its own once it has earned that. Nothing leaves your outbox until you decide it should.
Grounding is the hardest of these tests. this+that keeps a brain, a layer of knowledge about your people and relationships that updates from your messages and from the workflows that run, so a reply or a decision can draw on more than the message in front of it. A brain that stays fully current across your entire message stream, with no gaps, is still something we are building toward rather than a finished capability we would put on a slide. If cross-context grounding is why an assistant is worth having, and we think it is, that is the case we have made at length.
Run these tests against us and against everyone else on your shortlist. None of them favor a particular product until you actually try to answer them, which is the whole point.
Key takeaways #
- A demo shows the software doing what it already does well. The trial should test what breaks over weeks: correction, messy threads, unattended automation, cross-context grounding, and safe controls.
- Triage, drafting, and follow-ups are table stakes every tool demos well. Judge them on whether they survive a correction and a thread that already has facts in it, not on the clean demo.
- The capability that matters most is whether the tool acts while you are away. An instruction it carries out on its own, every time it applies, is what returns time; help that only works while you prompt it is help with typing.
- Grounding is the hardest test and the most valuable. A tool that invents a past agreement in a confident tone is more dangerous than one that admits it cannot see that yet.
- Control and reversibility are not extras. Read-only mode, per-action approval, a readable log, undo, and a clean exit are what make it safe to hand work to software. And an assistant the whole team is on, reading across all your channels, keeps everyone from re-learning what one of you already knows.