Price the whole workflow, including the work after launch.

Break the scope into work you can inspect.

Ask what is included in understanding the existing process, building the change, testing it and handing it over. A quote should make the boundary clear enough that you can identify an addition when one is proposed later, rather than discovering only at delivery that half of what you assumed was included was actually out of scope.

The five questions below are the ones I use to scope a project before pricing it. They are not exhaustive, but a proposal that cannot answer them plainly is a proposal that has not actually been scoped yet, whatever the document in front of you looks like.

Connections

Which systems, accounts and permissions are involved?

Information

Does the data already exist in a consistent, usable form?

Exceptions

Which missing, changed or duplicated records must be handled?

Decisions

What stays under human review before a message or commitment?

Handover

Who receives instructions, access and responsibility?

Separate project fees from running costs.

A project fee covers agreed work. Software subscriptions, usage charges and ongoing help may be separate. Ask who owns each account and what remains necessary after the project is finished, not just while it is being built.

At byImprint, focused projects start at CA$2,500. Broader systems receive their own quote. Ongoing partnerships start at CA$3,000 a month and include 12 hours of direct work. These are byImprint's terms, not a survey of market prices.

The partnership figure is priced for 12 reserved hours covering planning, building, testing and support, paid monthly in advance, with 30 days' notice to end and no rollover on unused hours (byImprint pricing, current terms, 11 September 2026). A one-off project and a standing partnership answer different questions: a project fixes one defined thing; a partnership keeps fixing things as they come up.

Use a transparent cost example.

Illustrative arithmetic only: assume a CA$2,500 project, CA$30 a month in additional software, and one hour of internal checking each month valued at CA$50. The first-year total is CA$3,460: 2,500 plus 360 plus 600, before applicable tax or other costs.

Those assumptions are not a quote or a prediction of what your workflow will require. Replace them with the actual proposal, the real tool costs, and measured review effort once you have them. Keep existing costs separate from the additional costs the project introduces.

I have not published a real client's full first-year invoice in this example. The starting fees above are current and real; the software cost and the internal-checking time in the arithmetic are assumptions, not one specific project's numbers, and I have labelled them illustrative rather than dress up a guess as a case study.

Keep the benefit equally explicit.

If the old task took four hours a month and the new one takes one hour, the apparent reduction is three hours. Check comparable examples, include corrections, and ask whether the released time is actually useful to the business or just quieter, since quieter is a real benefit but a different one from freed capacity.

Time freed is not automatically extra revenue or cash saved. Reliability, clearer ownership and fewer interruptions can matter too; describe them separately so the decision does not depend on an inflated return that the numbers alone cannot support.

Ask what the released time was actually spent on, three months later, not what it was supposed to be spent on when the project was proposed. A saved three hours that quietly fills with something equally unplanned has not produced the benefit the original case assumed, even though the automation itself is working exactly as built.

Price what the town is already doing by hand.

Most Squamish businesses handle their booking, quoting and order paths by hand right now: 449 of 642 booking paths, 577 of 642 quote paths, and 535 of 642 order paths I read this September had no online system behind them at all, only a form, a phone or email link, or nothing (byImprint intake census, 8 September 2026).

That is useful context for pricing a project: the realistic comparison for most businesses here is not “automated versus a competitor's automated system”, it is “automated versus a person doing it by hand, reliably, most of the time”. Cost the project against what the manual version actually costs in hours and error, not against an idealised alternative almost nobody here is running.

That also means the honest baseline is usually better than a pitch assumes. A person doing the work by hand today is often catching the exceptions this guide keeps returning to, without a formal process for it. Price the project against replacing that judgement reliably, not against a strawman of a business with no process at all.

Compare a subscription tool to a custom build.

Some of what looks like an automation project is actually a decision between an existing subscription tool and something built specifically for your process. A subscription is usually cheaper to start and faster to launch; a custom build costs more up front but fits a process that does not match any off-the-shelf tool's assumptions.

Ask what a subscription tool's monthly fee is actually buying beyond the software itself: does it include support, updates, and someone to call when it breaks, or is that a separate cost again? A custom build should answer the same question about who maintains it once the project ends, since “finished” and “unattended forever” are not the same thing for either option.

Either way, watch for scope that grows after signing. A workflow project often reveals a second, related problem once work begins, a system with messier data than expected, a process with more exceptions than anyone remembered. Ask, before signing, how a genuine scope change is handled, priced and approved, in writing, rather than discovering the answer partway through the project when a fair process should have already named who can approve added scope and at what rate.

Ask what happens when the exception isn't rare.

Every workflow has exceptions: a duplicate record, a cancelled booking, a payment that does not match. Ask whoever is quoting the project how often the exception case actually happens in your business, and what it costs to handle manually versus what it costs to build for up front.

A project that ignores a common exception to hit a lower headline price usually costs more later, either in ongoing upkeep or in the same manual work it was meant to remove in the first place. This is where a fixed low quote and a properly scoped one diverge most. Ask specifically what is excluded, not only what is included.

Reduce uncertainty before enlarging the build.

Optional CA$750 discovery at byImprint covers one workflow and a written recommendation. It is credited if a related project is agreed within 30 days; the paid discovery amount counts toward the total fee, rather than being added on top of it again.

A useful decision after investigation can be a smaller project, a manual improvement, or no build at all. See Pricing for current engagement terms; this guide explains what makes the scope, and the cost, change from one business to the next.

A discovery session is worth the CA$750 precisely when you cannot yet answer the five scoping questions above with confidence. If you already can, a full proposal may be the faster route, since the discovery fee is credited either way and buys certainty, not a different price.

• Pricing and scope

Keep the whole first year in view, not just the launch.

A first-year total realistically includes the project fee, any new software subscriptions for a full year, and the time someone on your team spends reviewing that the automation is still doing the right thing, especially in the first few months after launch. Automation maintenance covers what that review actually involves once something is live.

Decide up front who owns that review and how often, the same way Shared inbox asks you to name an owner for a conversation. An automation with no named owner drifts the same way an unassigned inbox does, quietly, until something visibly breaks.

Ask the person quoting the project what a normal month of upkeep actually involves, in hours, and whether that is included in the fee or billed separately. A project that looks cheaper on paper because it excludes upkeep is not actually cheaper over a full first year; it has just moved the cost to a line item nobody priced at the start.

• Automation maintenance
• Shared inbox

Measure whether it worked.

Price is only half the decision. Measure workflow improvement sets out how to check, afterward, whether the time actually freed up was real and whether the exception rate held at the level assumed when the project was quoted.

Revisit the first-year arithmetic once you have real numbers instead of assumptions. If the software cost or the review time turned out higher than expected, that is useful information for the next project, not a reason to stop measuring.

Set a date to revisit this, thirty and ninety days after launch, and put it in a calendar rather than trusting that someone will remember to check. A project that nobody measures tends to be quietly judged a success by default, whether or not it actually was one.