A vendor track record is what the named clinical owners and the named post-go-live support model say it is. Logos are a press release. Names are a track record. The difference is between a vendor that has shipped the system and a vendor that has shipped the system through the Rules of Engagement on a floor run by named people — that difference shows up in the cell-by-cell ledger you actually get to read, not in the deck the salesperson handed you at the demo.
This post is the buyer-side checklist we hand to clinical informatics leads and CIOs on the client side before they sign. It does not measure the vendor against its own marketing. It measures them against the floor — the named owners, the named support model, and the named signals in the first ninety days after cutover. The terms below — named Forward Deployment Engineer, stabilization, Rules of Engagement — sit on the same cell-by-cell list we read against on every engagement; the prior posts on the blog go through the same cells at greater length. If a vendor cannot produce line items on this checklist, the conversation is not closed; it is opened back up.
The prior deployment roster is the first line item. Ask for three named systems in shape — three systems with the same product line you are signing for, in the same shape you are signing into (a 700-bed academic medical center in the Midwest, a multi-site ambulatory network, a community system with a single inpatient tower, whatever matches the cutover shape on your readiness list). For each, ask for three named client-side owners from the engagement: a named clinical informatics lead, a named frontline operations manager, a named integration architect. Then ask for four dates: the week the named Forward Deployment Engineer was on the floor during cutover, the week the engagement closed, the named post-go-live support model that took over after close (queue or named operator — the difference is the difference between a transition and a true support model), and whether the named client-side owner running the program today was the same person who ran it at close. If the vendor cannot name these for three prior engagements, ask again — this is a list, not a riddle, and the absence of names on the list is the answer.
The post-go-live support model is the second line item, and it is the one buyers read least carefully. A ticket queue is not a support model, it is a transition — the floor runs the floor, the ticket sits in the queue, and the readiness list drifts against the queue without anyone named owning the drift. The named vendor operator who carried stabilization on the prior engagement is the same named FDE operator you want answering the page in month two. Ask the vendor to name the post-go-live support model by structure: who answers, under what SLA, for how long, with what named FDE operator continuity into month six, and whether the named operator who carried stabilization on the prior engagement is still on the floor for the engagement you are signing. Then ask them to walk you through measured response time at week eight on a recent prior engagement — not the SLA wording, the measured median, named, with the named client-side owner who tracked it. If the vendor quotes SLA language rather than measured time, the support model is a transition. If they quote measured time and name the owner, the support model is the engagement continuing. Sign on the latter.
The 90-day early signals are the third line item — four of them, each named, each tied to a readiness-list cell. Vendor staffing churn after cutover — the named FDE operator rotates, the named support contacts rotate, the named escalation contacts rotate. If the named engineer who sold you the engagement is not the named engineer on the floor in month three, the support model is a transition even if the SLA is a model. Integration ticket volume, week by week, by category — a single spike on a single category is recoverable; a steady stream across categories over six weeks is the readiness list drifting behind the support queue. Scope drift and change orders in month two — named work expands before the named owners can close what they signed in week zero. Named-owner handoff patterns — whether named clinical and operational owners on the client side are still running the program at day ninety, or rotated into other work. Each of these four signals sits on a readiness-list cell; each is named, observable, and reportable from the data the cell produces every Friday.
This is also where the frequently asked questions on the FAQ page live — the questions CIOs ask us in the first engagement call about how the named owners survive a vendor handoff at month two are the same questions buyers should be asking the vendor they are about to sign.
When the roster does not name names, the answer is open the conversation back up. Send the checklist back to the vendor with the columns named, ask the vendor to populate them, and read the populated list against the readiness list on your side. If the populated list reads against your floor, sign. If it does not, do not. When the names come back — three named systems, three named owners at each, four named dates, a named support model that is measured and not a transition, four named 90-day signals that match the readiness list cells on your side — that is the contract to sign.
For the same vendor track record in the form of an integration conflict after the contract is signed, read the prior post on integration conflict at week three — the cell it lives in is the Workflow Drift cell, and the named owners are the ones you want populating the roster above, and the handoff side of the same window is the prior post on the 90-day stabilization phase.