Practical operating guide
How to compare automation proposals on the same scope
By ByTomorrow · Published
Two proposals promise to automate lead follow-up. One covers a website form and an email. The other includes phone inquiries, task assignment and exception handling.
The headline prices cannot explain that difference. The phrase lead follow-up leaves too much scope unstated to compare the offers fairly.

Diagnosis
A feature label hides the work being purchased
The starting event is unclear
HighLevel defines workflows around triggers and subsequent actions. Use that distinction in the comparison: identify the exact incoming event, then list each required action. A general feature name is not a testable delivery.
An integration name hides a dependency
A proposal may name the CRM but omit account setup, field mapping, access approval or repair work. Mark whether each dependency is included, supplied by the buyer or separately scoped.
Support terms are attached to different obligations
A monthly amount may cover hosting, usage, maintenance or only a narrow support allowance. Ask each provider to identify the same categories and document exclusions.
Working worksheet
A proposal comparison template
The shared scenario
Write a neutral example that both offers must handle: an eligible inquiry arrives through the named form, the existing contact is matched or flagged for review, a task reaches the responsible person and the next step is recorded. Use your actual channel and business rule.
Comparison columns
Create columns for requirement, proposal A, proposal B, buyer-supplied dependency, exclusion and acceptance evidence. For each provider use included, separately priced, excluded or unanswered. Leave unanswered visible rather than treating it as included.
Implementation rows
Add rows for the starting event, record matching, required fields, ownership, communication channel, duplicate handling, failure route and configuration handover. Each included row needs a specific behavior the buyer can observe.
Cost rows without invented amounts
Request setup cost, recurring service cost, metered usage, third-party charges, support allowance and charges for changes. Record the unit and assumption beside every quoted amount. Compare each offer under the same buyer-supplied usage scenario.
Acceptance row
Example requirement: when a synthetic form inquiry reaches the system, the assigned task contains the original question and a stable inquiry identifier. Evidence: visible task plus matching source submission. Failure test: repeat delivery does not create a second identical task.
Exclusion example
Illustrative comparison: one offer includes a receipt email but excludes human ownership. The other includes an accepted task. Neither should be credited for the missing behavior. Ask whether the excluded action is necessary before selecting the lower total.
Use the worksheet
Put it into practice
Write the scenario before requesting revisions
Use the same inputs, account assumptions and expected outcomes for both proposals. This prevents a revised headline from hiding a narrower scope.
Resolve unanswered rows
Ask the commercial owner to confirm each unanswered inclusion, dependency and cost basis in writing. Keep operational assumptions separate from verified product capabilities.
Choose on the agreed scope
Record which requirements the selected proposal meets, which the business will handle and how acceptance will be demonstrated. Revisit price only after those choices are comparable.
Questions
Straight answers.
No. Remove requirements the business does not need. A smaller, well-defined scope can be the right purchase if its omissions are deliberate.
It can demonstrate a capability, but the agreed implementation must pass the buyer's own scenario and failure checks in the authorized environment.
Sources and further reading
- HighLevel getting started with workflows
Supports the distinction between workflow triggers, filters and actions. Proposal comparison fields and acceptance examples are original buyer worksheets.
Checked .
Bring the proposals and one shared scenario
A comparison becomes useful when both offers are judged against the same input, result and responsibility.
Discuss your workflow