Field guides / before the build
Fieldguides,before anybody builds anything.
What we show before an engagement, how a delivery is staged, and the safeguards that sit around an integration. The five sector guides start from an observable event rather than a category of software.
- 5field guides
- 4delivery stages
- 6systems you can drive
What we demonstrate before an engagement.
What you are shown before a scope is signed is a demonstration, and it is introduced as one. It is not a live connection to your systems, it is not a client dashboard, and nothing said inside it should be taken as operational advice. Its whole purpose is to agree three things: the moment where work gets lost, the person who has to act on it, and the result that would count as it being fixed.
Alongside that sit six systems that are genuinely running on our own server, and those are not simulations. On a call we open the one closest to your business and hand you the keyboard. They hold demonstration data of our own making: no client records, no customer data, no bank or point-of-sale extracts belonging to anybody else.
If the flow is relevant, the next step is a short diagnostic that maps it onto your actual systems and rules. That is the point at which claims stop being general and start being about you.
The delivery model
Four stages, each ending in a decision that is yours rather than ours.
Diagnostic
You receive. A current-state map, the priority bottleneck and a recommended first scope.
We validate. The business owner, the workflow steps, the source systems and the measurable outcome.
You decide. You approve the outcome and name the operating owner.
Blueprint
You receive. A delivery sequence, the integration boundaries, a risk list and the acceptance criteria.
We validate. Data quality, permissions, policy constraints and the hand-off owners.
You decide. You approve scope, timeline and the access model.
Pilot
You receive. A small working workflow in a controlled environment.
We validate. Exception handling, logs, usability and the pilot success criteria.
You decide. You approve pilot acceptance and the next stage.
Production
You receive. The documented workflow, an access register, a support hand-off and a monitoring plan.
We validate. Live credentials, user roles, error handling and the release plan.
You decide. You confirm go-live and the named escalation owner.
Moving Odoo 16 or 17 to 19
A version move is quoted as a fixed price, 25,000 to 60,000 EGP, and where it falls in that range depends on how many custom modules travel with you and how much of the data has to be reshaped. It runs on a copy of your database first and is signed off there; the live system is touched once, on the day you choose.
Five field guides
These are hypotheses, not diagnoses. Use the one that resembles the work in front of you, then let the team doing the work correct the picture.
Multi-location retail — When the branch knows before head office does.
Signals to look for
- Exceptions surface in chat, in calls, or in an end-of-day report
- A branch issue has no visible owner and no due action
- Head office learns about a gap after a customer has already felt it
- The same issue is rekeyed into several sheets or systems
The first control. One shared exception queue where a branch signal is captured, owned by a person, evidenced, and closed with a note in plain language.
The pilot boundary
- One approved branch group
- One exception category, such as availability or pricing
- Named branch and operations owners
- Resolution stays human: no register, inventory, refund or accounting action
What it does not authorise
- No autonomous stock changes
- No replacement of the register
- No customer or payment data needed
Field service and facilities — Proof of work should not arrive after the escalation.
Signals to look for
- Jobs are confirmed verbally and the proof is hard to find afterwards
- Supervisors chase technicians for updates and evidence
- A customer escalation arrives before a service status does
- The billing hand-off depends on somebody remembering to follow up
The first control. One controlled work-order slice with an assigned technician, a stated proof requirement, a supervisor review gate, and a billing-ready state.
The pilot boundary
- One client, site group or service line
- Configured job types and proof expectations
- Named technician and supervisor roles
- Human approval before any external or billing hand-off
What it does not authorise
- No dispatch-optimisation claim
- No invoice generation
- No replacement of the core field-service system
Restaurants and food groups — Turn the daily exception into a controlled next action.
Signals to look for
- Site issues move through chat with no trail behind them
- Recurring incidents are noticed but never classified
- Operations leaders cannot see what is open across locations
- Closing an issue depends on a few people remembering the context
The first control. One high-frequency operating exception, with its owner, its evidence, its reviewer and its closing condition made visible across the locations it touches.
The pilot boundary
- One exception type
- A limited group of locations
- Clear ownership and resolution states
- No change to menus, prices, orders, payments or customer records
What it does not authorise
- No replacement of the restaurant register
- No food-cost calculation claim
- No automated messages to customers
Logistics and distribution — A delayed hand-off is still an operating event.
Signals to look for
- Delivery or service proof sits on personal phones and in chat
- Issues are visible only in a late report
- Operations and finance are working from different versions of the same event
- Exception follow-up has no durable owner
The first control. One exception-to-review hand-off, so the team can see the event, its owner, the state of the evidence and the next human decision in one place.
The pilot boundary
- One route, depot, service type or delivery event
- One owner group and one escalation path
- Proof and exception evidence only
- No fleet optimisation, no accounting entry, no action inside the source system
What it does not authorise
- No live-tracking promise
- No automatic inventory adjustment
- No replacement of a transport management system
Professional services — The document is not the workflow. The review is.
Signals to look for
- Reviewers keep asking for the same missing evidence
- Approval status is inferred from an email chain
- Nobody can tell which item is genuinely ready for a decision
- The knowledge sits with whoever last touched the request
The first control. One review queue with agreed evidence labels, a visible reviewer status, exception states, and a hand-off that only happens after approval.
The pilot boundary
- One business unit or request type
- A short evidence checklist
- A named reviewer group
- No file archive, no payment, no tax action, no posting into the ledger
What it does not authorise
- No replacement of a document archive
- No autonomous approval
- No sensitive records in any demonstration
Integration safeguards
The same rules apply whether the work is an Odoo module, a messaging flow or an e-invoicing implementation.
- A dedicated integration user in Odoo, holding only the permissions the workflow needs, with its keys rotated on a written schedule.
- Opt-in, approved templates and a human escalation path for anything that sends a message to a customer, made part of the scope rather than discovered later.
- A traceable event history for e-invoicing, validated in the correct environment, with the tax credentials and the certificate owned by the client and nobody else.
- An access register with a review date. Named least-privilege accounts, never a permanent administrator login shared around.
- Nothing sensitive through an open form or a chat. Passwords, API keys, tax certificates, customer records and production database exports are handed over once, securely, inside a signed scope.
Bring a better first question.
Take the guide closest to your work, correct the parts that are wrong about you, and send it back. That is already most of a diagnostic.
Or open one of the six running systems with us on a call.