Diagnose: find out whether software is even the answer
Every engagement starts with working sessions on your operations, numbers and constraints — not a pitch deck. We map the workflow, price the leaks, and tell you plainly whether a system is worth building. Often, it isn't, and we say so.
What actually happens
No discovery theatre, no workshop week with sticky notes. Five concrete steps, run by the people who would build the system.
- 1
A working session on the operation itself
Not a sales call. An engineer and a partner sit with the people who run the process — dispatch, intake, billing, whatever it is — and walk through how work actually moves, including the workarounds nobody wrote down.
- 2
We map the workflow end to end
Every handoff, every re-typed field, every spreadsheet acting as a database. The map shows where hours go, where errors enter, and which steps exist only because two tools don't talk to each other.
- 3
We put numbers on the leaks
Hours per week, error rates, cycle times, payroll cost of manual steps — measured from your data where it exists, estimated conservatively where it doesn't. These numbers become the baseline any future system is judged against.
- 4
We pressure-test the constraints
Compliance requirements, legacy systems that can't be switched off, team capacity, budget reality. A recommendation that ignores constraints is theatre — so we surface them before recommending anything.
- 5
We answer the only question that matters
Is software the fix — and which kind? Sometimes the honest answer is an off-the-shelf tool, a process change, or a smaller automation than you had in mind. Roughly a third of the time, our advice is not to build.
The deliverable: a written diagnosis
Not a slide deck — a document your team can act on with or without us. It's yours to keep either way, and it becomes the input to the estimate if you continue.
The workflow map
How the process runs today — handoffs, tools, exceptions and workarounds — in a form your own team will recognise as true.
Where the money leaks
The manual steps, error loops and delays, priced in hours and cost — the baseline for any build that follows.
The recommendation, in plain language
Build, buy, change the process, or do nothing — with the reasoning written out. If we advise against building, this is where we say so.
What we'd do next, if anything
If software is the answer, a sketch of the system and the metric it should be accountable to — the input to the estimate phase.
What we need from you
Deliberately little. The diagnosis is designed to run alongside your normal week, not on top of it.
2–4 hours of the process owner's time
One or two working sessions with the person who actually runs the operation — not a steering committee.
Access to the people who do the work
Short conversations with the operators, dispatchers or clerks living in the process daily. They know where it hurts.
Whatever numbers you already have
Order volumes, headcount on the process, error logs, exports — rough is fine. No preparation or documentation required; we work with what exists.
Stopping here is a fine outcome
If the diagnosis says "don't build", or you simply decide not to continue, the engagement ends there — no charge, no obligation, no follow-up sequence. You keep the written diagnosis and every number in it. A third of the time, that document is the whole value: it saves you a build.
Common questions
How much of our time does the diagnosis need?
Roughly 2–4 hours from one accountable owner, plus short conversations with the people who run the process day to day. We do the mapping and the numbers — you supply reality.
Is it really free? What's the catch?
It's free and there's no obligation to continue. The catch, if you want one: diagnosis is how we scope well enough to give estimates that hold — it's underwriting, not marketing. If nothing comes of it, you still keep the written diagnosis.
What if the answer is "don't build"?
You get that in writing, with the reasoning and usually a cheaper alternative — an off-the-shelf tool, a process change, or a smaller automation. It happens roughly a third of the time, and it costs you nothing.
Do we need to prepare documentation first?
No. Most operations we diagnose have no accurate documentation — that's part of the problem we're mapping. Whatever exports, spreadsheets or numbers you have on hand are enough.
Can one diagnosis cover several processes?
Yes — we often look at two or three connected processes in one pass, because the leak is usually in the handoffs between them. If the scope is genuinely large, we'll say so and sequence it.
Who from SigmaJunction actually shows up?
An engineer who would work on the build, plus a partner. Never a dedicated salesperson — we don't employ any.
The four phases
Full process overview →Working sessions on operations, numbers and constraints — free, 1–2 weeks.
The diagnosis becomes a scoped proposal: architecture, milestones, price and metric — free, 1 week.
Phase one costs you thirty minutes.
The first session is free — and a third of the time, the outcome is "don't build," in writing.