What affects the price?
The systems involved, the rules the solution must handle and the work needed to put it into use. A simple calculation and a quoting process connected to several systems are different builds.
How we work
A clear piece of work.
An agreed way to deliver it.
We agree the repair or build, its fixed fee and the real examples we’ll use to check that it works. The system review is included in the engagement.
What you are buying
An agreed result.
People responsible for it.
Ryan leads the scope, architecture and delivery. We name the teammates involved and the person on your side who will run the system.
Your counterpart does not need to understand the inherited setup yet. They need time to explain the work, make decisions and review the result with us.
- The correction or build, the systems involved and what is included
- Real examples to test and the person who approves the result
- Access, decisions and review time needed from your team
- Delivery updates, response expectations and agreed support
- Documentation, source/configuration rights and maintenance responsibilities
Pricing
A clear fee.
A clear piece of work.
A defined repair or build has a fixed fee, quoted privately. Continuing work has a monthly fee attached to an agreed roadmap and support responsibilities. Before you commit, your proposal explains what we’ll deliver and what it will cost.
What is included?
Your proposal covers the build, testing, documentation, handover and agreed support. Licenses, hosting, third-party charges, maintenance and the input needed from your team are made explicit.
Is the review a separate purchase?
Our usual starting point is a defined repair or build. The review of relevant systems is included in week one. You do not have to buy a standalone assessment to enter that engagement.
What happens after delivery?
We review the result together. You can build on it with another improvement, arrange ongoing support or take over with your own team.
What if the scope changes?
We explain the effect on cost and timing before adding work. You can choose to swap priorities, extend the project or keep the original scope. Warranty fixes are covered by the agreed terms; new improvements are scoped separately.
For agencies & practitioners
The specialist build
your client needs.
A defined integration, repair or custom workflow, with a fixed fee quoted to your agency.
Your agency remains the prime contractor. We agree our delivery lead, responsibilities and the examples we will use to check the result.
- How we are introduced and who speaks with the client
- Who approves changes and takes responsibility for rework
- Who puts the result into use with the client and confirms its business value
- Estimate timing, delivery updates and handover
Access, availability and backup arrangements are agreed before kickoff. Further commitments follow when the work and commercial arrangement suit both teams.
Discuss a client projectAn early useful result
What can change
in the first 30 days?
We agree an early result your team can use and how we’ll check it. Where the scope, access and client availability support it, we commit to delivering that first improvement within 30 days.
- Week one
Establish the relevant behavior
Review the system inside the engagement. Confirm what is going wrong, what the change depends on and the examples we’ll test with your team.
- Build
Make the agreed change
Show working progress. Check everyday cases and difficult exceptions before rollout.
- Put it to use
Test with your team
Verify the records and walk through the task with the person who will operate it.
- Review
Accept and plan the next step
Confirm the agreed result, documentation and maintenance responsibilities.
Your proposal states the actual timing and dependencies. In a larger engagement, the first improvement is a usable part of the work. Longer-term revenue and adoption outcomes need their own evidence.
01
Understand in week one
Review the relevant records, behavior and dependencies inside the agreed repair or build. Agree the real examples we will use to check the result.
02
Build and verify
Show progress, test the normal and difficult cases, and inspect the result with the person on your team who will run the system.
03
Hand over or continue
Document ownership and maintenance. Where there is useful continuing work, agree the next improvements, priorities and monthly responsibilities.
The review is included in the repair or build. We define which systems and records it covers, and explain anything access or timing prevents us from checking.
We document how the system works and walk your team through maintaining it. Where continuing work is worthwhile, we agree the next improvements, support responsibilities and review points.
See capability transfer in practiceKnow what the improvement is for
What would make this worth doing?
A faster quote gives your team time for the next customer. A complete handoff lets delivery start without chasing sales. We agree which change matters to your business and measure it.
| The problem | A first improvement | What we measure |
|---|---|---|
| Quotes take too much preparation | Build a quote from the job details and approved pricing rules. | Time to prepare it, time to send it and corrections needed. |
| Completed jobs wait for invoicing | Bring the required job details into invoice preparation. | Missing information, repeated entry and days waiting to be ready. |
| Delivery chases sales for information | Create the delivery record with the details and owner it needs. | Complete handoffs and follow-up needed before work can start. |
| An integration needs constant repair | Fix the transfer and make failed records visible for recovery. | Failed transfers, duplicate records and time spent correcting them. |
We measure time released separately from money saved. The business benefit depends on what your team can do with that time.
Make the current state tangible
Do the math.
Then check the assumptions.
Explore the effort involved in preparing completed jobs for invoicing. Separate hands-on work from waiting, and include the effort needed to keep a change running.
Illustrative example
What does this workflow take?
Use the number of jobs expected to follow the revised process. Include manual cases, checking and corrections in its average preparation time.
Monthly human effort
25
hours / month
potentially released
potentially released
Capacity you could put to other work. This is not automatically a reduction in payroll or business costs.
See the calculation and what still needs checking
Current: 300 jobs × 12 minutes ÷ 60 = 60 hours/month.
Proposed: 300 × 6 ÷ 60 + 5 upkeep = 35 hours/month.
Difference: 60 − 35 = 25 hours/month.
Validate the sample, volume, exception rate and average human time. Proposed effort is an estimate until the changed process is tested. Check invoice accuracy, adoption, build cost, software cost and maintenance before deciding.
Elapsed waiting, payment timing and cash savings are separate outcomes. This calculation does not establish them.
What would make the change worthwhile?
We also examine build and operating costs, exceptions, whether people use the revised process and what the released time could accomplish. Faster billing, lower costs and higher profit each need their own evidence.
What to bring
Follow one piece of work.
A recent job, quote or invoice gives us a useful starting point. Bring a normal case and an exception if you can.
01
Start with the record
Where did the work begin? Which systems hold the details?
02
Name the handoffs
Who needed information, from whom, and what was missing?
03
Separate effort from waiting
Count active work, correction and review separately from elapsed delay.
04
Describe the result you need
What should your team be able to do, and why does it matter now?
Choosing the implementation
Use what fits
the work.
We check the capabilities you already have before recommending an integration or custom build. The choice depends on the task, the information it needs, permissions and how your team will maintain the result.
Do you need a custom build?A useful first conversation
Start with the work that needs to change.
Bring one real example. We’ll talk through what happens today, what a useful improvement would look like and the next step.