Map Your Enquiry Workflow Before You Build Custom Software

Most requests for custom software start with screens. “We need a CRM with a pipeline view.” “Customers should be able to see their quote online.” Those are reasonable wishes, but they describe the interface, not the work. If nobody has written down what actually happens between a first enquiry and a signed job, the software ends up encoding guesses, and the team starts working around it.

A workflow map is the cheaper place to find that out. Moving a sticky note costs nothing. Changing a status model after it’s built into the database, the permissions and the reports costs real time. You don’t need a consultant or special notation to make one. You need the people who do the work, a wall or a whiteboard, and a couple of hours.

Pick one journey with a clear start and end

Don’t map “the business”. Pick one journey that matters commercially and has an obvious beginning and end. For most service businesses that’s enquiry to accepted quote, or enquiry to completed job.

Write the start and end on the wall first. “A potential customer gets in touch” and “the job is booked with a deposit paid” are good boundaries. Everything outside them waits for another session.

Walk it with the people who do it

Invite whoever answers the phone, whoever prepares quotes and whoever schedules the work. The owner’s version of the process and the version the team actually follows are often different, and the software has to support the second one, or deliberately change it.

Ask them to walk through a real recent enquiry, step by step. One card per step, in order. When someone says “it depends”, that’s a branch: write both paths. When someone says “usually”, ask what happens the rest of the time. The exceptions are where most of the design work ends up.

Seven questions for every step

For each card, answer these. Write the answers on the card or next to it.

1. What starts this step? A form submission, a phone call, an approval, a date passing.
2. Who does it? A role, not a name. If the answer is “whoever’s free”, note that too.
3. What information do they need? And where do they get it today: an email thread, a notebook, a spreadsheet, someone’s memory.
4. What do they decide? Accept or decline, which consultant, which price, whether to chase.
5. What do they produce or hand over? A note, a quote, a booking, a message to the customer.
6. How long does it wait? Before the step starts and after it ends. Waiting is often where enquiries go cold.
7. What goes wrong? Missing details, a customer who stops replying, two people working the same lead, a change after the quote was sent.

Question 7 is the one people skip and the one that matters most. Software that only handles the smooth path pushes every exception back into email.

A worked example (fictional)

The following example is invented to show the method. It isn’t a VoxTraffic client or project.

A kitchen and furniture studio with a showroom and four staff maps its path from enquiry to booked installation. Enquiries arrive through a website form, by phone and in person. A consultant is assigned, holds a first call, visits the home to measure, helps the customer choose materials, prepares a quote, revises it, and once the customer accepts, the installation is scheduled.

Walking a few recent jobs through the seven questions turns up specific problems:

• Enquiry arrives. Form enquiries go to a shared inbox; phone enquiries go on paper by the till. Nobody can say how many enquiries came in last month. Requirement: one enquiry record, whatever the channel, with its source.
• Consultant assigned. It depends who notices first. Twice, two consultants called the same customer. Requirement: an owner on every enquiry, visible to the whole team.
• Measurement visit. Dimensions go in the consultant’s notebook and a photo on their phone. When a cabinet doesn’t fit, nobody can find which measurement was used. Requirement: measurements stored on the project, with who took them and when.
• Quote revised. The customer asks for a different worktop. A new PDF goes out by email. Later, nobody is sure what changed between version two and version three, or which one was accepted. Requirement: numbered quote versions that keep what was issued, and show what changed.
• Quote sent, no reply. Nobody owns the follow-up. Some quotes are chased after two days, some never. Requirement: a follow-up task with an owner and a date, created when the quote is issued.
• Accepted, installation scheduled. The installer gets the job details by phone. Requirement: an installation view with the accepted version, the measurements and the address.

Notice that none of those requirements is “a pipeline view”. The pipeline may still be useful, but it comes out of the statuses the map revealed, not the other way round.

If you want to see what a map like this can turn into, our furniture and kitchen studio concept is an interactive sample application covering enquiries, measurements, quote versions and installation planning. It runs on fictional sample data and was built as a demonstration, not for a client.

Turn the map into requirements

Once the cards are on the wall, read them again and sort what you learned into five lists. Together they’re most of a software brief.

• Records. The things you need to keep: enquiries, customers, projects, measurements, quotes, visits. Each noun that keeps appearing in question 3 is a candidate.
• Statuses. The decisions from question 4 become the states a record moves through, such as new, assigned, measured, quoted, accepted or lost. If the team can’t agree on a status, it needs a definition before it needs a screen.
• Permissions. Question 2 tells you who creates, edits and approves each record. Note what the customer should see, if anything.
• Notifications and tasks. Question 6 shows where things wait. Some waits need a reminder; some need a person to own them.
• Reports. Decide what you want to know at the end of the month: enquiries by source, time to first reply, quotes accepted or lost and why. A report can only count what the workflow records.

Then mark each item as essential for a first version or for later. A first version that handles one journey properly, exceptions included, is usually more useful than one that touches everything.

Note the personal data at each step

An enquiry workflow collects personal data from the first card: names, phone numbers, addresses, sometimes photos of someone’s home. Mark on each card what personal data is collected and why.

The GDPR’s Article 5 requires personal data to be limited to what is necessary for the purpose, and kept in identifiable form no longer than necessary. In mapping terms, that means two practical questions. Does this step really need this field? And what happens to the record of an enquiry that never became a customer? Decide a retention rule now, so it can be built in rather than added later. If you’re unsure what applies to your situation, check with whoever handles data protection for your business.

Signs the map is ready

Before you ask anyone to estimate or build, check that:

• The start and end of the journey are written down and agreed.
• Every step has an owner role, and nobody had to say “whoever”.
• The main exceptions have their own path, not just a note saying “sometimes”.
• Each status has a one-line definition the team agrees with.
• You know where today’s information lives and what has to move into the new system.
• Personal data and retention are noted.
• The first version is marked, and it’s smaller than the whole map.

What a map won’t tell you

A map shows the work; it doesn’t prove the software. It won’t tell you whether your existing accounting tool or website form can be connected, how clean your current spreadsheets are, or how the screens should feel to use. Those come out of discovery, a closer look at the data and, ideally, a working version of one step that the team can try. Expect the map to change once people use something real. That’s the point of doing it on paper first.

We start custom work the same way: a discovery conversation about the workflow, then, for a suitable project, one focused demo of a single screen or workflow before any project contract. Our process sets out each stage, and websites and business platforms covers the portals and internal tools we build. If you’re weighing a simpler option first, how long it takes to build a website explains what changes a timeline. When your map is on the wall, tell us which journey you want software for and we’ll tell you honestly whether it needs custom software at all.