How we choose, test and compare

Jobs, not categories

Software categories are written by vendors. An "AI receptionist", an "answering service with AI" and a "virtual front desk" can be the same thing, or very different things. So we start from the job an owner needs done and break it into tasks you can check.

The four jobs we cover first:

• Phone coverage: answering when you can't, working out what the caller needs, and leaving you a record.
• Booking changes: handling a request or a change so that the record, the calendar and what the customer was told agree.
• Your website: getting a page built and making the next edit yourself.
• Customer follow-up: making sure the next step happens, and that you can see and stop it.

We judge a tool on the job it promises to do, the way you set it up. Tools do the same job differently. One books straight into your calendar under rules you set; another takes a request for you to confirm. One sends follow-ups automatically within limits you choose; another waits for your approval. Either approach can pass. What fails is a tool that says it did something it didn’t, acts outside the authority you gave it, or leaves you unable to see and correct what happened.

We publish two kinds of guide. A buyer checklist lists the tasks to test and what a pass and a fail look like; it names no products. A comparison reports how specific products did on those same tasks. If we can't write down what "right" looks like for a task, we don't score it.

Three kinds of evidence

Every factual claim about a product carries one of three labels and a date.

A claim never moves up a tier because it sounds likely. A vendor's demo video is vendor-documented, not tested. Reporting by others can shape our questions and context. When we use it, we attribute it, and we never present it as our own test.

How a test works

1. Same script for every product. Each task has a fixed script, written before testing starts, with the same wording, the same order and the same changes of plan.
2. Fictional details we control. Test callers use made-up names and phone numbers and inboxes we own. No real customers take part in a test.
3. Standard setup only. We set each product up the way its own instructions describe for a small business. If a result depends on a special setting, we say which.
4. Record the outcome, not the impression. For each task we check what the product said, what it left in the record, and whether it overstepped or under-delivered.
5. Retests are reported, not hidden. If a result depends on a setup change, we keep the first result, record what we changed and how long it took, make the equivalent change for every product, and report both attempts.
6. Clean up. Tests use our own numbers and accounts. Afterwards we cancel test bookings and pending messages and delete the fictional records. Failure tests are arranged in a test setup, never as an unannounced outage.
7. Keep the evidence. Recordings and screenshots are kept with the test date and the product version or plan we used, where the vendor shows one.

Free trials and public plans come first. Where a task needs a paid plan, the guide says so, and we note the plan.

How we report results

• By task, not one score. A product can be excellent at taking a message and poor at handling a change. A single number would hide that, so results are shown task by task: pass, partial or fail, with the evidence.
• No rankings without tests. We don't rank or score products until every product in that comparison has run the same tasks.
• No overall winner. When a comparison suggests a choice, it is "for this job, under these conditions", never "best overall".
• Prices with a date. Prices change. Every price is labeled with the date we read it and links to the vendor's page.
• Dated guides. Each guide shows when it was last checked and keeps a short change log.

When our own product is in a comparison

AgentsFast is made by DavidAgents. When it is in a comparison:

• The guide says so at the top, next to the products it is compared with.
• It runs the same scripts, with the same setup rules and the same pass and fail definitions, written before testing.
• Its failures are reported the same way as anyone else's.
• Where we can't test a competitor on a task, we don't present AgentsFast's result on that task as a win.

We know a disclosure doesn't remove a bias. That is why the evidence is shown and the tasks are fixed in advance: so you can check our work instead of trusting it.

What we don't do

• We don't publish reviews, ratings or testimonials that aren't based on a real experience, and we don't write as "customers".
• We don't invent authors, testers or credentials. Guides are credited to the editors of this publication. See how guides are written.
• We don't claim to be independent of DavidAgents.
• We don't publish scores for products we haven't tested.
• We don't run ads, sell rankings, placement or coverage, or use affiliate links. See Money.

Limits of this method

• Our tests are snapshots. Products change, sometimes weekly. A result is true for the date and plan shown.
• A handful of scripted calls is not a large sample. It shows how a product handles specific situations, not how often it gets them right.
• We test the way a small business would set a product up. A vendor's specialist setup could perform differently.
• We write for owner-run businesses in the United States, in English. Rules on call recording, texting and data differ elsewhere.
• Nothing here is legal advice. Where a guide mentions a law or rule, it links the source so you can read it yourself.

Corrections and vendor responses

If we get something wrong, we fix it and note the change and its date at the bottom of the guide. A vendor can send a correction with evidence: a public document, a changelog or a reproducible result. Before publication we may ask a vendor to check facts about its own product. Vendors don't control, approve or veto our conclusions, and they can't pay for changes.

Send corrections to contact@davidagents.ai, the contact address of DavidAgents, which publishes this site.