The Opsian engineering audit — what we look for first

We start every engagement with an audit. Four to six weeks. We are on-site or as close as the engagement allows. We walk the workflow end-to-end, name the handoffs, and ask the people who run the operation what breaks when they leave for a week.

The audit is not a sales call. It produces a written document with the architecture of the operation, the manual steps that should not be manual, the places where data is moving but should not be, and the places where data is not moving but should be. The document is yours whether you continue with us or not.

Four questions drive the audit. They are not invented for the engagement. They are the same four we have asked at the start of every deployment we have shipped.

First — what is the decision the operation is actually making? Pricing is rarely just pricing. Front-desk is rarely just check-in. There is always a smaller decision underneath that the staff have been making by hand and the operation has never named. Until we name it, we cannot engineer around it.

Second — where is the data the decision needs, and who can see it? Most operations have the data. They have it in the PMS, the spreadsheet, the supplier email, the WhatsApp thread. The decision is not failing because the data is missing. The decision is failing because the data is not addressable. Engineering starts here.

Third — what is the failure mode the operation is paying for? Every operation has a price for the wrong answer: a comp, a refund, a callback, a churn. If we cannot price the failure, we cannot tell whether the AI is worth deploying. If we can, we know exactly which workloads will pay back in a quarter.

Fourth — what is the audit trail we want a year from now? The operations we deploy into are regulated, audited, or both. The system we ship needs to leave a trail someone who was not in the room can read. We define the trail in the audit, before we ship anything. It is the cheapest time to define it.

By the end of the audit, the customer has a written engineering plan that any team — ours, theirs, or a third party — could build from. Most customers ask us to build it. Some take the plan and run it internally. Both are valid outcomes. The audit was the work.

Engineering before audit is a bet on luck. We have shipped enough deployments to know which way the bet goes.