Maintain the decisions the team uses
Assign ownership for each play and supporting asset. Review after meaningful events: a repeated rejection, changed product boundary, integration failure or new buying pattern. Keep the original rule and revision reason so the team understands why practice changed.
Use operating reviews to identify gaps. Ask whether a new seller can classify an account, handle a reply and choose the next buyer action from the material. If not, repair the relevant explanation or example. Avoid turning every one-off exception into a new permanent process without checking its relevance.
| Decision | Evidence to use | What changes next |
|---|---|---|
| Observe | Repeated buyer or operator evidence exposes a gap | Identify the specific rule or material affected |
| Revise | Owner updates the decision, example and dependency | Preserve version and rationale |
| Test | Operator applies the revision to an unfamiliar case | Verify usefulness before broad adoption |
Work through the decision
Illustrative change: the product adds a supported deployment option. A former disqualifier may now be outdated, but not every old rejected account becomes suitable. The maintainer revises the capability boundary and adds a new example with remaining adoption constraints.
A seller tests the rule on a fresh account and a previously rejected case. If the reasoning remains unclear, improve the example before restarting broad outreach. Maintenance should change actions responsibly, not simply announce that more accounts can be targeted.
The archive grows while the working answer gets harder to find
Separate current plays from historical material and clearly label superseded rules. Remove duplicate instructions from the active path. Operators should not have to guess which of three conflicting versions applies.
A concrete next step
Select one frequently used play, identify its owner and test it with a new operator. Repair the first decision they cannot make, then set a review trigger based on actual evidence.
Sources and research notes
- GitLab sales operating proceduresCompany operating handbook
- GitLab commercial sales enablementCompany operating handbook
- GitLab customer-ready shadow programCompany operating handbook
Primary sources reviewed October 6, 2026. The operating recommendations and worked scenarios are Daavid’s analysis. Illustrative numbers are assumptions, not measured client results. Company marks identify sources and prior experience; they do not imply a customer relationship or endorsement.
Schematic