After the engagement: support and the next version

An engagement with E31 Consulting ends with the site team publishing a version on their own. What happens after that is mostly the site's business. This article sets out what the practice does and does not do once the engineers have gone, and how a next version gets built when the site wants one.

The ordinary case: the site changes it

Most changes after handoff are ordinary. A document set is added to the corpus. An approval moves from one role to another. A new system of record arrives and a route is declared for it. A bound is tightened after the run record shows a case the agent should have declined.

The site team has done each of these during training and has the notes to do them again. They publish a new version under their own role, the operating picture updates, the record continues. The practice is not involved and does not need to be told.

What the practice does not do afterward

The practice does not operate the use case. It does not hold access to the appliance or the segment. It does not keep a copy of anything built. It does not monitor the site from outside, because there is no path from outside. Support in the sense of a standing service desk for the use case is not something the practice offers, and the engagement is designed so the site does not need one.

The appliance itself is covered by its own subscription, which includes sustainment of the hardware and platform. That is separate from the practice and is not changed by an engagement.

When a change is bigger than the notes

Some changes are not ordinary. The site wants a second desk served by the same agent with a different approval structure. The corpus is to be extended to a kind of material the current version was not designed to read. A workflow that drafted and waited should now land results directly in a system of record, with a different person approving. The product that ships under the customer's name needs a capability its first version did not have.

The signal is usually in the run record. If the record shows a pattern the current version cannot express, or the site team finds that the change they want touches more than the notes describe, that is the moment to scope a next version rather than improvise one.

Scoping the next version

A next version is a new engagement, scoped like the first. It can be a forward-deployed engagement if the work needs engineers sitting with a new desk, or an in-house project if the site can describe what should be true when it is done. Often it is the second, because the site now knows its own use case well enough to write the statement of done.

The new engagement begins from what the site already holds: the current version, its history, the corpus, the adapters, the record, and the notes. Nothing has to be rebuilt or recovered from the practice, because the practice kept nothing. The engineers are granted access again by the customer, inside the posture the customer sets, and that access ends again at handoff.

Keeping the team able to change it

The best thing a site can do between engagements is keep making ordinary changes. A team that publishes a version now and then stays fluent; a team that leaves the use case untouched for a long stretch finds the notes harder to follow. The practice recommends the site treat small changes as practice for larger ones. If the team turns over, the notes and the version history are what a new operator learns from, and training them is the site's to do, using the same method the engineers used.

What stays constant

Across the first engagement, the ordinary changes, and any next version, the same things hold. The work is on the customer's appliance. The posture is the customer's. The versions, the corpus, the adapters, the record, and the documentation belong to the customer, as set out in what the customer keeps. The practice builds, hands back, and leaves no path out. The next version is built the same way, and ends the same way: with the site's own people publishing it.