How SED LMS works

Overview

SED LMS is the operating console for a web-design practice. One record — the lead — carries a prospective client from first contact all the way through to a live website, a signed contract and ongoing support, and every part of the system reads from and writes back to that same record.

There are six working surfaces:

Lead pipeline

A lead is a business you might build a website for. It holds the contact details, what the business does, which services and service areas it covers, the pages it wants, any photos it supplied, the quoted one-time and yearly price, and a rating.

Statuses

Every lead sits in exactly one status. Statuses are permissioned in two directions: who may see leads in a status, and who may move a lead into it.

Finding the leads you care about

The leads table combines free-text search with filters for status, agent, site type, region, tags and month, plus sorting by newest, follow-up time, rating or business name. Columns can be shown or hidden and the row density adjusted, and those choices are remembered per person.

• Saved views. Name a filter-and-sort combination and reload it in one click. Views are private to you and scoped to the page you saved them on.
• Tags. Your own catalog of coloured labels. Tags can be applied in bulk, filtered on, and shared with other users when you want a shared vocabulary.
• Bulk actions. With rows selected you can change status, reassign, apply tags, archive, or export the current filtered set to CSV.

Ownership

Each lead has an assigned agent, and once it closes, a recorded closer. Reassignment can be done one lead at a time or across a whole selection. Deleting is a soft delete, so history is never destroyed, and duplicate businesses are detected on entry.

Follow-ups

Follow-ups are how a live lead stays alive. Logging one records what happened on the call, an optional status change, and — required — when the next contact should happen.

1. 1Log the outcome. Pickup or no pickup, with a comment describing the conversation.
2. 2Set the next time. A future date and time is mandatory, so no live lead is ever left without a next step.
3. 3Watch the queue. Follow-ups group into overdue, today and upcoming, ordered by when they are due.

Repeated no-answers are counted as a streak, which resets the moment someone picks up — an at-a-glance signal that a lead is going cold. Reminders can be delivered ahead of the due time; see Notifications.

Website generation

The Template Engine turns a lead into a complete, multi-page website. The important idea is that the brief is not written by hand: it is assembled from what sales already captured on the lead. The operator's job is to supervise, curate and approve.

The five-step wizard

1. 1Setup. Choose the lead and a template. A readiness panel lists what the brief has and what it is missing — phone, email, services, service areas, colours, photos, requested page count — so gaps are visible before generation starts.
2. 2Content. The system derives the page list and generates the site's copy: hero, services, statistics, testimonials, FAQ, about, and the title and meta description of every page. It also proposes a colour theme.
3. 3Images. Candidate photographs are gathered for every image slot on the site, ranked, and presented for the operator to choose from. Only the chosen images are used.
4. 4Build. The site is assembled file by file, with a live step tracker and an estimated time to completion.
5. 5Review. Verification runs, the build can be previewed page by page and downloaded, and it can be reopened for edits and rebuilt.

How pages are chosen

Page selection is automatic. The pages the client asked for are matched against a canonical set — home, about, services, service areas, gallery and contact — and emitted in a sensible navigation order. Individual service and service-area pages are generated from the lists on the lead. If a business has no service areas, the area pages are simply not built.

Copywriting

Copy is generated from the real business details, and the generator is explicitly constrained: it may not invent licences, awards or certifications, testimonials must sit inside the areas the business actually serves, and if no email address is known, calls to action fall back to the phone number. The site's design files are never handed to the model, so the template's styling ships exactly as designed.

Imagery

For each image slot the system collects candidates from a stock photo library alongside any photos the client supplied, and an image-recognition pass scores every candidate for relevance to the slot and for visual quality. It can also detect and drop photographs containing people, which is on by default. The client's own photos are never dropped and always rank first.

The operator picks from the ranked shortlist — several images for a hero area, one for everything else — and can ask for more candidates or paste a specific image URL of their own.

Verification gates

Before a build can reach review — or be deployed — it must pass two blocking checks:

• Identity check.Every output file is scanned for text left over from the demo template. Nothing belonging to the sample business may survive into a client's site.
• Structure check. The page skeleton and script identifiers are compared against the template baseline, so a generation pass cannot quietly break the markup or the interactive behaviour.

Deployment & domains

A verified build can be published without leaving the console. Deployment happens in two phases, because clients want to see the real thing before they commit their domain to it.

