LearnGrokUse one structured workspace to turn plans, supplier commitments and operating requirements into a checklist the opening team can run. You will finish with open items, one owner per item, target dates, evidence and a clear go or no-go recommendation.
This is for operations teams opening an office, depot, store or service location. It works best when one person owns the checklist and uses the model to organise evidence, expose gaps and prepare the daily opening review.
Key point
Build the checklist from evidence, not memory
Treat every requirement as an item with a source, an owner, a date and proof that it is complete.
1. Set up the opening pack
Create a folder or shared document called Site opening readiness pack. Put the material below in it before asking the model to draft anything:
- The latest site plan, floor plan and equipment layout.
- The opening date, trading or service hours, and any phased opening plan.
- The operating requirements: staffing, receiving, storage, customer areas, cleaning, security, waste, IT and emergency arrangements.
- Supplier quotations, orders, delivery dates, installation dates and named supplier contacts.
- Building, landlord or project-team handover documents.
- Existing company checklists for comparable locations.
- Known dependencies, such as a network connection before payment equipment can be tested.
Give each file a clear name, for example 01_floor_plan.pdf, 02_supplier_schedule.xlsx and 03_operating_requirements.docx. Add a short note if a document is old, provisional or missing pages.
Do not merge conflicting documents into one version yourself. Keep the originals. The point is to let the checklist show where the team needs a decision.
Watch out
Do not treat a supplier promise as completion
A delivery date is not evidence that equipment is installed, working and accepted by the site team.
2. Ask for a requirements map first
Upload or paste the opening pack into the conversation. If the material is large, work in groups: site and building, suppliers, then operating requirements. Keep the same checklist structure each time.
Start with this prompt:
You are helping prepare a new site for opening. Read the attached material and create a requirements map. Do not assume missing facts.
Group requirements under: building and access; utilities; IT and communications; furniture and equipment; safety and security; cleaning and waste; stock and consumables; people and training; customer or service readiness; supplier handover.
For each requirement, give:
- requirement
- source document and page or section, if available
- dependency
- proposed evidence of completion
- missing or conflicting information
Mark any item that could prevent opening as critical. Return a table.
Read the table before moving on. Correct category names to match your business. Add local requirements that may not be in the documents, such as keys for shift leads, refrigeration temperature checks, vehicle access or a reception process.
The model may be able to read a plan but can confuse labels, scale or annotations. For dimensions, fire routes, utility positions and capacity figures, check the original drawing with the appropriate project or facilities person. Use the model to list what needs checking, not to approve the drawing.
Check
You have a usable requirements map when every row has a source or is clearly marked as an assumption
If a requirement has neither, it is a question for the opening team, not a completed task.
3. Convert requirements into checklist rows
Next, ask for the operational checklist. Use fixed fields so the list can move into a spreadsheet, project board or shared tracker without being rebuilt.
Convert the agreed requirements map into a site-opening readiness checklist. Use one row per verifiable task.
Use these columns:
ID | workstream | checklist item | completion evidence | dependency | accountable owner | supplier or contributor | target date | status | risk if late | source | notes
Use these status values only: not started, in progress, blocked, ready to verify, complete, not applicable.
Leave accountable owner and target date blank where the source does not establish them. Do not invent names, dates, approvals or regulatory requirements. Flag duplicate tasks and dependencies that make the target date unrealistic.
A good item describes an observable state. Replace IT ready with Wi-Fi is live in staff and customer areas, and the shift lead has completed a connection test. Replace cleaning arranged with Cleaning supplier has completed the pre-opening clean, and the site lead has recorded defects.
Assign one accountable owner to each active row. Suppliers can contribute, but they should not be the accountable owner. The owner is the person who chases the dependency, verifies the evidence and escalates a block.
Set target dates backwards from the opening date. Put testing and defect correction before final acceptance. For example, equipment installation may need to finish before connectivity tests, staff training and a dry run.
4. Run a short readiness review each day
Use the same checklist in a daily review during the final opening period. Ask each owner to update only their rows before the meeting. Then paste the changed rows and use this prompt:
Review this site-opening checklist update. List:
1. critical blocked items,
2. items due before the opening date that have no owner or target date,
3. dependencies at risk,
4. evidence still needed for items marked complete,
5. decisions needed today.
For each issue, state the checklist ID, accountable owner, target date and the next action. Do not say an item is complete unless evidence is recorded.
Keep the meeting to exceptions. Do not read complete rows aloud. Record each decision in the notes field with the date and decision-maker, especially if the team accepts a temporary workaround.
| If you see this | Treat it as | Do this next |
|---|---|---|
Complete with no evidence |
Unverified completion | Return it to ready to verify and name the verifier |
| A blank owner | No accountability | Assign an internal owner before the meeting ends |
| A supplier date after a dependent test | Schedule conflict | Replan the test or escalate the supplier commitment |
| A workaround with no end date | Hidden opening risk | Add a closure date and a person who will remove it |
5. Produce the go or no-go brief
On the day before opening, freeze a copy of the tracker. Ask the model to prepare a short decision brief from that copy:
Using this frozen readiness checklist, draft a go or no-go briefing for the opening decision-maker.
Include: opening date; completed critical items with evidence; outstanding critical items; other open items; accountable owners; target dates; workarounds; decisions required; and a recommendation of go, conditional go or no-go.
Base the recommendation only on recorded evidence and stated opening criteria. Separate facts from assumptions. Do not make safety, legal or technical approvals.
The opening decision-maker should review the source evidence, not only the summary. A conditional go should state the exact condition, who accepts it and when it must be resolved. Where formal safety, building or technical sign-off is required, obtain it from the qualified person.
Check
The brief is decision-ready when every outstanding item has an owner, a date and a stated effect on opening
If the recommendation depends on an unnamed person or an untested system, it is not ready for sign-off.
Check where the output is wrong
The most dangerous errors are tidy-looking assumptions. Check the checklist against the plan, order confirmation and operating requirement for items that affect access, utilities, equipment location, testing, staffing and handover.
Look particularly for:
- Dates copied from a quotation rather than a confirmed schedule.
- One task hiding several separate checks, such as delivery, installation and test.
- An item marked complete because it was ordered.
- Missing requirements caused by a vague operating document.
- Contradictions between the site plan and supplier specification.
- Critical tasks without a practical fallback.
The model can help identify inconsistencies, but it cannot see activity that is absent from the records. Walk the site with the checklist. Capture photographs, test records, acceptance notes or other evidence in the row or linked folder.
For current information about file handling and product behaviour, check the xAI documentation overview. Details can be version-dependent.
When the checklist does not work
If the output is generic, give the model one real completed checklist row and ask it to match that level of detail. If it misses whole workstreams, add the missing operating requirement and rebuild the requirements map before editing individual tasks.
If owners or dates remain blank, do not let the model fill them with guesses. Take those rows to the daily readiness review as decisions. If the recommendation is unclear, tighten the opening criteria, record the missing evidence and issue a fresh frozen checklist for review.
