“Automate client onboarding” sounds like a clear project until the first client arrives with an incomplete contract and an existing billing account.
A useful proposal explains what the system will do in that situation. Otherwise, you may approve the happy path and discover the rest of the scope after work begins.
Walk one real case through the proposal
Take a recent onboarding example, remove information the provider doesn’t need, and ask them to explain the sequence. What starts the workflow? Which records does it read? What does it create? Where does it stop for someone to decide?
Use the answer to fill in a small acceptance table:
| Situation | Expected behavior | How you’ll check it |
|---|---|---|
| Signed agreement, new client | Create one delivery project linked to the client | Inspect the final project and its source reference |
| Existing billing customer | Reuse the correct customer record | Confirm no second customer was created |
| Required detail missing | Ask the named person to resolve it | Check the review item and who received it |
| Same event arrives twice | Avoid repeating duplicate-sensitive work | Replay the event and inspect the resulting records |
These are illustrative requirements. Your process may need different ones, but the proposal should let you write equally concrete checks.
Find the work that falls between the tools
A provider may include workflow configuration while excluding field cleanup, account access, changes to the source app, or staff training. Those exclusions can be reasonable. They still need an owner and a place in the budget.
Ask who resolves a naming mismatch between the CRM and accounting system. Ask who approves a new field. Ask who confirms that a client-facing message uses the right information.
If the answer is “your team,” identify the person before approving the timeline. An unassigned dependency can delay the project just as effectively as a technical problem.
Separate launch acceptance from ongoing support
The build should have a finish condition. Ongoing maintenance should explain what happens when a dependency changes after that condition has been met.
For the onboarding example, launch acceptance might require the agreed cases to pass and the operations manager to handle a review item without the builder’s help. Maintenance might cover broken connections and restoring the agreed behavior. Adding a new customer segment would be a separate change.
Ask for this boundary in ordinary language. You should be able to tell whether a later request is a defect, a maintenance task, or new scope.
Approve a smaller complete workflow when the uncertainty is large
If neither party can describe the exception paths yet, start with a discovery step or one bounded workflow. Require a concrete output from that step: the sequence, dependencies, acceptance cases, and revised build scope.
That keeps uncertainty visible while still moving toward a useful result. A longer feature list does not resolve an unclear process.
The Ops Guide helps map and automate business workflows. A recent real case and the proposal you’re considering give us something specific to examine.