1. 1Publish to staging. One click creates a subdomain on the company's staging domain, uploads the site, and writes the live link back onto the lead so everyone can find it.
2. 2Iterate. Redeploy in place after changes — the previous files are cleared first, so pages you removed genuinely disappear. A site can also be taken down, which frees the subdomain and returns the build to review.
3. 3Transfer to the client's domain. When the client approves, the site moves to their own domain. The files are pulled fresh from the live server rather than from the original build, so any manual tweaks made on staging survive the move. The staging subdomain is deleted afterwards.

A deployments board lists every published site with its live URL, when it shipped, and the redeploy, take-down and transfer actions available to it. Sites built outside the wizard can also be uploaded and hosted the same way.

Company mailbox

Company email accounts are linked to the people who use them, so an agent can work their own address inside the dashboard. Credentials are stored encrypted, and both the incoming and the outgoing connection are tested when the account is linked — a mailbox that cannot send is caught then, not at the moment someone tries to email a client.

• Read. Inbox and Sent, as a message list beside a reading pane, with sender, subject, date, a preview snippet and an attachment indicator.
• Compose and reply. Write a new message or reply to the thread you are reading, with recipients, copies and a subject.
• Attachments. Attach files to anything you send, and download what arrives. Sent messages are saved back to the Sent folder.
• Unread badge. New mail shows as a count in the sidebar and on the browser tab. If the mail server is briefly unreachable the badge simply reads zero rather than breaking the app.

New mail is checked periodically in the background so the badge and the notifications stay current while you work elsewhere in the console.

Contracts & templates

Contracts are generated from your own documents. An administrator connects a Google account and registers Google Docs as contract templates; each template is an ordinary document with {{placeholders}} wherever a client-specific value belongs.

1. 1Choose a template. From the templates registered for your organisation.
2. 2Generate. The template document is copied, its placeholders are filled from the lead, and the copy is exported as a PDF. The values used are snapshotted, so the contract cannot change under you afterwards.
3. 3Adjust the price. The one-time and yearly figures can be overridden on a single contract to apply a discount; left alone, they inherit the lead's quoted prices.
4. 4Send. The PDF is emailed from the agent's own verified company address, with a message the agent writes and their signature applied to the document.

Placeholders cover the client (name, phone, email), pricing, the sending agent, the provider, and a range of date and time formats — for example {{business_name}}, {{one_time_price}} and {{date_long}}. A catalog inside the app lists every placeholder a template can use, including any custom fields on the lead.

A contract only counts as sent once the email actually goes out. If sending fails it stays a draft and the agent is notified, rather than the record quietly claiming a client has been contacted. Every contract is listed centrally and shown on the lead it belongs to, and leads that already have one are badged in the table.

Operations

Tickets

Post-sale work is tracked as tickets against the lead — change requests and improvements, with a priority, an assignee, a due date and a resolution note. A ticket carries a checklist whose items can be ticked off individually and can hold file attachments, so the work and its evidence stay together. Tickets that pass their due date are escalated automatically.

Payments

Payment links are managed inside the console with a label, amount, currency and category — website, yearly, add-on or other — so the right link is always at hand next to the client it belongs to. Viewing and managing them are separate permissions.

Analytics

The dashboard reports on the pipeline in numbers: totals, quoted and closed revenue, recurring revenue, average deal size, conversion rate, new leads this week, overdue follow-ups, pickup rate and ticket health. Charts cover leads over time, pipeline by status, leads by agent, site type split, rating distribution and revenue by status, and results can be scoped by month and region. There is also a per-agent view.

Permissions

Permissions are the individual capabilities in the system — viewing leads, editing them, deploying a website, sending a contract, opening the admin area, and so on. There are roughly ninety of them, grouped by module. They are enforced on the server for every request, not merely hidden in the interface.

Access is resolved in three layers:

1. 1Departments. A department is a group with its own permission set — Sales, Management, Tech, Support, Admin, and any others an administrator creates. Grant features to the department once, then add people to it.
2. 2Membership. A person can belong to more than one department. When they do, their access is the union of all of them, with no extra configuration.
3. 3User overrides. An administrator can force-grant an extra permission, or revoke a specific one, for a single person — the exception that avoids reshaping a whole department.

The result is a person's effective access, recomputed every time they load a page — so a change takes effect immediately, with no redeploy.

Sign-in is by invitation only. There is no public sign-up; accounts are created by an administrator, who can also deactivate an account to block access without erasing any of that person's history. Actions across the system are written to an activity log.

Notifications

Notifications are rule-driven rather than hard-coded. An administrator decides which events raise a notification, and who receives it — the lead's agent, its closer, a ticket's assignee or creator, and so on. Some events can fire ahead of time, such as a follow-up reminder a set number of minutes before it is due.

FAQ