Deliver the Service Manually Before You Automate the Software

Before building software, try to deliver its outcome manually. This step reveals the data, exceptions, perceived value and human controls the future product will need. More importantly, it separates a real need from an attractive demonstration.

A manual service is not an embarrassing version of the product. It is a research instrument. Keep it bounded, transparent and designed to produce a decision.

Why AI makes this more important

AI reduces the cost of a prototype. It also reduces the cost of producing the wrong features. A team can now ship a large amount of software before discovering what deserves repetition.

Manual delivery exposes the complete sequence: request, collection, judgment, delivery, correction and use after delivery. Future software should compress the understood parts of that sequence, not hide the unclear ones.

Choose an outcome, not a feature

A feature describes the means: automatic summary, dashboard or prospecting agent. An outcome describes the change: next actions are assigned, the manager detects an anomaly or a relevant prospect accepts a conversation.

Useful formula:

For [user in a situation], we deliver [observable outcome] within [time], with [trust control].

Example: “For a sales manager after a meeting, we deliver verifiable next actions within two hours, after human review.”

A six-step protocol

1. Recruit three to five cases

Find people already experiencing the problem. Do not rely only on friends who want to encourage you. Explain that the service is still manual.

2. Set a boundary

Define the number of cases, duration, data used and exclusions. An experiment without limits becomes an accidental agency.

3. Deliver with existing tools

Use a spreadsheet, templates, video calls, a general assistant or a documented procedure. Build only what is required to protect data or measure the outcome.

4. Time and annotate the work

Record every step: time, missing information, exception, decision, correction and risk. This log becomes the first workflow map.

5. Observe what happens next

Immediate satisfaction is not enough. Watch what the person does with the result. Do they use it, return, refer someone or pay again?

6. Decide

After the batch, choose to automate one step, preserve a human step, change the outcome, change the segment or stop.

What to measure

• total time per delivery;
• share of work that repeats;
• number and severity of exceptions;
• time to outcome;
• corrections requested;
• observed use after delivery;
• repeat purchase, commitment or referral;
• risk introduced by automation.

Include people, money and tokens in cost. An apparently cheaper automation may cost more in oversight and correction.

Example: sales qualification

A team wants to automate prospect research.

For one week, it manually selects 30 companies, documents the signal, personalizes ten messages and reviews each one. It measures useful replies and objections rather than send volume.

The team discovers that the best signal is not industry, but a recent organizational change. That signal becomes the center of the product. Without manual work, the team would have automated a segment that was too broad.

How manual work can mislead

Manual delivery may create a quality level that cannot be reproduced economically. A founder can compensate through unusual expertise and attention. Separate:

• what can be standardized;
• what requires judgment;
• what should remain premium and human;
• what will disappear at greater volume.

Introduce a realistic time or price constraint early.

Signals to automate

Automate a step when it appears in most cases, inputs and outputs are known, exceptions are mapped, errors are detectable, the control is defined and automation improves a customer metric rather than merely internal convenience.

Signals to stop

• the problem does not appear in behavior;
• users do not apply the result;
• delivery requires unavailable expertise;
• data cannot be used legitimately;
• control costs erase the value;
• the segment will not pay or change its workflow.

FAQ

Should the pilot be paid?

When possible, yes, even modestly. Payment is not the only proof, but it reveals priority better than a compliment. In sensitive contexts, a free pilot can still work if it requires a concrete commitment.

Is a manual service compatible with a SaaS ambition?

Yes, when it exists to understand a repeatable loop and has a boundary. It becomes a problem when the team sells indefinite custom work without deciding what will be standardized.

When should AI be used during the pilot?

When it can be supervised and compared. AI may accelerate delivery, but it should not hide decisions and exceptions.

Next step

Choose one roadmap promise and deliver it manually to three people before developing it. The Manual-Before-Software Canvas helps define scope, measurement and stop condition. For a review, email contact@yumea.fr with “MANUAL” in the subject.