Consulting is the plan
Choose consulting when the main problem is uncertainty. You know office work is leaking time or follow-up, but you do not yet know which workflow deserves the first build, what tools are involved, or where human approval belongs.
A useful consulting engagement maps the current process, tests the assumptions, ranks the opportunities, and ends with a written sequence your team can act on. It should tell you what to build, what not to build yet, and what has to be true before launch.
The deliverable is clarity. If you already have people who can execute a clear plan, consulting may be enough.
Contracting is the build and the owner
Choose contracting when the workflow needs to run in the real business and someone needs to own the result. The job includes connecting the tools, testing the normal path, defining exception handling, monitoring failures, and changing the system when the business changes.
The operating team is responsible for monitoring, exception handling, maintenance, and the boundary between routine automation and business judgment. Ridgeway documents that responsibility through clear workflow scope, so both teams know what is covered and how changes are handled.
If your team wants the job off its plate instead of another project to manage, contracting is the cleaner fit.
Use the bottleneck as the decision rule
| Your situation | The actual bottleneck | Buy |
|---|---|---|
| You cannot name the right first workflow | Uncertainty | Consulting |
| You know the workflow, not the safe build path | Ambiguity | Consulting |
| You know what should run and need it running | Execution | Contracting |
| The system runs but nobody owns exceptions or drift | Operation | Contracting |
Do not turn the decision into a debate about models. First get specific about the job AI should own. Then buy the kind of help that removes the actual bottleneck.
A plan can hand off cleanly
Starting with consulting does not obligate you to buy contracting. A good plan should stand on its own. Your internal team can build it, another vendor can build it, or Ridgeway can take on the managed operation.
That clean handoff matters. It keeps the advisory work honest and prevents the audit from becoming a long sales pitch.
Do not ignore the work after launch
Every build decision should name the person who handles exceptions, watches failures, and updates the workflow when reality changes. If the answer is “we will figure that out later,” the build is incomplete.
Read why AI systems go stale before choosing a one-time implementation. Launch is a milestone. Ownership is what keeps the system useful.
Compare the deliverable at handoff
For consulting, the handoff should make the next decision possible without another discovery project. Expect a current-state map, ranked opportunities, dependencies, risks, ownership, acceptance criteria, and a sequence of work. A tool list without the reasoning behind it is not an implementation plan.
For contracting, the handoff is a live operating surface. Expect the workflow definition, connected accounts, permission boundary, exception path, monitoring, change process, and the record used to verify completion. The signed scope should say which team owns routine operation and which decisions remain with the business.
Use an acceptance test before choosing
Ask what you should be able to inspect at the end. If the answer is a written decision package your team can take elsewhere, the shape is consulting. If the answer is a tested workflow with a named operator and support path, the shape is contracting. If the result is a defined website, migration, integration, or internal tool with a stable finish, a one-time project may be the cleaner third shape.
The AI Opportunity Audit helps when the right acceptance test is not yet clear. It ranks the work before the company commits to a build or an ongoing operating responsibility.