A systems discovery call is often treated as a sales meeting with extra notes. The supplier talks, the buyer listens, a brochure follows. That is not discovery. A useful systems discovery session maps how work actually moves, which tools already hold it, who owns each step, and where the risk sits if something fails. It should leave both sides with a shared picture, not a product pitch.
If you are buying workflow automation, communications, a website, or an integration, the first conversation should be about pathways. What happens from first contact to completed work? Where does that stall? What must not be disrupted while you change it? Those questions belong on the agenda before anyone names a platform.
What a systems discovery call is actually for
The job of the call is diagnosis. By the end, both sides should describe the same pathway in plain language: how demand arrives, who owns the next action, which screen holds truth, and what happens when that person is off. If the hour is spent on slides and demos, you have had a pitch with a polite title.
Who sits in the room matters more than the software. Bring someone who does the work and someone who can approve a first phase. The person who answers the phone, processes the form, or chases the quote will tell you where the path actually breaks. The director will tell you what must not go down. Buyers alone produce a tidy story. Operators alone may leave you with no decision.
A serious supplier will resist architecting live. They will ask how work enters, how it is recorded, who is accountable when it ages, and what you have already tried. They will listen when the answer is a CRM the team barely opens, a shared inbox everyone dreads, or a diary only one person trusts.
Timebox the session around one pathway. Mapping the whole firm in an hour produces a blur. Pick the path that hurts: new enquiry to booked work, request to a status the client can see, job to invoice. Walk it slowly. Exceptions are the process you will have to design for, because the happy path already mostly works.
Map the pathways before anyone names a tool
Start at the front door. How does demand actually arrive: phone, web form, email, walk-in, referral, a portal, a partner? For each channel, who sees it first, and how long can it sit before someone is accountable? If the honest answer is that it depends who is in, people are acting as the router. That holds until volume, leave, or a busy Tuesday arrives, and then the item that needed a decision waits next to everything else.
Then follow the work. Where is the job or case recorded? When does a conversation become a record? Who can see status, and who cannot? How does the client or citizen hear what happens next? Closure is part of the path: done, billed, filed, reported. Many organisations describe the start of a job and go vague at the end. That vagueness is where rework, unpaid extras, and repeat contact live. A discovery that stops at the shopfront has not mapped a pathway.
Ask for the unofficial path as well as the official one. The chat group that actually assigns vans. The spreadsheet finance trusts more than the CRM. The personal mailbox that still receives important clients. Those artefacts show where the current tools failed the week. Capture only the tidy version and you will recommend a tidy system that staff ignore under pressure.
Talk about load in ordinary language. What does a heavy day look like, and what happens when the usual owner is off? If the path only works because one person holds it in their head, write the name. Cover is part of the design, or it is a hope you will test the first time someone is ill. Keep the shopping list last. Do not jump to a CRM until you know what it would have to hold, who would update it, and which existing tool already holds a version of the same fact.
Tools, ownership and the joins between them
Once the path is visible, inventory the tools people actually open: email, telephony, a diary, a CRM, accounting, a website CMS, a shared drive, a job app, a form builder. For each, ask whether it is the source of truth for anything, a view of something else, or a leftover.
Name the source of truth per object: contacts, jobs or cases, money, calendar time, documents, messages. If two systems both think they own the same object, staff will copy, and copying is where records diverge. Re-keying is a design smell: a form dumps to email, a person types into a CRM, someone else types into a job sheet. The procedure may demand accuracy. The week will demand speed. Speed will win.
Ownership has two layers. Who owns the pathway when an enquiry ages, a booking collides, or a status is wrong? Who owns the tools: who can change a workflow, who holds admin access, who would be locked out if one person left? Shared logins and a vague appeal to whoever handles IT are delayed incidents. A deputy with the same view and the same rights is part of the map. A message that says keep an eye on it is not.
The joins matter more than the logos. Which tools already talk? Which joins are a person? Which fail silently: a website form that never creates a record, a missed call with no task, a calendar that is a view rather than a constraint? Phone, SMS, email, and the website sit inside this map. Assistants or voice reception only earn a place if the write path is real. Named products are optional modules, not the agenda of the call.
Risk, constraints and what you should leave with
Risk is the list of ways this path already fails, and the ways a change could make it worse. Missed first contact. Duplicate records. A queue that ages without an owner. A status nobody trusts. A go-live that takes email down on a Monday. A number you cannot lose. Data that must stay in the United Kingdom. A peak period when you cannot train anyone. Write those down in the room. If they only appear later in a statement of work, they were assumed, not discovered.
Treat constraints as design inputs. You may need to keep a phone number, a domain, a records system, or a finance package. You may have procurement rules, accessibility duties, or a narrow change window. You may have no appetite for a long programme when one pathway is on fire. A supplier who treats those as problems to overcome is selling. A supplier who treats them as the shape of phase one is discovering. Reuse versus replace should be spoken plainly before anyone quotes for a rebuild.
Phase one should change a real week: capture that creates a record, routing that names an owner, a booking that writes to the diary you actually use, a status a client can see without ringing. If discovery cannot describe that slice in operational language, you are not ready to buy a build. Leave with notes both sides can read: the pathway, the tools and owners, the workarounds, the constraints, and a next step with a boundary. That step might be a small written scope, an instruction to turn on something you already pay for, or a frank decision that you are not the right partner.
- Bring someone who does the work and someone who can approve a first phase.
- Pick one painful pathway and walk it from first contact to done.
- List every channel demand actually uses, including the unofficial ones.
- Name the source of truth for contacts, jobs, money, time and documents.
- Write down who owns the pathway and who owns the tools, with deputies.
- Surface workarounds: personal inboxes, chat groups, shadow spreadsheets.
- Record constraints: numbers, systems, data, peak periods, what must not go down.
- Separate must-fix this quarter from work that can wait.
- Ask what phase one would change in a normal week, in production.
- Leave with written notes both sides can read, not only a follow-up that says it was useful.
A systems discovery call earns its name when it produces a map of pathways, tools, ownership and risk. That is the work. The products come after, and only where they serve the path you actually run.
Lightning Business Solutions does that mapping for UK organisations across workflow automation, AI assistants, phone and SMS, email systems, websites, and integrations. The point of the first conversation is to see the bottleneck clearly enough to scope a real first piece, or to tell you that the first piece is smaller than you thought.
Talk through the pathways that matter on our contact page, or see how the pieces fit under capabilities.