Hands-on tests, without fake stars

Why a public protocol

A pricing page can tell us the rate and the free-plan allowance. It cannot show whether a CRM field maps correctly in a real setup or how quickly a particular inbox uses its credits. Those are questions for hands-on work. We publish the proposed method now so a future test has a defined job, a recorded plan and evidence readers can inspect. A product endorsement without those records would not answer the same question.

There are no published hands-on results yet. Tool reviews remain documentation-based until a queued test is finished. A completed write-up will appear under Hands-on notes on the relevant tool page, with the test date, plan and a link back to this method. Being in the queue does not mean the product has passed.

Before the test

1. Use a dedicated work account (not personal mail) and note the plan you are on (Free / trial / paid). Store the password in the vault if Rio approves.
2. Write one real job to complete (e.g. “recap a 25-minute client call into CRM notes” or “build one Make scenario that labels HubSpot deals”).
3. Record start time, browser/OS, integrations connected and whether the vendor’s bot or recorder will join external calls.
4. Screenshot the pricing page or in-app plan badge on day one so the published note matches the plan you actually used.

During the test

1. Follow the vendor’s default onboarding; don’t install unofficial workarounds or scraped prompts.
2. Capture screenshots of pricing confirmation, key UI and the finished output (recap, draft reply, automation run log).
3. Note failures, lag, missing languages, CRM fields that did not map and anything that needed a human rewrite.
4. Keep client-confidential material out of consumer AI side-channels. Prefer the vendor’s business plan settings and our privacy notes on each role page.
5. If a meeting bot joins external calls, disclose it. Have a bot-free fallback (Granola) when a buyer objects.

After the test

1. Score only what you observed; never invent a star rating, NPS or user-count.
2. Publish under “Hands-on notes” on the tool page with the test date, plan used, duration and limitations.
3. Cancel the trial if you won’t keep paying; screenshot the cancellation for the books.
4. Link back to this protocol from the tool page so readers can see the method.
5. Log any price or plan-name change you noticed into the editorial pricewatch process — do not silently edit old baselines.

First three tests (queue)

The order sets our editorial priority; it does not rank product quality. Each row names the work Rio needs to complete before there is a result to publish. Account access and the time needed for real work are still prerequisites, not tasks already carried out.

What Rio needs to do

1. Pick the first tool from the queue (recommended: Granola Basic or Fyxer Free).
2. Create or approve a dedicated work login (password can live in the vault).
3. Follow the protocol over two weeks of real work. A single demonstration call is not enough to support the planned write-up.
4. Send screenshots + notes; editorial publishes the Hands-on section and keeps the method link here.
5. Decide keep vs cancel; if cancel, screenshot confirmation before the trial renews.

Standing rules still apply: no purchases or sends without Rio’s explicit approval; free catalog work only.

How readers should treat hands-on notes

A future hands-on note will describe one operator’s experience on a named plan and date. It will not be a laboratory benchmark or security audit, and another CRM setup may behave differently. Before annual prepayment, check the review’s sourced price and the caps on What free actually means. Run a pilot for the work you need rather than assume our eventual result would transfer unchanged.

Related buying maps: task hubs, role guides, AI stacks, methodology.

What counts as evidence

A usable hands-on note answers five questions with artifacts, not adjectives:

1. Which plan and billing interval were active (Free, trial, monthly, annual)?
2. What real job was attempted, in one sentence?
3. What output did the tool produce (screenshot or export)?
4. What broke, lagged or needed a human rewrite?
5. Would we buy or renew at the sourced list price in the review? Give the reason, including any condition that changes the recommendation.

All five questions need an answer before publication. That is why the first queue contains three tools rather than thirty. Granola, Fyxer and Make connect to the existing Fireflies vs Granola, email and Make vs Zapier pages, where documentation cannot settle output quality or setup behavior. The queued work is intended to add those observations, including failures, not to retell the pricing page as if it were experience.

Price figures inside queue “why” columns are the same vendor numbers as elsewhere: Granola Business $14/user/mo (monthly), Fyxer Pro $37/person/mo annual, Make Core $9/mo annual, with Free caps documented on What free actually means. Hands-on never invents a discount.

Where results will appear

The tool page will carry a completed note first, so a reader arriving at the review can see its date and scope. This page will keep the method and queue. Role guides and task hubs may link to a finished write-up, but a research-based pick does not become a tested recommendation until the actual Hands-on block exists. A prose revision alone never supplies that evidence.

FAQ