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.
Project delivery
Know what needs to change? Let’s agree what done looks like.
When you need a defined build or repair, we agree the scope, fee, and the cases it must pass. Your team helps test an ordinary case and an exception, then practices running the result. See how we start when the scope is still open.
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.
Provide a process owner, access to the relevant records, timely business decisions and time for the affected people to test and practice the change.
- The correction or build, the systems involved and what is included
- Real examples to test and the person who approves the result
- Access, business decisions, testing and team practice needed from your team
- Delivery updates, rollout support and response expectations within scope
- 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. Published project prices start at $4,500 USD for a bounded Fix; First Result projects are $7,500, $15,000 or from $25,000, depending on scope. Continuing work has a monthly fee attached to an agreed roadmap and support responsibilities. For implementation projects, half is due at signature and half on written acceptance after the agreed checks pass. 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. Your proposal defines any defect support, its period and limits; 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, rehearse normal cases and exceptions with the people who will use the change, and leave working guidance.
- Review
Accept and plan the next step
Confirm the agreed result, documentation and maintenance responsibilities.
Your proposal states the actual timing and dependencies. We plan First Result projects around two to six weeks where the scope supports it. In a larger engagement, the first improvement within 30 days is a usable part of the work, not completion of every phase. Longer-term revenue and adoption outcomes need their own evidence.
Understand
Follow real work, including changes and exceptions.
Map the process, sample records, systems and people.
Design
Agree the handoffs, decisions and checks.
Define the proposed process, information needed and acceptance cases.
Build
Configure, connect or extend the systems.
Test the normal cases and agreed exceptions.
Practice
Rehearse the work with the people who will use it.
Leave working instructions, realistic scenarios and agreed rollout support.
Improve
Review actual use and decide what needs attention next.
Check agreed measures, issues and separately scoped next steps.
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 agree what completion means for your scope: the accepted change, tested cases, team practice, usable guidance and maintenance responsibilities. Continuing improvement or support beyond that scope is agreed separately.
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 |
|---|---|---|
| A customer change misses a team | A visible request, named approver and updates from the approved commitment | Missing updates, corrections, review effort and use by the affected people |
| 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
What should your team be able to do next?
Tell us what your team is trying to change. We’ll talk about what it needs to know, who needs to be involved, and where to start.