Installation Feasibility Standards

Installing a physical product depends on conditions at the customer's site that nobody internal can see. The standards existed to define what has to be known before scheduling, to make the customer's answers verifiable rather than described, and to give reviewers one consistent way to approve or stop an order.

Failed installations were being treated as field problems when most of them were qualification problems. Surface type, clearance, power, and access were collected inconsistently or taken on trust. Reviewers applied their own judgment, so two people looking at the same submission reached different answers. The failure surfaced at the worst possible moment: a crew on site, a customer waiting, and nothing anyone could do that day.

• Define what is supported, what is conditional, and what is not supported, in plain language and with pictures. Ambiguity here converts directly into wasted dispatches.
• Require evidence, not description. A customer saying there is enough room and a photograph showing the room are different pieces of information.
• Give reviewers a fixed order of checks so the same submission produces the same answer regardless of who opens it.
• Allow exactly three outcomes: approve, clarify once, or flag as unsupported. Open-ended back and forth is where orders go to age.
• Treat an unsupported site as a correct outcome. A qualification standard that only ever approves is a scheduling form.
• Write the customer-facing wording alongside the internal criteria, because the criteria are only useful if a non-expert can answer them.

1. 01

   A site qualification standard

   Supported and unsupported surface types, clearance requirements, power and access conditions, each written as a check with a defined pass condition rather than as guidance.

2. 02

   An evidence requirement

   Required photographs for each claim, with framing instructions written for someone holding a phone who has never done this before.

3. 03

   A review process

   A fixed order of checks and three permitted outcomes, so review became a repeatable procedure instead of an individual judgment.

4. 04

   A single clarification rule

   One consolidated request back to the customer rather than serial questions, because each round trip costs days and goodwill.

5. 05

   An internal installation reference

   The same criteria written from the crew's perspective, so the field and the reviewer were working from one definition of feasible.

1. 01

   Photographs over self-reported answers

   It added friction to the customer form and removed a whole category of failed dispatch. Customers are not wrong on purpose. They are answering a question they have no reason to be expert in.

2. 02

   One clarification round, then a decision

   Unlimited follow-up feels helpful and quietly produces orders that are neither cancelled nor scheduled. A forced decision point keeps the queue honest.

3. 03

   Publish the unsupported list

   Naming what cannot be installed protects the customer from a wasted day and protects the crew from being asked to improvise. It also made the exception data countable.

4. 04

   Require visual evidence before a post-visit ticket exists

   Issues raised after a visit were previously described in prose and escalated on tone. Requiring a photograph before a case is created made the severity assessment factual.

• Removed a recurring failure point identified in the order lifecycle map.
• Fed the exception taxonomy with a feasibility category that could be counted.
• Set the evidence standard later reused in remediation and field quality work.

The interesting part was not the criteria. It was discovering how much of the failure rate came from asking a customer a question they could not reasonably answer. Once the form asked for a photograph instead of a judgment, the accuracy problem largely disappeared. If I revisited it I would test the wording of the customer questions the way you would test product copy, because that wording is doing more work than the review process behind it.

• Customer Operations
  Order Lifecycle Failure Map →

  Nine lifecycle stages drawn alongside the specific failure that occurs at each one, with the current state and the intended state stated side by side.

• Customer Operations
  Order Operations Architecture →

  An operating model for orders: one rule that settles ownership, a split-intake work design, and a decision tree an associate can run in the moment.

• Customer Operations
  Relocation Service Design →

  A move modeled as two dependent orders rather than one job, with the link between them treated as the thing most likely to fail.